From daemon@optimus.ietf.org Mon Apr 1 07:21:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22275 for ; Mon, 1 Apr 2002 07:20:58 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA00126 for nsis-archive@odin.ietf.org; Mon, 1 Apr 2002 07:20:57 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA27980; Mon, 1 Apr 2002 07:16:21 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA27955 for ; Mon, 1 Apr 2002 07:16:19 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21983; Mon, 1 Apr 2002 07:15:56 -0500 (EST) Message-Id: <200204011215.HAA21983@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: nsis@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Mon, 01 Apr 2002 07:15:55 -0500 Subject: [NSIS] I-D ACTION:draft-polyrakis-mpib-00.txt Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Next Steps in Signaling Working Group of the IETF. Title : The Meta-Policy Information Base (M-PIB) Author(s) : A. Polyrakis, R. Boutaba Filename : draft-polyrakis-mpib-00.txt Pages : 31 Date : 29-Mar-02 This document introduces the concept of COPS-PR meta-policies and defines the Meta-Policy Information Base. The meta-policy PIB does not introduce a new policing area. On the contrary, it defines some provisioning classes that can be used by all other PIBs, in order to add meta-policing functionality into them. The meta-policy PIB, like every PIB, stores policing information that controls some policing mechanisms of the device. However, unlike other PIBs, the policing mechanism controlled by the meta-policy PRCs is the PIB itself. The data maintained by these PRCs implement policies that control other policies, this is why they are called meta-policies. Meta-policies is an attempt to push intelligence towards the COPS-PR PEPs and overcome the rigidity of their PIBs. Through meta-policies, more policing information and functionality can be pushed towards the PEP, less interaction with the PDP is necessary and less network and PDP resources are consumed. The PEP is more independent and it can bear longer PDP absences. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-polyrakis-mpib-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-polyrakis-mpib-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-polyrakis-mpib-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020329130848.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-polyrakis-mpib-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-polyrakis-mpib-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020329130848.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Tue Apr 2 09:43:53 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17309 for ; Tue, 2 Apr 2002 09:43:52 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA16078 for nsis-archive@odin.ietf.org; Tue, 2 Apr 2002 09:43:53 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA14831; Tue, 2 Apr 2002 09:28:24 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA14798 for ; Tue, 2 Apr 2002 09:28:21 -0500 (EST) Received: from mail1.telekom.de (mail1.telekom.de [62.225.183.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16623 for ; Tue, 2 Apr 2002 09:28:20 -0500 (EST) Received: from g8pbq.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Tue, 2 Apr 2002 16:26:28 +0200 Received: by G8PBQ.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Apr 2002 16:27:50 +0200 Message-Id: From: "Geib, Ruediger" To: svenvandenbosch@hotmail.com Cc: nsis@ietf.org Subject: RE: [NSIS] proposals related to NSIS WG draft Date: Tue, 2 Apr 2002 16:27:49 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id JAA14799 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Sven, the comment is a bit late, but I've been offline for a while. Nevertheless: > * New requirements > - in section MUST support priority > The priority of a flow is essentially decoupled from > its QoS requirements. Therefore the protocol MUST > support priority. As a consequence, it MUST support > preemption of traffic flows in case of congestion or > failure. A preemption action MAY trigger an attempt > to resetup the request by means of another instance > of an NSIS signaling protocol. Could you provide some clearer argumentation why preemption is a requirement? I'd classify preemption as a "nice to have" feature, no more than a "MAY" requirement. I'd especially insist on preemption being completely decoupled from QoS and any other service related signalling. I.e. if it is not supported by an opperator, no parameters or messages related to preemption are to be transported. I'd like to ask other representatives of operators for their view. Regards, Rüdiger _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Wed Apr 3 15:17:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14531 for ; Wed, 3 Apr 2002 15:17:37 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA23737 for nsis-archive@odin.ietf.org; Wed, 3 Apr 2002 15:17:40 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA23034; Wed, 3 Apr 2002 15:02:15 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA22997 for ; Wed, 3 Apr 2002 15:02:12 -0500 (EST) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14229 for ; Wed, 3 Apr 2002 15:02:08 -0500 (EST) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g33K1eS24925 for ; Wed, 3 Apr 2002 15:01:40 -0500 (EST) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Apr 2002 15:01:41 -0500 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA49A7@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'NSIS'" Date: Wed, 3 Apr 2002 15:01:38 -0500 Sensitivity: Company-Confidential X-Mailer: Internet Mail Service (5.5.2653.19) Subject: [NSIS] question on 5.3.3 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hello: I have a question regarding one of the requirements: 5.3.3 Possibility for automatic release of resources after failure When the QoS Initiator goes down, the resources it requested should be released, since they will no longer be necessary. This does not seem to me to be a protocol requirement nor a framework requirement, but rather an implementation requirement. Does this matter? Thanks, Gary _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Wed Apr 3 15:27:53 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14753 for ; Wed, 3 Apr 2002 15:27:53 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA24208 for nsis-archive@odin.ietf.org; Wed, 3 Apr 2002 15:27:56 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA23929; Wed, 3 Apr 2002 15:22:05 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA23896 for ; Wed, 3 Apr 2002 15:22:00 -0500 (EST) Received: from howler.tri.sbc.com (howler.tri.sbc.com [205.173.58.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14617 for ; Wed, 3 Apr 2002 15:21:57 -0500 (EST) Received: from sbctri.tri.sbc.com (sbctri [144.60.1.10]) by howler.tri.sbc.com (8.11.6+Sun/8.11.0) with ESMTP id g33KOiN29031; Wed, 3 Apr 2002 14:24:44 -0600 (CST) Received: from TRIMAIL2.ad.tri.sbc.com (localhost [127.0.0.1]) by sbctri.tri.sbc.com (8.11.6+Sun/8.9.3) with ESMTP id g33KLGL26042; Wed, 3 Apr 2002 14:21:16 -0600 (CST) Received: by TRIMAIL2.ad.tri.sbc.com with Internet Mail Service (5.5.2653.19) id <2HFW5TAW>; Wed, 3 Apr 2002 14:21:58 -0600 Message-ID: <905A1C4ABF353F4C8CC16FA9F53DD0D638BA5D@TRIMAIL2.ad.tri.sbc.com> From: "Schneider, Marco" To: "'Gary Kenward'" , "'NSIS'" Subject: RE: [NSIS] question on 5.3.3 Date: Wed, 3 Apr 2002 14:21:56 -0600 Sensitivity: Company-Confidential MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org To me this is part of the semantics of the protocol. My requirement is that the protocol support the following two behaviours: 1) When the QOS Initiator goes down, the resources it requested will be released 2) When the QOS Initiator goes down, the resources it requested will not be released The reason for supporting behaviour #2 is the case where an entity in the network proxy signals on behalf of a large number of customers. We want the ability for the corresponding connections to stay up should a controller fail. For policy reasons we may want to require that behaviour #1 be enforced for some customers. Obviously if a customer is paying for a connection that would want #1 to be enforced as well. Cheers, Marco > -----Original Message----- > From: Gary Kenward [mailto:gkenward@nortelnetworks.com] > Sent: Wednesday, April 03, 2002 2:02 PM > To: 'NSIS' > Subject: [NSIS] question on 5.3.3 > Sensitivity: Confidential > > > Hello: > > I have a question regarding one of the requirements: > > 5.3.3 Possibility for automatic release of resources after failure > > When the QoS Initiator goes down, the resources it requested should > be released, since they will no longer be necessary. > > This does not seem to me to be a protocol requirement nor a framework > requirement, but rather an implementation requirement. > > Does this matter? > > Thanks, > Gary > > > > > > _______________________________________________ > 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 daemon@ns.ietf.org Wed Apr 3 15:43:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15188 for ; Wed, 3 Apr 2002 15:43:01 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA25599 for nsis-archive@odin.ietf.org; Wed, 3 Apr 2002 15:43:04 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA24262; Wed, 3 Apr 2002 15:28:41 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA24231 for ; Wed, 3 Apr 2002 15:28:37 -0500 (EST) Received: from idcpa4.pa.interdigital.com (idcmail.interdigital.com [12.32.197.142]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14780 for ; Wed, 3 Apr 2002 15:28:34 -0500 (EST) Received: by idcpa4.pa.interdigital.com with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Apr 2002 15:27:02 -0500 Message-ID: From: "Shahrier, Sharif M." To: "Shahrier, Sharif M." Cc: nsis@ietf.org Subject: [NSIS] On the definition of QoS flow and aggregate flow. Date: Wed, 3 Apr 2002 15:27:01 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org In the NSIS requirement draft, I have some points for discussion on the definition of a "flow" from the presective of NSIS, and also on the definition of "aggregate flow". I feel these need to be defined more fully in terms of QoS. It is defined in the requirements draft, that: A flow is a traffic stream between two endpoints for which "a specific level of QoS is provided". My question is how to characterize such a flow in terms of quantitative QoS parameters. A set of QoS parameters can be standardized for a flow. These parameters could be: Maximum delay Minimum throughput Maximum response time (assuming buffering) Maximum jitter ....... These parameters should then be mapped to a specific "priority value", i.e. a single parameter. The parameter can relate directly to ABR, CBR, UBR, ......... types of flow. A 6-tuple (src. addr, dest. addr., src. port nbr., dest. port nbr, protoID, Priority) should characterize a "flow" as far as the requirements for NSIS working group. Having a single priority value would make it much easier to quantify QoS to define a flow, as opposed to a whole set of parameters like delay, throughput, jitter ............ A flow aggregate can be defined as a set of flows, where each flow has the same QoS priority. Thus, a coarse grain, single QoS priority for "flow" characterization can help to readily gather flows with the same priority value into a set to form an aggregate flow set. Comments and feedback please......... Sharif. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Wed Apr 3 15:44:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15236 for ; Wed, 3 Apr 2002 15:44:54 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA25651 for nsis-archive@odin.ietf.org; Wed, 3 Apr 2002 15:44:57 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA25234; Wed, 3 Apr 2002 15:34:53 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA25201 for ; Wed, 3 Apr 2002 15:34:49 -0500 (EST) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15032 for ; Wed, 3 Apr 2002 15:34:45 -0500 (EST) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g33KYFS27304; Wed, 3 Apr 2002 15:34:15 -0500 (EST) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Apr 2002 15:34:16 -0500 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA49A9@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Schneider, Marco'" , "'NSIS'" Subject: RE: [NSIS] question on 5.3.3 Date: Wed, 3 Apr 2002 15:34:07 -0500 Sensitivity: Company-Confidential MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DB4E.7F00DEA0" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1DB4E.7F00DEA0 Content-Type: text/plain; charset="iso-8859-1" Marco: I fully agree that resource allocations need to have the option for finite life times. However, I am unclear as to how 1) versus 2) would change the semantics of the protocol? As opposed to the semantics of resource reservation algorithms at a given node? To state this in another fashion, if I attached a protocol analyzer to a link carrying NSIS, what protocol semantics could I capture that would reflect this resource timing? Gary > -----Original Message----- > From: Schneider, Marco [mailto:schneider@tri.sbc.com] > Sent: April 3, 2002 15:22 > To: Kenward, Gary [WDLN2:AN10:EXCH]; 'NSIS' > Subject: RE: [NSIS] question on 5.3.3 > Sensitivity: Confidential > > > To me this is part of the semantics of the protocol. My > requirement is that > the protocol support the following two behaviours: > > 1) When the QOS Initiator goes down, the resources it > requested will be > released > 2) When the QOS Initiator goes down, the resources it > requested will not be > released > > The reason for supporting behaviour #2 is the case where an > entity in the > network proxy signals on behalf of a large number of > customers. We want the > ability for the corresponding connections to stay up should a > controller > fail. For policy reasons we may want to require that behaviour #1 be > enforced for some customers. Obviously if a customer is paying for a > connection that would want #1 to be enforced as well. > > Cheers, > Marco > > > > > -----Original Message----- > > From: Gary Kenward [mailto:gkenward@nortelnetworks.com] > > Sent: Wednesday, April 03, 2002 2:02 PM > > To: 'NSIS' > > Subject: [NSIS] question on 5.3.3 > > Sensitivity: Confidential > > > > > > Hello: > > > > I have a question regarding one of the requirements: > > > > 5.3.3 Possibility for automatic release of resources after failure > > > > When the QoS Initiator goes down, the resources it > requested should > > be released, since they will no longer be necessary. > > > > This does not seem to me to be a protocol requirement nor a > framework > > requirement, but rather an implementation requirement. > > > > Does this matter? > > > > Thanks, > > Gary > > > > > > > > > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > ------_=_NextPart_001_01C1DB4E.7F00DEA0 Content-Type: text/html; charset="iso-8859-1" RE: [NSIS] question on 5.3.3

Marco:

  I fully agree that resource allocations need to have the option for
finite life times.

  However, I am unclear as to how 1) versus 2) would change the semantics
of the protocol? As opposed to the semantics of resource reservation algorithms
at a given node?

  To state this in another fashion, if I attached a protocol
analyzer to a link carrying NSIS, what protocol semantics could
I capture that would reflect this resource timing?

Gary

> -----Original Message-----
> From: Schneider, Marco [mailto:schneider@tri.sbc.com]
> Sent: April 3, 2002 15:22
> To: Kenward, Gary [WDLN2:AN10:EXCH]; 'NSIS'
> Subject: RE: [NSIS] question on 5.3.3
> Sensitivity: Confidential
>
>
> To me this is part of the semantics of the protocol. My
> requirement is that
> the protocol support the following two behaviours:
>
> 1) When the QOS Initiator goes down, the resources it
> requested will be
> released
> 2) When the QOS Initiator goes down, the resources it
> requested will not be
> released
>
> The reason for supporting behaviour #2 is the case where an
> entity in the
> network proxy signals on behalf of a large number of
> customers. We want the
> ability for the corresponding connections to stay up should a
> controller
> fail. For policy reasons we may want to require that behaviour #1 be
> enforced for some customers. Obviously if a customer is paying for a
> connection that would want #1 to be enforced as well.
>
> Cheers,
> Marco
>
>
>
> > -----Original Message-----
> > From: Gary Kenward [mailto:gkenward@nortelnetworks.com]
> > Sent: Wednesday, April 03, 2002 2:02 PM
> > To: 'NSIS'
> > Subject: [NSIS] question on 5.3.3
> > Sensitivity: Confidential
> >
> >
> > Hello:
> >
> > I have a question regarding one of the requirements:
> >
> > 5.3.3 Possibility for automatic release of resources after failure
> >
> >    When the QoS Initiator goes down, the resources it
> requested should
> >    be released, since they will no longer be necessary.
> >
> > This does not seem to me to be a protocol requirement nor a
> framework
> > requirement, but rather an implementation requirement.
> >
> > Does this matter?
> >
> > Thanks,
> > Gary
> >
> >
> >
> >
> >
> > _______________________________________________
> > nsis mailing list
> > nsis@ietf.org
> > https://www1.ietf.org/mailman/listinfo/nsis
> >
>

------_=_NextPart_001_01C1DB4E.7F00DEA0-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Wed Apr 3 15:46:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15297 for ; Wed, 3 Apr 2002 15:46:49 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA25721 for nsis-archive@odin.ietf.org; Wed, 3 Apr 2002 15:46:48 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA25039; Wed, 3 Apr 2002 15:32:47 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA25003 for ; Wed, 3 Apr 2002 15:32:43 -0500 (EST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14967 for ; Wed, 3 Apr 2002 15:32:39 -0500 (EST) Received: from mira-sjc5-7.cisco.com (IDENT:mirapoint@mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g33KW7OY024165; Wed, 3 Apr 2002 12:32:07 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id ABH24368; Wed, 3 Apr 2002 12:29:43 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA14264; Wed, 3 Apr 2002 12:32:06 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15531.26310.192169.241593@thomasm-u1.cisco.com> Date: Wed, 3 Apr 2002 12:32:06 -0800 (PST) To: "Schneider, Marco" Cc: "'Gary Kenward'" , "'NSIS'" Subject: RE: [NSIS] question on 5.3.3 In-Reply-To: <905A1C4ABF353F4C8CC16FA9F53DD0D638BA5D@TRIMAIL2.ad.tri.sbc.com> References: <905A1C4ABF353F4C8CC16FA9F53DD0D638BA5D@TRIMAIL2.ad.tri.sbc.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit Schneider, Marco writes: > To me this is part of the semantics of the protocol. My requirement is that > the protocol support the following two behaviours: > > 1) When the QOS Initiator goes down, the resources it requested will be > released > 2) When the QOS Initiator goes down, the resources it requested will not be > released Define "down". Does a network partition count? Mike _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Wed Apr 3 16:11:48 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15841 for ; Wed, 3 Apr 2002 16:11:48 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA27225 for nsis-archive@odin.ietf.org; Wed, 3 Apr 2002 16:11:51 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA26171; Wed, 3 Apr 2002 15:55:35 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA26125 for ; Wed, 3 Apr 2002 15:55:32 -0500 (EST) Received: from idcpa4.pa.interdigital.com (idcmail.interdigital.com [12.32.197.142]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15596 for ; Wed, 3 Apr 2002 15:55:28 -0500 (EST) Received: by idcpa4.pa.interdigital.com with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Apr 2002 15:53:56 -0500 Message-ID: From: "Shahrier, Sharif M." To: "Shahrier, Sharif M." Cc: "'nsis@ietf.org'" Subject: [NSIS] On flow buffering and scheduling. Date: Wed, 3 Apr 2002 15:53:55 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org A flow is a packet stream between endpoints, with a specified level of QoS. In my last e-mail, I had suggested using priority, as the level of QoS for the given flow stream. I had also suggested using a 6-tuple (src addr, dst addr, src prt, dst prt, protoid, priority) to characterize flow for NSIS purposes. For a flow to be a member of an aggregate flow set, its priority must be the same as all the others, of course, while src addr, dst addr may be different. An important consideration is how to buffer the flows for an aggregate flow set, so they all can have the same forwarding treatment based on their common priority value. How to manage the buffers............ And how to schedule packets in the aggregate flow set for transmission. I believe these are important issues, I wanted to bring them up for discussion, suggesting text should be added to the requirements document. Sharif. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Wed Apr 3 16:30:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16359 for ; Wed, 3 Apr 2002 16:30:22 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA28024 for nsis-archive@odin.ietf.org; Wed, 3 Apr 2002 16:30:26 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA27173; Wed, 3 Apr 2002 16:10:06 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA27139 for ; Wed, 3 Apr 2002 16:10:01 -0500 (EST) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15808 for ; Wed, 3 Apr 2002 16:09:57 -0500 (EST) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g33L9SS29864; Wed, 3 Apr 2002 16:09:28 -0500 (EST) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Apr 2002 16:09:29 -0500 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA49AC@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Shahrier, Sharif M.'" Cc: "'nsis@ietf.org'" Subject: RE: [NSIS] On flow buffering and scheduling. Date: Wed, 3 Apr 2002 16:09:28 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DB53.7B795FC8" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1DB53.7B795FC8 Content-Type: text/plain; charset="iso-8859-1" Sharif: I think you are proposing a new QoS model, based upon "priority". It is my understanding that the common view of "priority" from a QoS perspective is that it can always be translated to other QoS performance parameters: more bandwidth, lower delay, less loss, lower delay jitter. Priority queuing is just one mechanism for achieving these QoS levels. Gary > -----Original Message----- > From: Shahrier, Sharif M. [mailto:Sharif.Shahrier@InterDigital.com] > Sent: April 3, 2002 15:54 > To: Shahrier, Sharif M. > Cc: 'nsis@ietf.org' > Subject: [NSIS] On flow buffering and scheduling. > > > > A flow is a packet stream between endpoints, with a specified > level of QoS. > > In my last e-mail, I had suggested using priority, as the > level of QoS for > the given flow stream. > > I had also suggested using a 6-tuple (src addr, dst addr, src > prt, dst prt, > protoid, priority) to characterize flow for NSIS purposes. > > For a flow to be a member of an aggregate flow set, its > priority must be the > same as all the others, of course, while src addr, dst addr may be > different. > > An important consideration is how to buffer the flows for an > aggregate flow > set, so they all can have the same forwarding treatment based on their > common priority value. > > How to manage the buffers............ > > And how to schedule packets in the aggregate flow set for > transmission. > > I believe these are important issues, I wanted to bring them up for > discussion, suggesting text should be added to the > requirements document. > > Sharif. > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > ------_=_NextPart_001_01C1DB53.7B795FC8 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [NSIS] On flow buffering and scheduling.

Sharif:

 I think you are proposing a new QoS model, = based upon "priority".
It is my understanding that the common view of = "priority" from a QoS
perspective is that it can always be translated to = other QoS performance
parameters: more bandwidth, lower delay, less loss, = lower delay jitter.
Priority queuing is just one mechanism for achieving = these QoS levels.

Gary

> -----Original Message-----
> From: Shahrier, Sharif M. [mailto:Sharif.Shahrier@= InterDigital.com]
> Sent: April 3, 2002 15:54
> To: Shahrier, Sharif M.
> Cc: 'nsis@ietf.org'
> Subject: [NSIS] On flow buffering and = scheduling.
>
>
>
> A flow is a packet stream between endpoints, = with a specified
> level of QoS.
>
> In my last e-mail, I had suggested using = priority, as the
> level of QoS for
> the given flow stream.
>
> I had also suggested using a 6-tuple (src addr, = dst addr, src
> prt, dst prt,
> protoid, priority) to characterize flow for = NSIS purposes.
>
> For a flow to be a member of an aggregate flow = set, its
> priority must be the
> same as all the others, of course, while src = addr, dst addr may be
> different.
>
> An important consideration is how to buffer the = flows for an
> aggregate flow
> set, so they all can have the same forwarding = treatment based on their
> common priority value.
>
> How to manage the buffers............
>
> And how to schedule packets in the aggregate = flow set for
> transmission.
>
> I believe these are important issues, I wanted = to bring them up for
> discussion, suggesting text should be added to = the
> requirements document.
>
> Sharif.
>
> = _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis=
>

------_=_NextPart_001_01C1DB53.7B795FC8-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Wed Apr 3 16:31:48 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16406 for ; Wed, 3 Apr 2002 16:31:48 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA28333 for nsis-archive@odin.ietf.org; Wed, 3 Apr 2002 16:31:51 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA27361; Wed, 3 Apr 2002 16:13:54 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA27282 for ; Wed, 3 Apr 2002 16:13:48 -0500 (EST) Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15890 for ; Wed, 3 Apr 2002 16:13:38 -0500 (EST) From: marc.greis@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g33LGCH08052 for ; Wed, 3 Apr 2002 15:16:13 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 3 Apr 2002 15:13:38 -0600 Received: from daebe006.NOE.Nokia.com ([172.18.242.205]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 3 Apr 2002 15:13:37 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DB54.6B8DC4F4" Subject: RE: [NSIS] question on 5.3.3 Date: Wed, 3 Apr 2002 15:13:37 -0600 Message-ID: Thread-Topic: [NSIS] question on 5.3.3 Thread-Index: AcHbTxG4aWg870XXR+ekTFlKSdWpowABKT4A Sensitivity: Company-Confidential To: , , X-OriginalArrivalTime: 03 Apr 2002 21:13:37.0350 (UTC) FILETIME=[6BAFBE60:01C1DB54] Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C1DB54.6B8DC4F4 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Gary, =20 I assume that based based on this requirement, there needs to be a = mechanism in the protocol to determine if the QoS Initiator is actually = down. So to come back to your original question, I do think that this is = actually a protocol requirement and not merely an implementation issue. =20 Marc =20 -----Original Message----- From: ext Gary Kenward [mailto:gkenward@nortelnetworks.com] Sent: 03 April, 2002 2:34 PM To: 'Schneider, Marco'; 'NSIS' Subject: RE: [NSIS] question on 5.3.3 Marco:=20 I fully agree that resource allocations need to have the option for=20 finite life times.=20 However, I am unclear as to how 1) versus 2) would change the = semantics=20 of the protocol? As opposed to the semantics of resource reservation = algorithms=20 at a given node?=20 To state this in another fashion, if I attached a protocol=20 analyzer to a link carrying NSIS, what protocol semantics could=20 I capture that would reflect this resource timing?=20 Gary=20 > -----Original Message-----=20 > From: Schneider, Marco [ mailto:schneider@tri.sbc.com]=20 > Sent: April 3, 2002 15:22=20 > To: Kenward, Gary [WDLN2:AN10:EXCH]; 'NSIS'=20 > Subject: RE: [NSIS] question on 5.3.3=20 > Sensitivity: Confidential=20 >=20 >=20 > To me this is part of the semantics of the protocol. My=20 > requirement is that=20 > the protocol support the following two behaviours:=20 >=20 > 1) When the QOS Initiator goes down, the resources it=20 > requested will be=20 > released=20 > 2) When the QOS Initiator goes down, the resources it=20 > requested will not be=20 > released=20 >=20 > The reason for supporting behaviour #2 is the case where an=20 > entity in the=20 > network proxy signals on behalf of a large number of=20 > customers. We want the=20 > ability for the corresponding connections to stay up should a=20 > controller=20 > fail. For policy reasons we may want to require that behaviour #1 be=20 > enforced for some customers. Obviously if a customer is paying for a=20 > connection that would want #1 to be enforced as well.=20 >=20 > Cheers,=20 > Marco=20 >=20 >=20 >=20 > > -----Original Message-----=20 > > From: Gary Kenward [ mailto:gkenward@nortelnetworks.com]=20 > > Sent: Wednesday, April 03, 2002 2:02 PM=20 > > To: 'NSIS'=20 > > Subject: [NSIS] question on 5.3.3=20 > > Sensitivity: Confidential=20 > >=20 > >=20 > > Hello:=20 > >=20 > > I have a question regarding one of the requirements:=20 > >=20 > > 5.3.3 Possibility for automatic release of resources after failure=20 > >=20 > > When the QoS Initiator goes down, the resources it=20 > requested should=20 > > be released, since they will no longer be necessary.=20 > >=20 > > This does not seem to me to be a protocol requirement nor a=20 > framework=20 > > requirement, but rather an implementation requirement.=20 > >=20 > > Does this matter?=20 > >=20 > > Thanks,=20 > > Gary=20 > >=20 > >=20 > >=20 > >=20 > >=20 > > _______________________________________________=20 > > nsis mailing list=20 > > nsis@ietf.org=20 > > https://www1.ietf.org/mailman/listinfo/nsis=20 > >=20 >=20 ------_=_NextPart_001_01C1DB54.6B8DC4F4 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [NSIS] question on 5.3.3
Gary,
 
I=20 assume that based based on this requirement, there needs to be a = mechanism in=20 the protocol to determine if the QoS Initiator is actually down. So to = come back=20 to your original question, I do think that this is actually a protocol=20 requirement and not merely an implementation issue.
 
Marc
 
-----Original Message-----
From: ext Gary Kenward=20 [mailto:gkenward@nortelnetworks.com]
Sent: 03 April, 2002 = 2:34=20 PM
To: 'Schneider, Marco'; 'NSIS'
Subject: RE: = [NSIS]=20 question on 5.3.3

Marco:

  I fully agree that resource allocations need = to have=20 the option for
finite life times. =

  However, I am unclear as to how 1) versus 2) = would=20 change the semantics
of the protocol? As = opposed to=20 the semantics of resource reservation algorithms
at a=20 given node?

  To state this in another fashion, if I = attached a=20 protocol
analyzer to a link carrying NSIS, = what=20 protocol semantics could
I capture that = would reflect=20 this resource timing?

Gary

> -----Original Message-----
>=20 From: Schneider, Marco [mailto:schneider@tri.sbc.com]=20
> Sent: April 3, 2002 15:22
>=20 To: Kenward, Gary [WDLN2:AN10:EXCH]; 'NSIS'
>=20 Subject: RE: [NSIS] question on 5.3.3
>=20 Sensitivity: Confidential
> =
>
> To me this is part of the = semantics=20 of the protocol. My
> requirement is = that=20
> the protocol support the following two=20 behaviours:
>
> 1) When=20 the QOS Initiator goes down, the resources it
>=20 requested will be
> released =
> 2) When the QOS Initiator goes down, the resources it=20
> requested will not be
> released
>
>=20 The reason for supporting behaviour #2 is the case where an =
> entity in the
> network = proxy signals=20 on behalf of a large number of
> = customers. We want=20 the
> ability for the corresponding = connections to=20 stay up should a
> controller =
> fail. For policy reasons we may want to require that = behaviour #1=20 be
> enforced for some customers. = Obviously if a=20 customer is paying for a
> connection = that would=20 want #1 to be enforced as well.
> =
> Cheers,
> Marco =
>
>
>=20
> > -----Original Message----- =
> > From: Gary Kenward [mailto:gkenward@nortelnetwork= s.com]=20
> > Sent: Wednesday, April 03, 2002 2:02 = PM=20
> > To: 'NSIS'
> = >=20 Subject: [NSIS] question on 5.3.3
> >=20 Sensitivity: Confidential
> > =
> >
> > Hello: =
> >
> > I have a = question regarding=20 one of the requirements:
> > =
> > 5.3.3 Possibility for automatic release of = resources after=20 failure
> >
>=20 >    When the QoS Initiator goes down, the resources = it=20
> requested should
>=20 >    be released, since they will no longer be=20 necessary.
> >
> >=20 This does not seem to me to be a protocol requirement nor a =
> framework
> > = requirement, but=20 rather an implementation requirement.
> = >=20
> > Does this matter?
> >
> > Thanks, =
> > Gary
> > =
> >
> > =
> >
> > =
> > = _______________________________________________=20
> > nsis mailing list
> >=20 nsis@ietf.org
> > https://www1.ietf.org/mailman/listinfo/nsis =
> >
>=20

------_=_NextPart_001_01C1DB54.6B8DC4F4-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Wed Apr 3 16:43:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16678 for ; Wed, 3 Apr 2002 16:43:56 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA29339 for nsis-archive@odin.ietf.org; Wed, 3 Apr 2002 16:44:00 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA28842; Wed, 3 Apr 2002 16:37:30 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA28807 for ; Wed, 3 Apr 2002 16:37:26 -0500 (EST) Received: from idcpa4.pa.interdigital.com (idcmail.interdigital.com [12.32.197.142]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16497 for ; Wed, 3 Apr 2002 16:37:20 -0500 (EST) Received: by idcpa4.pa.interdigital.com with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Apr 2002 16:35:48 -0500 Message-ID: From: "Shahrier, Sharif M." To: "'Gary Kenward'" , "Shahrier, Sharif M." Cc: "'nsis@ietf.org'" Subject: RE: [NSIS] On flow buffering and scheduling. Date: Wed, 3 Apr 2002 16:35:47 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DB57.84C00920" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1DB57.84C00920 Content-Type: text/plain; charset="iso-8859-1" Gary: Priority is not a "new QoS model". It is already defined in the IETF. For example Differentiated Services can map from service parameters such as delay, throughput, etc. to a number of discrete codepoints, known as Differentiated Services CodePoints (DSCPs). Thus, the idea of translating from service specific QoS parameters to priority values exists already. I was suggesting the re-use of this concept to characterize a flow from the NSIS prespective. Sharif. -----Original Message----- From: Gary Kenward [mailto:gkenward@nortelnetworks.com] Sent: Wednesday, April 03, 2002 4:09 PM To: 'Shahrier, Sharif M.' Cc: 'nsis@ietf.org' Subject: RE: [NSIS] On flow buffering and scheduling. Sharif: I think you are proposing a new QoS model, based upon "priority". It is my understanding that the common view of "priority" from a QoS perspective is that it can always be translated to other QoS performance parameters: more bandwidth, lower delay, less loss, lower delay jitter. Priority queuing is just one mechanism for achieving these QoS levels. Gary > -----Original Message----- > From: Shahrier, Sharif M. [ mailto:Sharif.Shahrier@InterDigital.com ] > Sent: April 3, 2002 15:54 > To: Shahrier, Sharif M. > Cc: 'nsis@ietf.org' > Subject: [NSIS] On flow buffering and scheduling. > > > > A flow is a packet stream between endpoints, with a specified > level of QoS. > > In my last e-mail, I had suggested using priority, as the > level of QoS for > the given flow stream. > > I had also suggested using a 6-tuple (src addr, dst addr, src > prt, dst prt, > protoid, priority) to characterize flow for NSIS purposes. > > For a flow to be a member of an aggregate flow set, its > priority must be the > same as all the others, of course, while src addr, dst addr may be > different. > > An important consideration is how to buffer the flows for an > aggregate flow > set, so they all can have the same forwarding treatment based on their > common priority value. > > How to manage the buffers............ > > And how to schedule packets in the aggregate flow set for > transmission. > > I believe these are important issues, I wanted to bring them up for > discussion, suggesting text should be added to the > requirements document. > > Sharif. > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > ------_=_NextPart_001_01C1DB57.84C00920 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [NSIS] On flow buffering and scheduling.

G= ary:

<= ![if = !supportEmptyParas]> 

=

<= span style=3D'mso-tab-count:1'>       &nbs= p;    Priority is not a “new QoS model”. It is already defined in the = IETF. For example Differentiated Services can map from service parameters such as delay, throughput, etc. to a number of discrete codepoints, known as = Differentiated Services CodePoints (DSCPs). Thus, the idea of translating from service specific  QoS parameters = to priority values exists already.

<= ![if = !supportEmptyParas]> 

=

I= was suggesting the re-use of this concept to characterize a flow from the = NSIS prespective.

<= ![if = !supportEmptyParas]> 

=

S= harif.

<= ![if = !supportEmptyParas]> 

=

-----Original Message-----
From: Gary Kenward [mailto:gkenward@nortelnetworks.com]
Sent: Wednesday, April = 03, 2002 4:09 PM
To: 'Shahrier, Sharif = M.'
Cc: 'nsis@ietf.org'
Subject: RE: [NSIS] On = flow buffering and scheduling.

 

Sharif: =

 I think you are proposing a new QoS model, based = upon "priority".
It is my understanding that the common view of "priority" from a QoS
perspective is that it can always be translated to other = QoS performance
parameters: more bandwidth, lower delay, less loss, lower = delay jitter. =
Priority queuing is just one mechanism for achieving these = QoS levels. = =

Gary =

> -----Original Message-----
> From: Shahrier, Sharif M. [mailto:Sharif.Shahrier@= InterDigital.com]
> Sent: April 3, 2002 15:54
> To: Shahrier, Sharif M.
> Cc: 'nsis@ietf.org'
> Subject: [NSIS] On flow buffering and = scheduling.
>
>
>
> A flow is a packet stream between endpoints, with a = specified
> level of QoS.
>
> In my last e-mail, I had suggested using priority, as = the
> level of QoS for
> the given flow stream.
>
> I had also suggested using a 6-tuple (src addr, dst = addr, src
> prt, dst prt,
> protoid, priority) to characterize flow for NSIS = purposes.
>
> For a flow to be a member of an aggregate flow set, = its
> priority must be the
> same as all the others, of course, while src addr, = dst addr may be =
> different.
>
> An important consideration is how to buffer the flows = for an
> aggregate flow
> set, so they all can have the same forwarding = treatment based on their =
> common priority value.
>
> How to manage the = buffers............
>
> And how to schedule packets in the aggregate flow set = for
> transmission.
>
> I believe these are important issues, I wanted to = bring them up for =
> discussion, suggesting text should be added to the =
> requirements document.
>
> Sharif.
>
> = _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis=
>

------_=_NextPart_001_01C1DB57.84C00920-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Wed Apr 3 16:45:11 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16708 for ; Wed, 3 Apr 2002 16:45:11 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA29372 for nsis-archive@odin.ietf.org; Wed, 3 Apr 2002 16:45:15 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA28661; Wed, 3 Apr 2002 16:35:31 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA28627 for ; Wed, 3 Apr 2002 16:35:28 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16446 for ; Wed, 3 Apr 2002 16:35:23 -0500 (EST) Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id g33LYrV05100 for ; Wed, 3 Apr 2002 13:34:53 -0800 (PST) Received: from SBRIM-W2K (rtp-vpn1-422.cisco.com [10.82.225.166]) by airborne.cisco.com (Mirapoint) with SMTP id AAX10870; Wed, 3 Apr 2002 13:34:40 -0800 (PST) Received: by SBRIM-W2K (sSMTP sendmail emulation); Wed, 3 Apr 2002 16:34:51 -0500 Date: Wed, 3 Apr 2002 16:34:50 -0500 From: Scott Brim To: "'nsis@ietf.org'" Subject: Re: [NSIS] On flow buffering and scheduling. Message-ID: <20020403163450.L1948@SBRIM-W2K> Mail-Followup-To: Scott Brim , "'nsis@ietf.org'" References: <9FBD322B7824D511B36900508BF93C9C01AA49AC@zcard031.ca.nortel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <9FBD322B7824D511B36900508BF93C9C01AA49AC@zcard031.ca.nortel.com>; from gkenward@nortelnetworks.com on Wed, Apr 03, 2002 at 04:09:28PM -0500 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Regardless, a flow is what QoS is applied to, therefore it cannot be defined as having a "specified level of QoS" without circularity. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Wed Apr 3 17:13:31 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17500 for ; Wed, 3 Apr 2002 17:13:31 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA01821 for nsis-archive@odin.ietf.org; Wed, 3 Apr 2002 17:13:35 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA01068; Wed, 3 Apr 2002 17:02:23 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA01030 for ; Wed, 3 Apr 2002 17:02:19 -0500 (EST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17135 for ; Wed, 3 Apr 2002 17:02:11 -0500 (EST) Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id g33M2Ep22730; Wed, 3 Apr 2002 14:02:14 -0800 (PST) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.8.7/8.8.6) id WAA03281; Wed, 3 Apr 2002 22:02:14 GMT Date: Wed, 3 Apr 2002 22:02:14 GMT Message-Id: <200204032202.WAA03281@gra.isi.edu> To: gkenward@nortelnetworks.com, Sharif.Shahrier@InterDigital.com Subject: RE: [NSIS] On flow buffering and scheduling. Cc: nsis@ietf.org X-Sun-Charset: US-ASCII Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org *> From nsis-admin@ietf.org Wed Apr 3 13:38:03 2002 *> From: "Shahrier, Sharif M." *> To: "'Gary Kenward'" , *> "Shahrier, Sharif M." *> *> Cc: "'nsis@ietf.org'" *> Subject: RE: [NSIS] On flow buffering and scheduling. *> Date: Wed, 3 Apr 2002 16:35:47 -0500 *> MIME-Version: 1.0 *> X-Mailman-Version: 1.0 *> List-Id: Next Steps in Signaling *> X-BeenThere: nsis@ietf.org *> X-AntiVirus: scanned by AMaViS 0.2.1 *> *> Gary: *> *> Priority is not a "new QoS model". It is already defined in the *> IETF. For example Differentiated Services can map from service parameters *> such as delay, throughput, etc. to a number of discrete codepoints, known as *> Differentiated Services CodePoints (DSCPs). I would be very interested to read that the RFC that defines a mapping of QoS parameters to code points, or that says anything specific about priority queueing. Thanks, Bob Braden _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Wed Apr 3 17:27:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17707 for ; Wed, 3 Apr 2002 17:27:48 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA02169 for nsis-archive@odin.ietf.org; Wed, 3 Apr 2002 17:27:52 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA01577; Wed, 3 Apr 2002 17:07:06 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA01493 for ; Wed, 3 Apr 2002 17:06:59 -0500 (EST) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17309 for ; Wed, 3 Apr 2002 17:06:51 -0500 (EST) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g33M69i19036; Wed, 3 Apr 2002 17:06:09 -0500 (EST) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Apr 2002 17:06:11 -0500 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA49B3@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'marc.greis@nokia.com'" , schneider@tri.sbc.com, nsis@ietf.org Subject: RE: [NSIS] question on 5.3.3 Date: Wed, 3 Apr 2002 17:06:09 -0500 Sensitivity: Company-Confidential MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DB5B.69B85700" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1DB5B.69B85700 Content-Type: text/plain; charset="iso-8859-1" Marc: Ok, but I think that this is a specific interpretation of the requirement that is not captured in the wording. What you are referring to is more along the lines of protocol support for fault recovery. May be useful (if the initiator is down, who are the protocol peers? if the initiator is in the path, how can the protocol be used? etc.) Anyway, thanks. Gary -----Original Message----- From: marc.greis@nokia.com [mailto:marc.greis@nokia.com] Sent: April 3, 2002 16:14 To: Kenward, Gary [WDLN2:AN10:EXCH]; schneider@tri.sbc.com; nsis@ietf.org Subject: RE: [NSIS] question on 5.3.3 Sensitivity: Confidential Gary, I assume that based based on this requirement, there needs to be a mechanism in the protocol to determine if the QoS Initiator is actually down. So to come back to your original question, I do think that this is actually a protocol requirement and not merely an implementation issue. Marc -----Original Message----- From: ext Gary Kenward [mailto:gkenward@nortelnetworks.com] Sent: 03 April, 2002 2:34 PM To: 'Schneider, Marco'; 'NSIS' Subject: RE: [NSIS] question on 5.3.3 Marco: I fully agree that resource allocations need to have the option for finite life times. However, I am unclear as to how 1) versus 2) would change the semantics of the protocol? As opposed to the semantics of resource reservation algorithms at a given node? To state this in another fashion, if I attached a protocol analyzer to a link carrying NSIS, what protocol semantics could I capture that would reflect this resource timing? Gary > -----Original Message----- > From: Schneider, Marco [ mailto:schneider@tri.sbc.com ] > Sent: April 3, 2002 15:22 > To: Kenward, Gary [WDLN2:AN10:EXCH]; 'NSIS' > Subject: RE: [NSIS] question on 5.3.3 > Sensitivity: Confidential > > > To me this is part of the semantics of the protocol. My > requirement is that > the protocol support the following two behaviours: > > 1) When the QOS Initiator goes down, the resources it > requested will be > released > 2) When the QOS Initiator goes down, the resources it > requested will not be > released > > The reason for supporting behaviour #2 is the case where an > entity in the > network proxy signals on behalf of a large number of > customers. We want the > ability for the corresponding connections to stay up should a > controller > fail. For policy reasons we may want to require that behaviour #1 be > enforced for some customers. Obviously if a customer is paying for a > connection that would want #1 to be enforced as well. > > Cheers, > Marco > > > > > -----Original Message----- > > From: Gary Kenward [ mailto:gkenward@nortelnetworks.com ] > > Sent: Wednesday, April 03, 2002 2:02 PM > > To: 'NSIS' > > Subject: [NSIS] question on 5.3.3 > > Sensitivity: Confidential > > > > > > Hello: > > > > I have a question regarding one of the requirements: > > > > 5.3.3 Possibility for automatic release of resources after failure > > > > When the QoS Initiator goes down, the resources it > requested should > > be released, since they will no longer be necessary. > > > > This does not seem to me to be a protocol requirement nor a > framework > > requirement, but rather an implementation requirement. > > > > Does this matter? > > > > Thanks, > > Gary > > > > > > > > > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > ------_=_NextPart_001_01C1DB5B.69B85700 Content-Type: text/html; charset="iso-8859-1" RE: [NSIS] question on 5.3.3
Marc:
 
Ok, but I think that this is a specific interpretation of the requirement that is not captured in the wording.
What you are referring to is more along the lines of protocol support for fault recovery. May be useful
(if the initiator is down, who are the protocol peers? if the initiator is in the path, how can the protocol
be used? etc.)
 
Anyway, thanks.
Gary
-----Original Message-----
From: marc.greis@nokia.com [mailto:marc.greis@nokia.com]
Sent: April 3, 2002 16:14
To: Kenward, Gary [WDLN2:AN10:EXCH]; schneider@tri.sbc.com; nsis@ietf.org
Subject: RE: [NSIS] question on 5.3.3
Sensitivity: Confidential

Gary,
 
I assume that based based on this requirement, there needs to be a mechanism in the protocol to determine if the QoS Initiator is actually down. So to come back to your original question, I do think that this is actually a protocol requirement and not merely an implementation issue.
 
Marc
 
-----Original Message-----
From: ext Gary Kenward [mailto:gkenward@nortelnetworks.com]
Sent: 03 April, 2002 2:34 PM
To: 'Schneider, Marco'; 'NSIS'
Subject: RE: [NSIS] question on 5.3.3

Marco:

  I fully agree that resource allocations need to have the option for
finite life times.

  However, I am unclear as to how 1) versus 2) would change the semantics
of the protocol? As opposed to the semantics of resource reservation algorithms
at a given node?

  To state this in another fashion, if I attached a protocol
analyzer to a link carrying NSIS, what protocol semantics could
I capture that would reflect this resource timing?

Gary

> -----Original Message-----
> From: Schneider, Marco [mailto:schneider@tri.sbc.com]
> Sent: April 3, 2002 15:22
> To: Kenward, Gary [WDLN2:AN10:EXCH]; 'NSIS'
> Subject: RE: [NSIS] question on 5.3.3
> Sensitivity: Confidential
>
>
> To me this is part of the semantics of the protocol. My
> requirement is that
> the protocol support the following two behaviours:
>
> 1) When the QOS Initiator goes down, the resources it
> requested will be
> released
> 2) When the QOS Initiator goes down, the resources it
> requested will not be
> released
>
> The reason for supporting behaviour #2 is the case where an
> entity in the
> network proxy signals on behalf of a large number of
> customers. We want the
> ability for the corresponding connections to stay up should a
> controller
> fail. For policy reasons we may want to require that behaviour #1 be
> enforced for some customers. Obviously if a customer is paying for a
> connection that would want #1 to be enforced as well.
>
> Cheers,
> Marco
>
>
>
> > -----Original Message-----
> > From: Gary Kenward [mailto:gkenward@nortelnetworks.com]
> > Sent: Wednesday, April 03, 2002 2:02 PM
> > To: 'NSIS'
> > Subject: [NSIS] question on 5.3.3
> > Sensitivity: Confidential
> >
> >
> > Hello:
> >
> > I have a question regarding one of the requirements:
> >
> > 5.3.3 Possibility for automatic release of resources after failure
> >
> >    When the QoS Initiator goes down, the resources it
> requested should
> >    be released, since they will no longer be necessary.
> >
> > This does not seem to me to be a protocol requirement nor a
> framework
> > requirement, but rather an implementation requirement.
> >
> > Does this matter?
> >
> > Thanks,
> > Gary
> >
> >
> >
> >
> >
> > _______________________________________________
> > nsis mailing list
> > nsis@ietf.org
> > https://www1.ietf.org/mailman/listinfo/nsis
> >
>

------_=_NextPart_001_01C1DB5B.69B85700-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Wed Apr 3 17:49:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18130 for ; Wed, 3 Apr 2002 17:49:36 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA03181 for nsis-archive@odin.ietf.org; Wed, 3 Apr 2002 17:49:41 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA02956; Wed, 3 Apr 2002 17:39:38 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA02911 for ; Wed, 3 Apr 2002 17:39:33 -0500 (EST) Received: from howler.tri.sbc.com (howler.tri.sbc.com [205.173.58.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17882 for ; Wed, 3 Apr 2002 17:39:28 -0500 (EST) Received: from sbctri.tri.sbc.com (sbctri [144.60.1.10]) by howler.tri.sbc.com (8.11.6+Sun/8.11.0) with ESMTP id g33MgGN00288; Wed, 3 Apr 2002 16:42:16 -0600 (CST) Received: from TRIMAIL2.ad.tri.sbc.com (localhost [127.0.0.1]) by sbctri.tri.sbc.com (8.11.6+Sun/8.9.3) with ESMTP id g33McmJ02419; Wed, 3 Apr 2002 16:38:49 -0600 (CST) Received: by TRIMAIL2.ad.tri.sbc.com with Internet Mail Service (5.5.2653.19) id <2HFW5T8D>; Wed, 3 Apr 2002 16:39:31 -0600 Message-ID: <905A1C4ABF353F4C8CC16FA9F53DD0D638BA5F@TRIMAIL2.ad.tri.sbc.com> From: "Schneider, Marco" To: "'Gary Kenward'" , "'NSIS'" Subject: RE: [NSIS] question on 5.3.3 Date: Wed, 3 Apr 2002 16:39:29 -0600 Sensitivity: Company-Confidential MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DB60.6ADA4F80" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1DB60.6ADA4F80 Content-Type: text/plain; charset="iso-8859-1" Gary, To answer your question I must make assumptions about the solution. For example: 1) In the case of a soft-state solution such as RSVP, Case #1 is explicityly supported. The refresh message acts as a "keep alive". The semantics of the protocol is that a reservation timeouts in a short duration if not refreshed. The refreshments are per flow. Behaviour #2 is not supported. If it were supported exclusively then refresh would not exist. 2) In contrast ATM UNI does not do per flow/connection refresh. My best recollection is as follows. If the signaling channel is detected as having gone down (via some sort of keep alive mechanism) then all associated connections are released. Because ATM "refreshes" the signaling channel and not the flows/connections, for any individual connection the protocol will reach a steady state in which no additional messages are sent. While this may be seen as implicit implementation of behaviour #1 from the overall layered perspective, from the UNI state machine perspective behaviour #2 is being supported. Not sure if this fully answers your question.... Marco -----Original Message----- From: Gary Kenward [mailto:gkenward@nortelnetworks.com] Sent: Wednesday, April 03, 2002 2:34 PM To: Schneider, Marco; 'NSIS' Subject: RE: [NSIS] question on 5.3.3 Sensitivity: Confidential Marco: I fully agree that resource allocations need to have the option for finite life times. However, I am unclear as to how 1) versus 2) would change the semantics of the protocol? As opposed to the semantics of resource reservation algorithms at a given node? To state this in another fashion, if I attached a protocol analyzer to a link carrying NSIS, what protocol semantics could I capture that would reflect this resource timing? Gary > -----Original Message----- > From: Schneider, Marco [ mailto:schneider@tri.sbc.com ] > Sent: April 3, 2002 15:22 > To: Kenward, Gary [WDLN2:AN10:EXCH]; 'NSIS' > Subject: RE: [NSIS] question on 5.3.3 > Sensitivity: Confidential > > > To me this is part of the semantics of the protocol. My > requirement is that > the protocol support the following two behaviours: > > 1) When the QOS Initiator goes down, the resources it > requested will be > released > 2) When the QOS Initiator goes down, the resources it > requested will not be > released > > The reason for supporting behaviour #2 is the case where an > entity in the > network proxy signals on behalf of a large number of > customers. We want the > ability for the corresponding connections to stay up should a > controller > fail. For policy reasons we may want to require that behaviour #1 be > enforced for some customers. Obviously if a customer is paying for a > connection that would want #1 to be enforced as well. > > Cheers, > Marco > > > > > -----Original Message----- > > From: Gary Kenward [ mailto:gkenward@nortelnetworks.com ] > > Sent: Wednesday, April 03, 2002 2:02 PM > > To: 'NSIS' > > Subject: [NSIS] question on 5.3.3 > > Sensitivity: Confidential > > > > > > Hello: > > > > I have a question regarding one of the requirements: > > > > 5.3.3 Possibility for automatic release of resources after failure > > > > When the QoS Initiator goes down, the resources it > requested should > > be released, since they will no longer be necessary. > > > > This does not seem to me to be a protocol requirement nor a > framework > > requirement, but rather an implementation requirement. > > > > Does this matter? > > > > Thanks, > > Gary > > > > > > > > > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > ------_=_NextPart_001_01C1DB60.6ADA4F80 Content-Type: text/html; charset="iso-8859-1" RE: [NSIS] question on 5.3.3
Gary,
 
To answer your question I must make assumptions about the solution. For example:
 
1) In the case of a soft-state solution such as RSVP, Case #1 is explicityly supported. The refresh message acts as a "keep alive". The semantics of the protocol is that a reservation timeouts in a short duration if not refreshed. The refreshments are per flow. Behaviour #2 is not supported. If it were supported exclusively then refresh would not exist.
 
2) In contrast ATM UNI does not do per flow/connection refresh. My best recollection is as follows. If the signaling channel is detected as having gone down (via some sort of keep alive mechanism) then all associated connections are released. Because ATM "refreshes" the signaling channel and not the flows/connections, for any individual connection the protocol will reach a steady state in which no additional messages are sent. While this may be seen as implicit implementation of behaviour #1 from the overall layered perspective, from the UNI state machine perspective behaviour #2 is being supported.
 
Not sure if this fully answers your question....
 
Marco
-----Original Message-----
From: Gary Kenward [mailto:gkenward@nortelnetworks.com]
Sent: Wednesday, April 03, 2002 2:34 PM
To: Schneider, Marco; 'NSIS'
Subject: RE: [NSIS] question on 5.3.3
Sensitivity: Confidential

Marco:

  I fully agree that resource allocations need to have the option for
finite life times.

  However, I am unclear as to how 1) versus 2) would change the semantics
of the protocol? As opposed to the semantics of resource reservation algorithms
at a given node?

  To state this in another fashion, if I attached a protocol
analyzer to a link carrying NSIS, what protocol semantics could
I capture that would reflect this resource timing?

Gary

> -----Original Message-----
> From: Schneider, Marco [mailto:schneider@tri.sbc.com]
> Sent: April 3, 2002 15:22
> To: Kenward, Gary [WDLN2:AN10:EXCH]; 'NSIS'
> Subject: RE: [NSIS] question on 5.3.3
> Sensitivity: Confidential
>
>
> To me this is part of the semantics of the protocol. My
> requirement is that
> the protocol support the following two behaviours:
>
> 1) When the QOS Initiator goes down, the resources it
> requested will be
> released
> 2) When the QOS Initiator goes down, the resources it
> requested will not be
> released
>
> The reason for supporting behaviour #2 is the case where an
> entity in the
> network proxy signals on behalf of a large number of
> customers. We want the
> ability for the corresponding connections to stay up should a
> controller
> fail. For policy reasons we may want to require that behaviour #1 be
> enforced for some customers. Obviously if a customer is paying for a
> connection that would want #1 to be enforced as well.
>
> Cheers,
> Marco
>
>
>
> > -----Original Message-----
> > From: Gary Kenward [mailto:gkenward@nortelnetworks.com]
> > Sent: Wednesday, April 03, 2002 2:02 PM
> > To: 'NSIS'
> > Subject: [NSIS] question on 5.3.3
> > Sensitivity: Confidential
> >
> >
> > Hello:
> >
> > I have a question regarding one of the requirements:
> >
> > 5.3.3 Possibility for automatic release of resources after failure
> >
> >    When the QoS Initiator goes down, the resources it
> requested should
> >    be released, since they will no longer be necessary.
> >
> > This does not seem to me to be a protocol requirement nor a
> framework
> > requirement, but rather an implementation requirement.
> >
> > Does this matter?
> >
> > Thanks,
> > Gary
> >
> >
> >
> >
> >
> > _______________________________________________
> > nsis mailing list
> > nsis@ietf.org
> > https://www1.ietf.org/mailman/listinfo/nsis
> >
>

------_=_NextPart_001_01C1DB60.6ADA4F80-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Wed Apr 3 18:53:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19265 for ; Wed, 3 Apr 2002 18:53:07 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA06657 for nsis-archive@odin.ietf.org; Wed, 3 Apr 2002 18:53:07 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA05581; Wed, 3 Apr 2002 18:32:02 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA05544 for ; Wed, 3 Apr 2002 18:31:57 -0500 (EST) Received: from howler.tri.sbc.com (howler.tri.sbc.com [205.173.58.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18785 for ; Wed, 3 Apr 2002 18:31:54 -0500 (EST) Received: from sbctri.tri.sbc.com (sbctri [144.60.1.10]) by howler.tri.sbc.com (8.11.6+Sun/8.11.0) with ESMTP id g33NYhN00658; Wed, 3 Apr 2002 17:34:43 -0600 (CST) Received: from TRIMAIL2.ad.tri.sbc.com (localhost [127.0.0.1]) by sbctri.tri.sbc.com (8.11.6+Sun/8.9.3) with ESMTP id g33NV7Y04581; Wed, 3 Apr 2002 17:31:07 -0600 (CST) Received: by TRIMAIL2.ad.tri.sbc.com with Internet Mail Service (5.5.2653.19) id <2HFW54FT>; Wed, 3 Apr 2002 17:31:49 -0600 Message-ID: <905A1C4ABF353F4C8CC16FA9F53DD0D638BA61@TRIMAIL2.ad.tri.sbc.com> From: "Schneider, Marco" To: "'Michael Thomas'" Cc: "'Gary Kenward'" , "'NSIS'" Subject: RE: [NSIS] question on 5.3.3 Date: Wed, 3 Apr 2002 17:31:47 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org >>"Define "down". " Good question. Please note that I did not define the original requirement which used the term "down". I took the meaning to be that if the actual box running the software or the software itself stops working then the QOS Initiator is "down". A controller would likely detect this indirectly. For instance a keep alive message is not recieved for a period of time. >>"Does a network partition count?" If a network partition prevents the initiator from sending signaling messaging to the controller then a network partition does count. Marco > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: Wednesday, April 03, 2002 2:32 PM > To: Schneider, Marco > Cc: 'Gary Kenward'; 'NSIS' > Subject: RE: [NSIS] question on 5.3.3 > > > Schneider, Marco writes: > > To me this is part of the semantics of the protocol. My > requirement is that > > the protocol support the following two behaviours: > > > > 1) When the QOS Initiator goes down, the resources it > requested will be > > released > > 2) When the QOS Initiator goes down, the resources it > requested will not be > > released > > Define "down". Does a network partition count? > > Mike > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Wed Apr 3 18:56:18 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19358 for ; Wed, 3 Apr 2002 18:56:18 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA06827 for nsis-archive@odin.ietf.org; Wed, 3 Apr 2002 18:56:21 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA06037; Wed, 3 Apr 2002 18:35:31 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA06005 for ; Wed, 3 Apr 2002 18:35:28 -0500 (EST) Received: from howler.tri.sbc.com (howler.tri.sbc.com [205.173.58.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18921 for ; Wed, 3 Apr 2002 18:35:24 -0500 (EST) Received: from sbctri.tri.sbc.com (sbctri [144.60.1.10]) by howler.tri.sbc.com (8.11.6+Sun/8.11.0) with ESMTP id g33NcDN00692; Wed, 3 Apr 2002 17:38:13 -0600 (CST) Received: from TRIMAIL2.ad.tri.sbc.com (localhost [127.0.0.1]) by sbctri.tri.sbc.com (8.11.6+Sun/8.9.3) with ESMTP id g33NYjA04722; Wed, 3 Apr 2002 17:34:45 -0600 (CST) Received: by TRIMAIL2.ad.tri.sbc.com with Internet Mail Service (5.5.2653.19) id <2HFW54GF>; Wed, 3 Apr 2002 17:35:27 -0600 Message-ID: <905A1C4ABF353F4C8CC16FA9F53DD0D638BA62@TRIMAIL2.ad.tri.sbc.com> From: "Schneider, Marco" To: "'Gary Kenward'" , "'marc.greis@nokia.com'" , nsis@ietf.org Subject: RE: [NSIS] question on 5.3.3 Date: Wed, 3 Apr 2002 17:35:26 -0600 Sensitivity: Company-Confidential MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DB68.3B9CFB70" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1DB68.3B9CFB70 Content-Type: text/plain; charset="iso-8859-1" Yes that's it, the protocol must support options for fault recovery including the maintenance and the release of existing flows. Marco -----Original Message----- From: Gary Kenward [mailto:gkenward@nortelnetworks.com] Sent: Wednesday, April 03, 2002 4:06 PM To: 'marc.greis@nokia.com'; Schneider, Marco; nsis@ietf.org Subject: RE: [NSIS] question on 5.3.3 Sensitivity: Confidential Marc: Ok, but I think that this is a specific interpretation of the requirement that is not captured in the wording. What you are referring to is more along the lines of protocol support for fault recovery. May be useful (if the initiator is down, who are the protocol peers? if the initiator is in the path, how can the protocol be used? etc.) Anyway, thanks. Gary -----Original Message----- From: marc.greis@nokia.com [mailto:marc.greis@nokia.com] Sent: April 3, 2002 16:14 To: Kenward, Gary [WDLN2:AN10:EXCH]; schneider@tri.sbc.com; nsis@ietf.org Subject: RE: [NSIS] question on 5.3.3 Sensitivity: Confidential Gary, I assume that based based on this requirement, there needs to be a mechanism in the protocol to determine if the QoS Initiator is actually down. So to come back to your original question, I do think that this is actually a protocol requirement and not merely an implementation issue. Marc -----Original Message----- From: ext Gary Kenward [mailto:gkenward@nortelnetworks.com] Sent: 03 April, 2002 2:34 PM To: 'Schneider, Marco'; 'NSIS' Subject: RE: [NSIS] question on 5.3.3 Marco: I fully agree that resource allocations need to have the option for finite life times. However, I am unclear as to how 1) versus 2) would change the semantics of the protocol? As opposed to the semantics of resource reservation algorithms at a given node? To state this in another fashion, if I attached a protocol analyzer to a link carrying NSIS, what protocol semantics could I capture that would reflect this resource timing? Gary > -----Original Message----- > From: Schneider, Marco [ mailto:schneider@tri.sbc.com ] > Sent: April 3, 2002 15:22 > To: Kenward, Gary [WDLN2:AN10:EXCH]; 'NSIS' > Subject: RE: [NSIS] question on 5.3.3 > Sensitivity: Confidential > > > To me this is part of the semantics of the protocol. My > requirement is that > the protocol support the following two behaviours: > > 1) When the QOS Initiator goes down, the resources it > requested will be > released > 2) When the QOS Initiator goes down, the resources it > requested will not be > released > > The reason for supporting behaviour #2 is the case where an > entity in the > network proxy signals on behalf of a large number of > customers. We want the > ability for the corresponding connections to stay up should a > controller > fail. For policy reasons we may want to require that behaviour #1 be > enforced for some customers. Obviously if a customer is paying for a > connection that would want #1 to be enforced as well. > > Cheers, > Marco > > > > > -----Original Message----- > > From: Gary Kenward [ mailto:gkenward@nortelnetworks.com ] > > Sent: Wednesday, April 03, 2002 2:02 PM > > To: 'NSIS' > > Subject: [NSIS] question on 5.3.3 > > Sensitivity: Confidential > > > > > > Hello: > > > > I have a question regarding one of the requirements: > > > > 5.3.3 Possibility for automatic release of resources after failure > > > > When the QoS Initiator goes down, the resources it > requested should > > be released, since they will no longer be necessary. > > > > This does not seem to me to be a protocol requirement nor a > framework > > requirement, but rather an implementation requirement. > > > > Does this matter? > > > > Thanks, > > Gary > > > > > > > > > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > ------_=_NextPart_001_01C1DB68.3B9CFB70 Content-Type: text/html; charset="iso-8859-1" RE: [NSIS] question on 5.3.3
Yes that's it, the protocol must support options for fault recovery including the maintenance and the release of existing flows.
 
Marco
-----Original Message-----
From: Gary Kenward [mailto:gkenward@nortelnetworks.com]
Sent: Wednesday, April 03, 2002 4:06 PM
To: 'marc.greis@nokia.com'; Schneider, Marco; nsis@ietf.org
Subject: RE: [NSIS] question on 5.3.3
Sensitivity: Confidential

Marc:
 
Ok, but I think that this is a specific interpretation of the requirement that is not captured in the wording.
What you are referring to is more along the lines of protocol support for fault recovery. May be useful
(if the initiator is down, who are the protocol peers? if the initiator is in the path, how can the protocol
be used? etc.)
 
Anyway, thanks.
Gary
-----Original Message-----
From: marc.greis@nokia.com [mailto:marc.greis@nokia.com]
Sent: April 3, 2002 16:14
To: Kenward, Gary [WDLN2:AN10:EXCH]; schneider@tri.sbc.com; nsis@ietf.org
Subject: RE: [NSIS] question on 5.3.3
Sensitivity: Confidential

Gary,
 
I assume that based based on this requirement, there needs to be a mechanism in the protocol to determine if the QoS Initiator is actually down. So to come back to your original question, I do think that this is actually a protocol requirement and not merely an implementation issue.
 
Marc
 
-----Original Message-----
From: ext Gary Kenward [mailto:gkenward@nortelnetworks.com]
Sent: 03 April, 2002 2:34 PM
To: 'Schneider, Marco'; 'NSIS'
Subject: RE: [NSIS] question on 5.3.3

Marco:

  I fully agree that resource allocations need to have the option for
finite life times.

  However, I am unclear as to how 1) versus 2) would change the semantics
of the protocol? As opposed to the semantics of resource reservation algorithms
at a given node?

  To state this in another fashion, if I attached a protocol
analyzer to a link carrying NSIS, what protocol semantics could
I capture that would reflect this resource timing?

Gary

> -----Original Message-----
> From: Schneider, Marco [mailto:schneider@tri.sbc.com]
> Sent: April 3, 2002 15:22
> To: Kenward, Gary [WDLN2:AN10:EXCH]; 'NSIS'
> Subject: RE: [NSIS] question on 5.3.3
> Sensitivity: Confidential
>
>
> To me this is part of the semantics of the protocol. My
> requirement is that
> the protocol support the following two behaviours:
>
> 1) When the QOS Initiator goes down, the resources it
> requested will be
> released
> 2) When the QOS Initiator goes down, the resources it
> requested will not be
> released
>
> The reason for supporting behaviour #2 is the case where an
> entity in the
> network proxy signals on behalf of a large number of
> customers. We want the
> ability for the corresponding connections to stay up should a
> controller
> fail. For policy reasons we may want to require that behaviour #1 be
> enforced for some customers. Obviously if a customer is paying for a
> connection that would want #1 to be enforced as well.
>
> Cheers,
> Marco
>
>
>
> > -----Original Message-----
> > From: Gary Kenward [mailto:gkenward@nortelnetworks.com]
> > Sent: Wednesday, April 03, 2002 2:02 PM
> > To: 'NSIS'
> > Subject: [NSIS] question on 5.3.3
> > Sensitivity: Confidential
> >
> >
> > Hello:
> >
> > I have a question regarding one of the requirements:
> >
> > 5.3.3 Possibility for automatic release of resources after failure
> >
> >    When the QoS Initiator goes down, the resources it
> requested should
> >    be released, since they will no longer be necessary.
> >
> > This does not seem to me to be a protocol requirement nor a
> framework
> > requirement, but rather an implementation requirement.
> >
> > Does this matter?
> >
> > Thanks,
> > Gary
> >
> >
> >
> >
> >
> > _______________________________________________
> > nsis mailing list
> > nsis@ietf.org
> > https://www1.ietf.org/mailman/listinfo/nsis
> >
>

------_=_NextPart_001_01C1DB68.3B9CFB70-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu Apr 4 01:49:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27247 for ; Thu, 4 Apr 2002 01:49:38 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA07804 for nsis-archive@odin.ietf.org; Thu, 4 Apr 2002 01:49:40 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA07005; Thu, 4 Apr 2002 01:30:38 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA06917 for ; Thu, 4 Apr 2002 01:30:30 -0500 (EST) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27026 for ; Thu, 4 Apr 2002 01:30:27 -0500 (EST) From: john.loughney@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g346Ug525040 for ; Thu, 4 Apr 2002 09:30:43 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 4 Apr 2002 09:30:27 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Thu, 4 Apr 2002 09:30:27 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Thu, 4 Apr 2002 09:30:26 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64DB5@esebe004.NOE.Nokia.com> Thread-Topic: [Tsvwg] notes from L2 Triggers meeting Thread-Index: AcHba6PA3pPqA94dReGqAdT+dIZb2gANoHyw To: X-OriginalArrivalTime: 04 Apr 2002 06:30:27.0145 (UTC) FILETIME=[3579E390:01C1DBA2] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id BAA06918 Subject: [NSIS] notes from L2 Triggers meeting Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit L2-Trigger unofficial meeting Tuesday, March 18th, 2002 IETF-53 Minneapolis, MN led by (& notes taken by) Aaron Falk and Carl Williams attendance: about 55 people (beer courtesy of NTT DoCoMo) ============================= Based on interest from folks engaged in manet, mobileip, and seamoby working groups, an unofficial meeting was held to discuss issues surrounding the triggers at layer 2 to communicate information to upper layers in a hosts protocol stack. Two drafts, one discussing the issues (draft-manyfolks-l2-mobilereq-01.txt) and another proposing an API (draft-guri-seamoby-paging-trigger-00.txt) had been previously submitted. The objective of the meeting was to discover if the scope should be more broad than the drafts proposed. This was accomplished by a somewhat unstructured discussion that touched on several topics including what information to express, how it is delivered, and some possible next steps. The conversation and some perceived conclusions are summarized below. WHAT TO EXPRESS Not a new problem, past experience likely useful: The need for communication about L2 state to L3 is not new. Routers have been handling it, largely with proprietary means for years. Routers are in fact the canonical customers for this function; they by definition perform their principal L3 function based on L2 state info. Routing folks have learned a lot about how links lie about their state (e.g., links that fail half-duplex). In fact, router manufacturers may have insight as to which metrics would be of interest or possibly how to extend or abstract them if they are willing to share the information. Getting input from people familiar with routing would be valuable. Small set of common functions seen as useful: The most common need expressed for information to be revealed was a link up/down indicator. This might be extended to be a table containing reachability to multiple access points for technologies where that is possible. (There already exists an appropriate SNMP message but it appears to be largely unused.) Interaction with MobileIP: In mobileIP on a wireless link, an L3 handover may, but does not always, occur when the mobile node moves to a new access point. Link layer protocols provide more accurate, and possibly timelier, reachability information than L3 'hello' protocols. There is great benefit if a mobileIP L3 can learn that a handover is imminent, rather than waiting until after the old link is gone. Early warning may allow mobileIP to optimize the L3 hand-off process in a number of ways, such as triggering an L3 early hand-off or moving context to the new router. Discussion about architectural principles and amount of revealed information: It was suggested that it might be valuable to reveal *any* information that might be of interest to any part of the host, e.g., bit error rate, or link bandwidth. For example, a video codec (e.g., MPEG-4) might behave differently if it was aware of the bit error rate of the wireless link. This was widely thought to be a bad idea as it suggests an architecture which is not general - leading to applications that are too tightly bound to specific link types or depend on the assumption that the 'difficult' link is the one nearest the end host. The Internet layer, as the 'waist in the protocol hourglass' insulates the application from the link layer. The question of what information ought to be passed up from L3 is separate from what info L3 could usefully get from L2, and should be considered separately. Only a very limited, general set of parameters would be appropriate above L3 and defining appropriate parameters based on link characteristics is a very difficult task. Even adding a metric such as signal strength is difficult when link technologies are heterogeneous. Some other caveats that were suggested: Triggers should only enable performance enhancements and not be used for correct protocol operation. There's value in finding implicit rather than explicit mechanisms. Again: the focus should be firmly on L2/L3 communication, rather than enabling applications (or, presumably, transport) to interact directly with L2. Apps can fight with L3 if it's done wrong. Management applications considered a special case: In the context of the above discussion, management applications were seen as a special case that might require greater access to link information than would normally be made available to normal applications (or even protocol stack internals). This is because the application is intentionally associated with the management of a specific L2 technology. For example, 802.11 cards typically come with a management application that reveals information about the card status, link status, and access point(s). This information is necessary to ensure the correct functioning of the card and should not be considered an Internet network application. HOW IS L2 INFORMATION DELIVERED Options for how to implement L2/3 communication include an API, a MIB, or a protocol. Most of the applications discussed above do not require communication across the wire and so a protocol does not seem to be justified or appropriate. It's unclear whether an API or MIB is more appropriate. MIBs were considered by some as somewhat 'heavyweight' because accessing local information typically requires SNMP to localhost and implies ASN.1 marshaling that is not needed in this situation. This issue is particularly important to small memory and power-limited wireless devices. Most participants agreed that the difficult task that needs to be done is to determine the right set of metrics to abstract and capture them in a common location. It was widely recognized that the question of MIB or API is really secondary to the question of what information should be passed between L2 and L3. In the IETF, that process is frequently captured in a MIB. However, since the issue is really a matter of internal communication within a host, it may not be necessary to standardize or even specify the format or mechanism which is used to communicate across the L2/L3 boundary. SOME NEXT STEPS Since the IETF doesn't develop link technologies, one output of an IETF effort might include an informational RFC on which information to export/reveal. This document will likely be of interest to other standards bodies who standardize link technologies. (Some of these ideas have already been taken to IEEE 802.11. The IEEE is also working on related issues in the context of OAM.) This might be considered a natural extension of the PILC working group document "Advice to Subnet Designers." The IESG will provide advice as to the next process steps. They could include doing the work in PILC, possibly requiring rechartering, holding a BoF, creating a new working group, or possibly just an individual RFC submission. For the moment, the discussion should take place on the PILC mail list. Subscription instructions are available through the working group charter page at http://www.ietf.org/html.charters/pilc-charter.html. Should the work take place in a seperate working group, naturally a new mailing list will be formed. --aaron (for aaron and carl) Postscript In the wireless directorate meeting (of chairs of wireless-related working groups, it was suggested that besides advising link designers, we should also consider an advisory document to upper layers on how to handle L2 information. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu Apr 4 02:44:09 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06231 for ; Thu, 4 Apr 2002 02:44:05 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA10570 for nsis-archive@odin.ietf.org; Thu, 4 Apr 2002 02:44:07 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA09637; Thu, 4 Apr 2002 02:26:34 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA09606 for ; Thu, 4 Apr 2002 02:26:31 -0500 (EST) Received: from relay1.alcatel.be (alc119.alcatel.be [195.207.101.119]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06001 for ; Thu, 4 Apr 2002 02:26:27 -0500 (EST) From: sven.van_den_bosch@alcatel.be Received: from bemail04.net.alcatel.be (localhost [127.0.0.1]) by relay1.alcatel.be (8.10.1/8.10.1) with ESMTP id g347PUG24491; Thu, 4 Apr 2002 09:25:30 +0200 (MET DST) To: "Schneider, Marco" Cc: "'Gary Kenward'" , "'marc.greis@nokia.com'" , nsis@ietf.org X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Thu, 4 Apr 2002 09:25:29 +0200 Subject: RE: [NSIS] question on 5.3.3 X-MIMETrack: Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 04/04/2002 09:25:30 MIME-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=C1256B910028117F8f9e8a93df938690918cC1256B910028117F" Content-Disposition: inline Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org --0__=C1256B910028117F8f9e8a93df938690918cC1256B910028117F Content-type: text/plain; charset=us-ascii Hi Marco, all, I think this touches on the resiliency issue we discussed in Minneapolis. When the data plane and control plane are separate then it is a question of fate sharing. Should or shouldn't the data path be torn down when a control plane entity fails. I certainly wouldn't limit this to the QI only, it is also important for the QC. Also, we may need to consider different types of failures with different reactions. Personally, I think that the behaviour under failure conditions is a framework issue. For the moment I think that in terms of requirements, the suggestion that both maintenance and release of existing flows should be supported is a good starting point. I thought, however, that we were going to put all the failure behaviour under open issues for the requirements. Sven. "Schneider, Marco" on 04/04/2002 01:35:26 To: "'Gary Kenward'" , "'marc.greis@nokia.com'" , nsis@ietf.org cc: (bcc: Sven VAN DEN BOSCH/BE/ALCATEL) Subject RE: [NSIS] question on 5.3.3 : Yes that's it, the protocol must support options for fault recovery including the maintenance and the release of existing flows. Marco -----Original Message----- From: Gary Kenward [mailto:gkenward@nortelnetworks.com] Sent: Wednesday, April 03, 2002 4:06 PM To: 'marc.greis@nokia.com'; Schneider, Marco; nsis@ietf.org Subject: RE: [NSIS] question on 5.3.3 Sensitivity: Confidential Marc: Ok, but I think that this is a specific interpretation of the requirement that is not captured in the wording. What you are referring to is more along the lines of protocol support for fault recovery. May be useful (if the initiator is down, who are the protocol peers? if the initiator is in the path, how can the protocol be used? etc.) Anyway, thanks. Gary -----Original Message----- From: marc.greis@nokia.com [mailto:marc.greis@nokia.com] Sent: April 3, 2002 16:14 To: Kenward, Gary [WDLN2:AN10:EXCH]; schneider@tri.sbc.com; nsis@ietf.org Subject: RE: [NSIS] question on 5.3.3 Sensitivity: Confidential Gary, I assume that based based on this requirement, there needs to be a mechanism in the protocol to determine if the QoS Initiator is actually down. So to come back to your original question, I do think that this is actually a protocol requirement and not merely an implementation issue. Marc -----Original Message----- From: ext Gary Kenward [mailto:gkenward@nortelnetworks.com] Sent: 03 April, 2002 2:34 PM To: 'Schneider, Marco'; 'NSIS' Subject: RE: [NSIS] question on 5.3.3 Marco: I fully agree that resource allocations need to have the option for finite life times. However, I am unclear as to how 1) versus 2) would change the semantics of the protocol? As opposed to the semantics of resource reservation algorithms at a given node? To state this in another fashion, if I attached a protocol analyzer to a link carrying NSIS, what protocol semantics could I capture that would reflect this resource timing? Gary > -----Original Message----- > From: Schneider, Marco [ mailto:schneider@tri.sbc.com ] > Sent: April 3, 2002 15:22 > To: Kenward, Gary [WDLN2:AN10:EXCH]; 'NSIS' > Subject: RE: [NSIS] question on 5.3.3 > Sensitivity: Confidential > > > To me this is part of the semantics of the protocol. My > requirement is that > the protocol support the following two behaviours: > > 1) When the QOS Initiator goes down, the resources it > requested will be > released > 2) When the QOS Initiator goes down, the resources it > requested will not be > released > > The reason for supporting behaviour #2 is the case where an > entity in the > network proxy signals on behalf of a large number of > customers. We want the > ability for the corresponding connections to stay up should a > controller > fail. For policy reasons we may want to require that behaviour #1 be > enforced for some customers. Obviously if a customer is paying for a > connection that would want #1 to be enforced as well. > > Cheers, > Marco > > > > > -----Original Message----- > > From: Gary Kenward [ mailto:gkenward@nortelnetworks.com ] > > Sent: Wednesday, April 03, 2002 2:02 PM > > To: 'NSIS' > > Subject: [NSIS] question on 5.3.3 > > Sensitivity: Confidential > > > > > > Hello: > > > > I have a question regarding one of the requirements: > > > > 5.3.3 Possibility for automatic release of resources after failure > > > > When the QoS Initiator goes down, the resources it > requested should > > be released, since they will no longer be necessary. > > > > This does not seem to me to be a protocol requirement nor a > framework > > requirement, but rather an implementation requirement. > > > > Does this matter? > > > > Thanks, > > Gary > > > > > > > > > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > (See attached file: att1.htm) --0__=C1256B910028117F8f9e8a93df938690918cC1256B910028117F Content-type: text/html; name="att1.htm" Content-Disposition: attachment; filename="att1.htm" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05U RU5UPSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9aXNvLTg4NTktMSI+DQo8VElUTEU+UkU6IFtOU0lTXSBx dWVzdGlvbiBvbiA1LjMuMzwvVElUTEU+DQoNCjxNRVRBIGNvbnRlbnQ9Ik1TSFRNTCA1LjUwLjQ3 MjUuMjEwMCIgbmFtZT1HRU5FUkFUT1I+PC9IRUFEPg0KPEJPRFk+DQo8RElWPjxTUEFOIGNsYXNz PTkyMTIzMzQyMy0wMzA0MjAwMj48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgc2l6ZT0y PlllcyANCnRoYXQncyBpdCwgdGhlIHByb3RvY29sIG11c3Qgc3VwcG9ydCBvcHRpb25zIGZvciBm YXVsdCByZWNvdmVyeSBpbmNsdWRpbmcgdGhlIA0KbWFpbnRlbmFuY2UgYW5kIHRoZSByZWxlYXNl IG9mIGV4aXN0aW5nIGZsb3dzLjwvRk9OVD48L1NQQU4+PC9ESVY+DQo8RElWPjxTUEFOIGNsYXNz PTkyMTIzMzQyMy0wMzA0MjAwMj48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgDQpzaXpl PTI+PC9GT05UPjwvU1BBTj4mbmJzcDs8L0RJVj4NCjxESVY+PFNQQU4gY2xhc3M9OTIxMjMzNDIz LTAzMDQyMDAyPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiANCnNpemU9Mj5NYXJjbzwv Rk9OVD48L1NQQU4+PC9ESVY+DQo8QkxPQ0tRVU9URSBkaXI9bHRyIA0Kc3R5bGU9IlBBRERJTkct TEVGVDogNXB4OyBNQVJHSU4tTEVGVDogNXB4OyBCT1JERVItTEVGVDogIzAwMDBmZiAycHggc29s aWQ7IE1BUkdJTi1SSUdIVDogMHB4Ij4NCiAgPERJViBjbGFzcz1PdXRsb29rTWVzc2FnZUhlYWRl ciBkaXI9bHRyIGFsaWduPWxlZnQ+PEZPTlQgZmFjZT1UYWhvbWEgDQogIHNpemU9Mj4tLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLTxCUj48Qj5Gcm9tOjwvQj4gR2FyeSBLZW53YXJkIA0KICBbbWFp bHRvOmdrZW53YXJkQG5vcnRlbG5ldHdvcmtzLmNvbV08QlI+PEI+U2VudDo8L0I+IFdlZG5lc2Rh eSwgQXByaWwgMDMsIDIwMDIgDQogIDQ6MDYgUE08QlI+PEI+VG86PC9CPiAnbWFyYy5ncmVpc0Bu b2tpYS5jb20nOyBTY2huZWlkZXIsIE1hcmNvOyANCiAgbnNpc0BpZXRmLm9yZzxCUj48Qj5TdWJq ZWN0OjwvQj4gUkU6IFtOU0lTXSBxdWVzdGlvbiBvbiANCiAgNS4zLjM8QlI+PEI+U2Vuc2l0aXZp dHk6PC9CPiBDb25maWRlbnRpYWw8QlI+PEJSPjwvRk9OVD48L0RJVj4NCiAgPERJVj48Rk9OVCBm YWNlPSJDb21pYyBTYW5zIE1TIiBjb2xvcj0jMDAwMGZmPjxTUEFOIA0KICBjbGFzcz0yOTYxNDEx MjItMDMwNDIwMDI+TWFyYzo8L1NQQU4+PC9GT05UPjwvRElWPg0KICA8RElWPjxGT05UIGZhY2U9 IkNvbWljIFNhbnMgTVMiIGNvbG9yPSMwMDAwZmY+PFNQQU4gDQogIGNsYXNzPTI5NjE0MTEyMi0w MzA0MjAwMj48L1NQQU4+PC9GT05UPiZuYnNwOzwvRElWPg0KICA8RElWPjxGT05UIGZhY2U9IkNv bWljIFNhbnMgTVMiIGNvbG9yPSMwMDAwZmY+PFNQQU4gDQogIGNsYXNzPTI5NjE0MTEyMi0wMzA0 MjAwMj5PaywgYnV0IEkgdGhpbmsgdGhhdCB0aGlzIGlzIGEgc3BlY2lmaWMgDQogIGludGVycHJl dGF0aW9uIG9mIHRoZSByZXF1aXJlbWVudCB0aGF0IGlzIG5vdCBjYXB0dXJlZCBpbiB0aGUgDQog IHdvcmRpbmcuPC9TUEFOPjwvRk9OVD48L0RJVj4NCiAgPERJVj48Rk9OVCBmYWNlPSJDb21pYyBT YW5zIE1TIiBjb2xvcj0jMDAwMGZmPjxTUEFOIA0KICBjbGFzcz0yOTYxNDExMjItMDMwNDIwMDI+ V2hhdCB5b3UgYXJlIHJlZmVycmluZyB0byBpcyBtb3JlIGFsb25nIHRoZSBsaW5lcyBvZiANCiAg cHJvdG9jb2wgc3VwcG9ydCBmb3IgZmF1bHQgcmVjb3ZlcnkuIE1heSBiZSB1c2VmdWw8L1NQQU4+ PC9GT05UPjwvRElWPg0KICA8RElWPjxGT05UIGZhY2U9IkNvbWljIFNhbnMgTVMiIGNvbG9yPSMw MDAwZmY+PFNQQU4gDQogIGNsYXNzPTI5NjE0MTEyMi0wMzA0MjAwMj4oaWYgdGhlIGluaXRpYXRv ciBpcyBkb3duLCB3aG8gYXJlIHRoZSBwcm90b2NvbCANCiAgcGVlcnM/IGlmIHRoZSBpbml0aWF0 b3IgaXMgaW4gdGhlIHBhdGgsIGhvdyBjYW4gdGhlIHByb3RvY29sIA0KICA8L1NQQU4+PC9GT05U PjwvRElWPg0KICA8RElWPjxGT05UIGZhY2U9IkNvbWljIFNhbnMgTVMiIGNvbG9yPSMwMDAwZmY+ PFNQQU4gDQogIGNsYXNzPTI5NjE0MTEyMi0wMzA0MjAwMj5iZSB1c2VkPyBldGMuKTwvU1BBTj48 L0ZPTlQ+PC9ESVY+DQogIDxESVY+PEZPTlQgZmFjZT0iQ29taWMgU2FucyBNUyIgY29sb3I9IzAw MDBmZj48U1BBTiANCiAgY2xhc3M9Mjk2MTQxMTIyLTAzMDQyMDAyPjwvU1BBTj48L0ZPTlQ+Jm5i c3A7PC9ESVY+DQogIDxESVY+PEZPTlQgZmFjZT0iQ29taWMgU2FucyBNUyIgY29sb3I9IzAwMDBm Zj48U1BBTiANCiAgY2xhc3M9Mjk2MTQxMTIyLTAzMDQyMDAyPkFueXdheSwgdGhhbmtzLjwvU1BB Tj48L0ZPTlQ+PC9ESVY+DQogIDxESVY+PEZPTlQgZmFjZT0iQ29taWMgU2FucyBNUyIgY29sb3I9 IzAwMDBmZj48U1BBTiANCiAgY2xhc3M9Mjk2MTQxMTIyLTAzMDQyMDAyPkdhcnk8L1NQQU4+PC9G T05UPjwvRElWPg0KICA8QkxPQ0tRVU9URSANCiAgc3R5bGU9IlBBRERJTkctTEVGVDogNXB4OyBN QVJHSU4tTEVGVDogNXB4OyBCT1JERVItTEVGVDogIzAwMDBmZiAycHggc29saWQ7IE1BUkdJTi1S SUdIVDogMHB4Ij4NCiAgICA8RElWIGNsYXNzPU91dGxvb2tNZXNzYWdlSGVhZGVyIGRpcj1sdHIg YWxpZ249bGVmdD48Rk9OVCBmYWNlPVRhaG9tYSANCiAgICBzaXplPTI+LS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS08QlI+PEI+RnJvbTo8L0I+IG1hcmMuZ3JlaXNAbm9raWEuY29tIA0KICAgIFtt YWlsdG86bWFyYy5ncmVpc0Bub2tpYS5jb21dPEJSPjxCPlNlbnQ6PC9CPiBBcHJpbCAzLCAyMDAy IA0KICAgIDE2OjE0PEJSPjxCPlRvOjwvQj4gS2Vud2FyZCwgR2FyeSBbV0RMTjI6QU4xMDpFWENI XTsgc2NobmVpZGVyQHRyaS5zYmMuY29tOyANCiAgICBuc2lzQGlldGYub3JnPEJSPjxCPlN1Ympl Y3Q6PC9CPiBSRTogW05TSVNdIHF1ZXN0aW9uIG9uIA0KICAgIDUuMy4zPEJSPjxCPlNlbnNpdGl2 aXR5OjwvQj4gQ29uZmlkZW50aWFsPEJSPjxCUj48L0RJVj48L0ZPTlQ+DQogICAgPERJVj48Rk9O VCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPjxTUEFOIA0KICAgIGNsYXNzPTc3MDMz MDgyMS0wMzA0MjAwMj5HYXJ5LDwvU1BBTj48L0ZPTlQ+PC9ESVY+DQogICAgPERJVj48Rk9OVCBm YWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPjxTUEFOIA0KICAgIGNsYXNzPTc3MDMzMDgy MS0wMzA0MjAwMj48L1NQQU4+PC9GT05UPiZuYnNwOzwvRElWPg0KICAgIDxESVY+PEZPTlQgZmFj ZT1BcmlhbCBjb2xvcj0jMDAwMGZmIHNpemU9Mj48U1BBTiBjbGFzcz03NzAzMzA4MjEtMDMwNDIw MDI+SSANCiAgICBhc3N1bWUgdGhhdCBiYXNlZCBiYXNlZCBvbiB0aGlzIHJlcXVpcmVtZW50LCB0 aGVyZSBuZWVkcyB0byBiZSBhIG1lY2hhbmlzbSANCiAgICBpbiB0aGUgcHJvdG9jb2wgdG8gZGV0 ZXJtaW5lIGlmIHRoZSBRb1MgSW5pdGlhdG9yIGlzIGFjdHVhbGx5IGRvd24uIFNvIHRvIA0KICAg IGNvbWUgYmFjayB0byB5b3VyIG9yaWdpbmFsIHF1ZXN0aW9uLCBJIGRvIHRoaW5rIHRoYXQgdGhp cyBpcyBhY3R1YWxseSBhIA0KICAgIHByb3RvY29sIHJlcXVpcmVtZW50IGFuZCBub3QgbWVyZWx5 IGFuIGltcGxlbWVudGF0aW9uIA0KICAgIGlzc3VlLjwvU1BBTj48L0ZPTlQ+PC9ESVY+DQogICAg PERJVj4mbmJzcDs8L0RJVj4NCiAgICA8RElWPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBm ZiBzaXplPTI+PFNQQU4gDQogICAgY2xhc3M9NzcwMzMwODIxLTAzMDQyMDAyPk1hcmM8L1NQQU4+ PC9GT05UPjwvRElWPg0KICAgIDxESVY+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIHNp emU9Mj48U1BBTiANCiAgICBjbGFzcz03NzAzMzA4MjEtMDMwNDIwMDI+PC9TUEFOPjwvRk9OVD4m bmJzcDs8L0RJVj4NCiAgICA8QkxPQ0tRVU9URSANCiAgICBzdHlsZT0iUEFERElORy1MRUZUOiA1 cHg7IE1BUkdJTi1MRUZUOiA1cHg7IEJPUkRFUi1MRUZUOiAjMDAwMGZmIDJweCBzb2xpZDsgTUFS R0lOLVJJR0hUOiAwcHgiPg0KICAgICAgPERJViBjbGFzcz1PdXRsb29rTWVzc2FnZUhlYWRlciBk aXI9bHRyIGFsaWduPWxlZnQ+PEZPTlQgZmFjZT1UYWhvbWEgDQogICAgICBzaXplPTI+LS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS08QlI+PEI+RnJvbTo8L0I+IGV4dCBHYXJ5IEtlbndhcmQgDQog ICAgICBbbWFpbHRvOmdrZW53YXJkQG5vcnRlbG5ldHdvcmtzLmNvbV08QlI+PEI+U2VudDo8L0I+ IDAzIEFwcmlsLCAyMDAyIDI6MzQgDQogICAgICBQTTxCUj48Qj5Ubzo8L0I+ICdTY2huZWlkZXIs IE1hcmNvJzsgJ05TSVMnPEJSPjxCPlN1YmplY3Q6PC9CPiBSRTogW05TSVNdIA0KICAgICAgcXVl c3Rpb24gb24gNS4zLjM8QlI+PC9ESVY+PC9GT05UPg0KICAgICAgPFA+PEZPTlQgc2l6ZT0yPk1h cmNvOjwvRk9OVD4gPC9QPg0KICAgICAgPFA+PEZPTlQgc2l6ZT0yPiZuYnNwOyBJIGZ1bGx5IGFn cmVlIHRoYXQgcmVzb3VyY2UgYWxsb2NhdGlvbnMgbmVlZCB0byANCiAgICAgIGhhdmUgdGhlIG9w dGlvbiBmb3I8L0ZPTlQ+IDxCUj48Rk9OVCBzaXplPTI+ZmluaXRlIGxpZmUgdGltZXMuIDwvRk9O VD48L1A+DQogICAgICA8UD48Rk9OVCBzaXplPTI+Jm5ic3A7IEhvd2V2ZXIsIEkgYW0gdW5jbGVh ciBhcyB0byBob3cgMSkgdmVyc3VzIDIpIHdvdWxkIA0KICAgICAgY2hhbmdlIHRoZSBzZW1hbnRp Y3MgPC9GT05UPjxCUj48Rk9OVCBzaXplPTI+b2YgdGhlIHByb3RvY29sPyBBcyBvcHBvc2VkIA0K ICAgICAgdG8gdGhlIHNlbWFudGljcyBvZiByZXNvdXJjZSByZXNlcnZhdGlvbiBhbGdvcml0aG1z PC9GT05UPiA8QlI+PEZPTlQgDQogICAgICBzaXplPTI+YXQgYSBnaXZlbiBub2RlPzwvRk9OVD4g PC9QPg0KICAgICAgPFA+PEZPTlQgc2l6ZT0yPiZuYnNwOyBUbyBzdGF0ZSB0aGlzIGluIGFub3Ro ZXIgZmFzaGlvbiwgaWYgSSBhdHRhY2hlZCBhIA0KICAgICAgcHJvdG9jb2w8L0ZPTlQ+IDxCUj48 Rk9OVCBzaXplPTI+YW5hbHl6ZXIgdG8gYSBsaW5rIGNhcnJ5aW5nIE5TSVMsIHdoYXQgDQogICAg ICBwcm90b2NvbCBzZW1hbnRpY3MgY291bGQ8L0ZPTlQ+IDxCUj48Rk9OVCBzaXplPTI+SSBjYXB0 dXJlIHRoYXQgd291bGQgDQogICAgICByZWZsZWN0IHRoaXMgcmVzb3VyY2UgdGltaW5nPzwvRk9O VD4gPC9QPg0KICAgICAgPFA+PEZPTlQgc2l6ZT0yPkdhcnk8L0ZPTlQ+IDwvUD4NCiAgICAgIDxQ PjxGT05UIHNpemU9Mj4mZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPC9GT05UPiA8QlI+ PEZPTlQgDQogICAgICBzaXplPTI+Jmd0OyBGcm9tOiBTY2huZWlkZXIsIE1hcmNvIFs8QSANCiAg ICAgIGhyZWY9Im1haWx0bzpzY2huZWlkZXJAdHJpLnNiYy5jb20iPm1haWx0bzpzY2huZWlkZXJA dHJpLnNiYy5jb208L0E+XTwvRk9OVD4gDQogICAgICA8QlI+PEZPTlQgc2l6ZT0yPiZndDsgU2Vu dDogQXByaWwgMywgMjAwMiAxNToyMjwvRk9OVD4gPEJSPjxGT05UIA0KICAgICAgc2l6ZT0yPiZn dDsgVG86IEtlbndhcmQsIEdhcnkgW1dETE4yOkFOMTA6RVhDSF07ICdOU0lTJzwvRk9OVD4gPEJS PjxGT05UIA0KICAgICAgc2l6ZT0yPiZndDsgU3ViamVjdDogUkU6IFtOU0lTXSBxdWVzdGlvbiBv biA1LjMuMzwvRk9OVD4gPEJSPjxGT05UIA0KICAgICAgc2l6ZT0yPiZndDsgU2Vuc2l0aXZpdHk6 IENvbmZpZGVudGlhbDwvRk9OVD4gPEJSPjxGT05UIHNpemU9Mj4mZ3Q7IA0KICAgICAgPC9GT05U PjxCUj48Rk9OVCBzaXplPTI+Jmd0OyA8L0ZPTlQ+PEJSPjxGT05UIHNpemU9Mj4mZ3Q7IFRvIG1l IHRoaXMgaXMgDQogICAgICBwYXJ0IG9mIHRoZSBzZW1hbnRpY3Mgb2YgdGhlIHByb3RvY29sLiBN eSA8L0ZPTlQ+PEJSPjxGT05UIHNpemU9Mj4mZ3Q7IA0KICAgICAgcmVxdWlyZW1lbnQgaXMgdGhh dDwvRk9OVD4gPEJSPjxGT05UIHNpemU9Mj4mZ3Q7IHRoZSBwcm90b2NvbCBzdXBwb3J0IHRoZSAN CiAgICAgIGZvbGxvd2luZyB0d28gYmVoYXZpb3Vyczo8L0ZPTlQ+IDxCUj48Rk9OVCBzaXplPTI+ Jmd0OyA8L0ZPTlQ+PEJSPjxGT05UIA0KICAgICAgc2l6ZT0yPiZndDsgMSkgV2hlbiB0aGUgUU9T IEluaXRpYXRvciBnb2VzIGRvd24sIHRoZSByZXNvdXJjZXMgaXQgDQogICAgICA8L0ZPTlQ+PEJS PjxGT05UIHNpemU9Mj4mZ3Q7IHJlcXVlc3RlZCB3aWxsIGJlPC9GT05UPiA8QlI+PEZPTlQgDQog ICAgICBzaXplPTI+Jmd0OyByZWxlYXNlZDwvRk9OVD4gPEJSPjxGT05UIHNpemU9Mj4mZ3Q7IDIp IFdoZW4gdGhlIFFPUyANCiAgICAgIEluaXRpYXRvciBnb2VzIGRvd24sIHRoZSByZXNvdXJjZXMg aXQgPC9GT05UPjxCUj48Rk9OVCBzaXplPTI+Jmd0OyANCiAgICAgIHJlcXVlc3RlZCB3aWxsIG5v dCBiZTwvRk9OVD4gPEJSPjxGT05UIHNpemU9Mj4mZ3Q7IHJlbGVhc2VkPC9GT05UPiANCiAgICAg IDxCUj48Rk9OVCBzaXplPTI+Jmd0OyA8L0ZPTlQ+PEJSPjxGT05UIHNpemU9Mj4mZ3Q7IFRoZSBy ZWFzb24gZm9yIA0KICAgICAgc3VwcG9ydGluZyBiZWhhdmlvdXIgIzIgaXMgdGhlIGNhc2Ugd2hl cmUgYW4gPC9GT05UPjxCUj48Rk9OVCBzaXplPTI+Jmd0OyANCiAgICAgIGVudGl0eSBpbiB0aGU8 L0ZPTlQ+IDxCUj48Rk9OVCBzaXplPTI+Jmd0OyBuZXR3b3JrIHByb3h5IHNpZ25hbHMgb24gYmVo YWxmIA0KICAgICAgb2YgYSBsYXJnZSBudW1iZXIgb2YgPC9GT05UPjxCUj48Rk9OVCBzaXplPTI+ Jmd0OyBjdXN0b21lcnMuIFdlIHdhbnQgDQogICAgICB0aGU8L0ZPTlQ+IDxCUj48Rk9OVCBzaXpl PTI+Jmd0OyBhYmlsaXR5IGZvciB0aGUgY29ycmVzcG9uZGluZyBjb25uZWN0aW9ucyANCiAgICAg IHRvIHN0YXkgdXAgc2hvdWxkIGEgPC9GT05UPjxCUj48Rk9OVCBzaXplPTI+Jmd0OyBjb250cm9s bGVyPC9GT05UPiANCiAgICAgIDxCUj48Rk9OVCBzaXplPTI+Jmd0OyBmYWlsLiBGb3IgcG9saWN5 IHJlYXNvbnMgd2UgbWF5IHdhbnQgdG8gcmVxdWlyZSB0aGF0IA0KICAgICAgYmVoYXZpb3VyICMx IGJlPC9GT05UPiA8QlI+PEZPTlQgc2l6ZT0yPiZndDsgZW5mb3JjZWQgZm9yIHNvbWUgY3VzdG9t ZXJzLiANCiAgICAgIE9idmlvdXNseSBpZiBhIGN1c3RvbWVyIGlzIHBheWluZyBmb3IgYTwvRk9O VD4gPEJSPjxGT05UIHNpemU9Mj4mZ3Q7IA0KICAgICAgY29ubmVjdGlvbiB0aGF0IHdvdWxkIHdh bnQgIzEgdG8gYmUgZW5mb3JjZWQgYXMgd2VsbC4gPC9GT05UPjxCUj48Rk9OVCANCiAgICAgIHNp emU9Mj4mZ3Q7IDwvRk9OVD48QlI+PEZPTlQgc2l6ZT0yPiZndDsgQ2hlZXJzLDwvRk9OVD4gPEJS PjxGT05UIA0KICAgICAgc2l6ZT0yPiZndDsgTWFyY288L0ZPTlQ+IDxCUj48Rk9OVCBzaXplPTI+ Jmd0OyA8L0ZPTlQ+PEJSPjxGT05UIA0KICAgICAgc2l6ZT0yPiZndDsgPC9GT05UPjxCUj48Rk9O VCBzaXplPTI+Jmd0OyA8L0ZPTlQ+PEJSPjxGT05UIHNpemU9Mj4mZ3Q7ICZndDsgDQogICAgICAt LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTwvRk9OVD4gPEJSPjxGT05UIHNpemU9Mj4mZ3Q7ICZn dDsgRnJvbTogR2FyeSANCiAgICAgIEtlbndhcmQgWzxBIA0KICAgICAgaHJlZj0ibWFpbHRvOmdr ZW53YXJkQG5vcnRlbG5ldHdvcmtzLmNvbSI+bWFpbHRvOmdrZW53YXJkQG5vcnRlbG5ldHdvcmtz LmNvbTwvQT5dPC9GT05UPiANCiAgICAgIDxCUj48Rk9OVCBzaXplPTI+Jmd0OyAmZ3Q7IFNlbnQ6 IFdlZG5lc2RheSwgQXByaWwgMDMsIDIwMDIgMjowMiBQTTwvRk9OVD4gDQogICAgICA8QlI+PEZP TlQgc2l6ZT0yPiZndDsgJmd0OyBUbzogJ05TSVMnPC9GT05UPiA8QlI+PEZPTlQgc2l6ZT0yPiZn dDsgJmd0OyANCiAgICAgIFN1YmplY3Q6IFtOU0lTXSBxdWVzdGlvbiBvbiA1LjMuMzwvRk9OVD4g PEJSPjxGT05UIHNpemU9Mj4mZ3Q7ICZndDsgDQogICAgICBTZW5zaXRpdml0eTogQ29uZmlkZW50 aWFsPC9GT05UPiA8QlI+PEZPTlQgc2l6ZT0yPiZndDsgJmd0OyANCiAgICAgIDwvRk9OVD48QlI+ PEZPTlQgc2l6ZT0yPiZndDsgJmd0OyA8L0ZPTlQ+PEJSPjxGT05UIHNpemU9Mj4mZ3Q7ICZndDsg DQogICAgICBIZWxsbzo8L0ZPTlQ+IDxCUj48Rk9OVCBzaXplPTI+Jmd0OyAmZ3Q7IDwvRk9OVD48 QlI+PEZPTlQgc2l6ZT0yPiZndDsgJmd0OyANCiAgICAgIEkgaGF2ZSBhIHF1ZXN0aW9uIHJlZ2Fy ZGluZyBvbmUgb2YgdGhlIHJlcXVpcmVtZW50czo8L0ZPTlQ+IDxCUj48Rk9OVCANCiAgICAgIHNp emU9Mj4mZ3Q7ICZndDsgPC9GT05UPjxCUj48Rk9OVCBzaXplPTI+Jmd0OyAmZ3Q7IDUuMy4zIFBv c3NpYmlsaXR5IGZvciANCiAgICAgIGF1dG9tYXRpYyByZWxlYXNlIG9mIHJlc291cmNlcyBhZnRl ciBmYWlsdXJlPC9GT05UPiA8QlI+PEZPTlQgc2l6ZT0yPiZndDsgDQogICAgICAmZ3Q7IDwvRk9O VD48QlI+PEZPTlQgc2l6ZT0yPiZndDsgJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBXaGVuIHRoZSBR b1MgDQogICAgICBJbml0aWF0b3IgZ29lcyBkb3duLCB0aGUgcmVzb3VyY2VzIGl0IDwvRk9OVD48 QlI+PEZPTlQgc2l6ZT0yPiZndDsgDQogICAgICByZXF1ZXN0ZWQgc2hvdWxkPC9GT05UPiA8QlI+ PEZPTlQgc2l6ZT0yPiZndDsgJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBiZSANCiAgICAgIHJlbGVh c2VkLCBzaW5jZSB0aGV5IHdpbGwgbm8gbG9uZ2VyIGJlIG5lY2Vzc2FyeS48L0ZPTlQ+IDxCUj48 Rk9OVCANCiAgICAgIHNpemU9Mj4mZ3Q7ICZndDsgPC9GT05UPjxCUj48Rk9OVCBzaXplPTI+Jmd0 OyAmZ3Q7IFRoaXMgZG9lcyBub3Qgc2VlbSB0byANCiAgICAgIG1lIHRvIGJlIGEgcHJvdG9jb2wg cmVxdWlyZW1lbnQgbm9yIGEgPC9GT05UPjxCUj48Rk9OVCBzaXplPTI+Jmd0OyANCiAgICAgIGZy YW1ld29yazwvRk9OVD4gPEJSPjxGT05UIHNpemU9Mj4mZ3Q7ICZndDsgcmVxdWlyZW1lbnQsIGJ1 dCByYXRoZXIgYW4gDQogICAgICBpbXBsZW1lbnRhdGlvbiByZXF1aXJlbWVudC4gPC9GT05UPjxC Uj48Rk9OVCBzaXplPTI+Jmd0OyAmZ3Q7IA0KICAgICAgPC9GT05UPjxCUj48Rk9OVCBzaXplPTI+ Jmd0OyAmZ3Q7IERvZXMgdGhpcyBtYXR0ZXI/PC9GT05UPiA8QlI+PEZPTlQgDQogICAgICBzaXpl PTI+Jmd0OyAmZ3Q7IDwvRk9OVD48QlI+PEZPTlQgc2l6ZT0yPiZndDsgJmd0OyBUaGFua3MsPC9G T05UPiANCiAgICAgIDxCUj48Rk9OVCBzaXplPTI+Jmd0OyAmZ3Q7IEdhcnk8L0ZPTlQ+IDxCUj48 Rk9OVCBzaXplPTI+Jmd0OyAmZ3Q7IA0KICAgICAgPC9GT05UPjxCUj48Rk9OVCBzaXplPTI+Jmd0 OyAmZ3Q7IDwvRk9OVD48QlI+PEZPTlQgc2l6ZT0yPiZndDsgJmd0OyANCiAgICAgIDwvRk9OVD48 QlI+PEZPTlQgc2l6ZT0yPiZndDsgJmd0OyA8L0ZPTlQ+PEJSPjxGT05UIHNpemU9Mj4mZ3Q7ICZn dDsgDQogICAgICA8L0ZPTlQ+PEJSPjxGT05UIHNpemU9Mj4mZ3Q7ICZndDsgDQogICAgICBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzwvRk9OVD4gPEJSPjxG T05UIA0KICAgICAgc2l6ZT0yPiZndDsgJmd0OyBuc2lzIG1haWxpbmcgbGlzdDwvRk9OVD4gPEJS PjxGT05UIHNpemU9Mj4mZ3Q7ICZndDsgDQogICAgICBuc2lzQGlldGYub3JnPC9GT05UPiA8QlI+ PEZPTlQgc2l6ZT0yPiZndDsgJmd0OyA8QSB0YXJnZXQ9X2JsYW5rIA0KICAgICAgaHJlZj0iaHR0 cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbnNpcyI+aHR0cHM6Ly93d3cxLmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vbnNpczwvQT48L0ZPTlQ+IA0KICAgICAgPEJSPjxGT05U IHNpemU9Mj4mZ3Q7ICZndDsgPC9GT05UPjxCUj48Rk9OVCBzaXplPTI+Jmd0OyANCiAgICA8L0ZP TlQ+PC9QPjwvQkxPQ0tRVU9URT48L0JMT0NLUVVPVEU+PC9CTE9DS1FVT1RFPjwvQk9EWT48L0hU TUw+DQoNCg== --0__=C1256B910028117F8f9e8a93df938690918cC1256B910028117F-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu Apr 4 06:04:19 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09537 for ; Thu, 4 Apr 2002 06:04:18 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA21473 for nsis-archive@odin.ietf.org; Thu, 4 Apr 2002 06:04:22 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA20315; Thu, 4 Apr 2002 05:47:54 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA20285 for ; Thu, 4 Apr 2002 05:47:47 -0500 (EST) Received: from yamato.ccrle.nec.de (yamato.ccrle.nec.de [195.37.70.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09299 for ; Thu, 4 Apr 2002 05:47:43 -0500 (EST) Received: from citadel.mobility.ccrle.nec.de ([192.168.156.1]) by yamato.ccrle.nec.de (8.11.6/8.10.1) with ESMTP id g34AmVL19855; Thu, 4 Apr 2002 12:48:31 +0200 (CEST) Received: from [192.168.102.79] (madrid.heidelberg.ccrle.nec.de [192.168.102.79]) by citadel.mobility.ccrle.nec.de (Postfix on SuSE eMail Server 2.0) with ESMTP id DF6ABC051; Thu, 4 Apr 2002 12:46:48 +0200 (CEST) Date: Thu, 04 Apr 2002 13:01:03 +0200 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de To: Roland Bless , Anders.P.Bergsten@telia.se, Jukka MJ Manner Cc: nsis@ietf.org Subject: Re: [NSIS] proposal to add requirement text Message-ID: <9743240.1017925263@[192.168.102.79]> In-Reply-To: <200203220015.g2M0Fcf03307@i72pc127.tm.uka.de> References: <200203220015.g2M0Fcf03307@i72pc127.tm.uka.de> X-Mailer: Mulberry/2.1.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit On the scalability issue, I tend to agree with Roland here as well. So my proposal is to add Anders text but keep the scalability text (can be removed later if required) objections. I agree with Roland on the second thing (the priority on signalling messages) If the protocol is not detectable we have a problem anyway. And Anders even says it in the last sentence of the paragraph "From protocol design this requirement states that the protocol messages should be detectable, at least where the control and assignment of the messages priority is done." And I read the paragraph such that it is the providers business what he wants to do, but from the architecture and protocol point of the requirements states that it needs to be poswsible that the provider can do it. And I agree with Anders that the difference lies more in what for the requierements document is used. If Jukka has no major concerns I will include the Anders text for the next version of the doc. Title of Requirement I propose "Ability to assign transport quality to signaling messages" Marcus --On Friday, March 22, 2002 1:15 AM +0100 Roland Bless wrote: > Hi Anders, > > I don't think that it really replaces the scalability statement, but > maybe a good addition to it. Scalability is usually about considering the > effects on system performance when scaling some system parameters in > the order of magnitudes (different scales). This is somehow different > from the statement of minimizing/constraining things. > > The second suggested paragraph on transport quality for the signaling > protocol is IMO a non-requirement (i.e. not really a requirement): > 1. every protocol has some identifier in the lower layer (thus they are > always "detectable") > 2. although it is sensible and really desirable to have a > faster/better/isolated transport for signaling messages, it should be > left to the provider to do so and if so by what means. > > [BTW: please, can you break the lines into a reasonable length, > because quoting is awkward otherwise?] > > Regards, > Roland > >> off line discussions revealed that the scalability sections (5.6) could >> be slightly updated. >> >> I suggest wording along these lines: >> >> The nsis architecture should give the ability to constrain the load (CPU >> load, memory space, signaling bandwidth consumption and signaling >> intensity) on devices where it is needed. This can be achieved by many >> different methods, for example message aggregation, by ignoring >> signaling message, header compression or minimizing functionality. The >> architecture may choose any of these methods as long as the requirement >> is met. >> >> (the reasoning behind the words are the following, if I have the ability >> to control the load the protocol(s) generate in a singel device, the >> protocol will "scale". And the words does not mandate any particular >> solution) >> >> A related requirement that was discussed was transport quality for the >> signaling protocol where I propose the following text. >> >> The nsis architecture should allow the network operator to assign the >> nsis protocol messages a certain transport quality. As signaling opens >> up for possible denial-of-service attacks, this requirement gives the >> network operator a mean, but also the obligation, to trade-off between >> signaling latency and the impact (from the signaling messages) on >> devices within his/her network. From protocol design this requirement >> states that the protocol messages should be detectable, at least where >> the control and assignment of the messages priority is done. >> >> Anders >> >> _______________________________________________ >> nsis mailing list >> nsis@ietf.org >> https://www1.ietf.org/mailman/listinfo/nsis > > -- > Roland Bless -- e-Mail: bless@tm.uka.de > Institute of Telematics, University of Karlsruhe, Germany > Zirkel 2, D-76128 Karlsruhe -- Office: Bld. 20.20, 3rd floor, R 358 > Phone: +49 721 608-6413 Fax: +49 721 388097 > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ personal home page: http://www.brubers.org/marcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu Apr 4 06:09:42 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09603 for ; Thu, 4 Apr 2002 06:09:42 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA21687 for nsis-archive@odin.ietf.org; Thu, 4 Apr 2002 06:09:46 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA21336; Thu, 4 Apr 2002 06:02:03 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA21285 for ; Thu, 4 Apr 2002 06:01:58 -0500 (EST) Received: from yamato.ccrle.nec.de (yamato.ccrle.nec.de [195.37.70.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09496 for ; Thu, 4 Apr 2002 06:01:54 -0500 (EST) Received: from citadel.mobility.ccrle.nec.de ([192.168.156.1]) by yamato.ccrle.nec.de (8.11.6/8.10.1) with ESMTP id g34B2hL19935; Thu, 4 Apr 2002 13:02:43 +0200 (CEST) Received: from [192.168.102.79] (madrid.heidelberg.ccrle.nec.de [192.168.102.79]) by citadel.mobility.ccrle.nec.de (Postfix on SuSE eMail Server 2.0) with ESMTP id 6912FC051; Thu, 4 Apr 2002 13:00:59 +0200 (CEST) Date: Thu, 04 Apr 2002 13:15:13 +0200 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de To: Sven Van den Bosch , nsis@ietf.org Subject: grouping of signalling of microflows (was Re: [NSIS] proposals related to NSIS WG draft) Message-ID: <10593913.1017926113@[192.168.102.79]> In-Reply-To: References: X-Mailer: Mulberry/2.1.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit If I am not mistaken, we already closed this issue. The decision was not to include it as a requirement. This might be an optimization in certain cases, and it even might be useful from an application perspective, but nevertheless seams to more an extension than a hard requirement. Marcus --On Tuesday, March 19, 2002 11:43 PM +0100 Sven Van den Bosch wrote: > - in section 5.3: MAY support grouping of microflows (possibly only for > feedback) As a consequence of the optimization for the interactive > multimedia services, the signaling should allow one unique request for > several micro flows having the same origination and destination IP > addresses. This is usually the case for multimedia SIP calls where the > voice and video micro flows follow the same path. This grouping of > requests allows optimization of the QoS processing. Note that this may be > detrimental for the call setup time. The use of grouping for microflows > may be restricted to teardown and/or notification messages when call > setup time is a concern. -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ personal home page: http://www.brubers.org/marcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu Apr 4 06:46:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10194 for ; Thu, 4 Apr 2002 06:46:45 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA23481 for nsis-archive@odin.ietf.org; Thu, 4 Apr 2002 06:46:47 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA22541; Thu, 4 Apr 2002 06:28:27 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA22463 for ; Thu, 4 Apr 2002 06:28:23 -0500 (EST) Received: from yamato.ccrle.nec.de (yamato.ccrle.nec.de [195.37.70.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09862 for ; Thu, 4 Apr 2002 06:28:19 -0500 (EST) Received: from citadel.mobility.ccrle.nec.de ([192.168.156.1]) by yamato.ccrle.nec.de (8.11.6/8.10.1) with ESMTP id g34BSmL20033; Thu, 4 Apr 2002 13:28:48 +0200 (CEST) Received: from [192.168.102.79] (madrid.heidelberg.ccrle.nec.de [192.168.102.79]) by citadel.mobility.ccrle.nec.de (Postfix on SuSE eMail Server 2.0) with ESMTP id 5F86FC051; Thu, 4 Apr 2002 13:27:12 +0200 (CEST) Date: Thu, 04 Apr 2002 13:41:27 +0200 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de To: Sven Van den Bosch , nsis@ietf.org Message-ID: <12167055.1017927687@[192.168.102.79]> In-Reply-To: <10593913.1017926113@[192.168.102.79]> References: <10593913.1017926113@[192.168.102.79]> X-Mailer: Mulberry/2.1.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Subject: [NSIS] Sorry: Re: grouping of signalling of microflows (was Re: [NSIS] proposals related to NSIS WG draft) Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit Sorry I was mistaken. We keep the issue open until we resolved the issue on bi-directional QoS path setup. Marcus --On Thursday, April 04, 2002 1:15 PM +0200 Marcus Brunner wrote: > If I am not mistaken, we already closed this issue. The decision was not > to include it as a requirement. This might be an optimization in certain > cases, and it even might be useful from an application perspective, but > nevertheless seams to more an extension than a hard requirement. > > Marcus > > --On Tuesday, March 19, 2002 11:43 PM +0100 Sven Van den Bosch > wrote: > >> - in section 5.3: MAY support grouping of microflows (possibly only for >> feedback) As a consequence of the optimization for the interactive >> multimedia services, the signaling should allow one unique request for >> several micro flows having the same origination and destination IP >> addresses. This is usually the case for multimedia SIP calls where the >> voice and video micro flows follow the same path. This grouping of >> requests allows optimization of the QoS processing. Note that this may be >> detrimental for the call setup time. The use of grouping for microflows >> may be restricted to teardown and/or notification messages when call >> setup time is a concern. > > > > -------------------------------------- > Dr. Marcus Brunner > Network Laboratories > NEC Europe Ltd. > > E-Mail: brunner@ccrle.nec.de > WWW: http://www.ccrle.nec.de/ > personal home page: http://www.brubers.org/marcus > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ personal home page: http://www.brubers.org/marcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu Apr 4 06:48:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10257 for ; Thu, 4 Apr 2002 06:48:49 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA23580 for nsis-archive@odin.ietf.org; Thu, 4 Apr 2002 06:48:51 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA22410; Thu, 4 Apr 2002 06:26:37 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA22377 for ; Thu, 4 Apr 2002 06:26:34 -0500 (EST) Received: from yamato.ccrle.nec.de (yamato.ccrle.nec.de [195.37.70.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09803 for ; Thu, 4 Apr 2002 06:26:30 -0500 (EST) Received: from citadel.mobility.ccrle.nec.de ([192.168.156.1]) by yamato.ccrle.nec.de (8.11.6/8.10.1) with ESMTP id g34BRFL20026; Thu, 4 Apr 2002 13:27:15 +0200 (CEST) Received: from [192.168.102.79] (madrid.heidelberg.ccrle.nec.de [192.168.102.79]) by citadel.mobility.ccrle.nec.de (Postfix on SuSE eMail Server 2.0) with ESMTP id 0E7D7C051; Thu, 4 Apr 2002 13:25:39 +0200 (CEST) Date: Thu, 04 Apr 2002 13:39:53 +0200 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de To: "Geib, Ruediger" , svenvandenbosch@hotmail.com Cc: nsis@ietf.org Subject: pre-emption (was RE: [NSIS] proposals related to NSIS WG draft) Message-ID: <12073650.1017927593@[192.168.102.79]> In-Reply-To: References: X-Mailer: Mulberry/2.1.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id GAA22378 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit As Ruediger I would like to hear some other opinions as well. I think the whole fault handling is an open issue anyway and preempting flows might play a roll in fault handling as well. Marcus --On Tuesday, April 02, 2002 4:27 PM +0200 "Geib, Ruediger" wrote: > Hi Sven, > > the comment is a bit late, but I've been offline for a while. > Nevertheless: > >> * New requirements >> - in section MUST support priority >> The priority of a flow is essentially decoupled from >> its QoS requirements. Therefore the protocol MUST >> support priority. As a consequence, it MUST support >> preemption of traffic flows in case of congestion or >> failure. A preemption action MAY trigger an attempt >> to resetup the request by means of another instance >> of an NSIS signaling protocol. > > Could you provide some clearer argumentation why > preemption is a requirement? I'd classify preemption > as a "nice to have" feature, no more than a "MAY" > requirement. I'd especially insist on preemption being > completely decoupled from QoS and any other service > related signalling. > I.e. if it is not supported by an opperator, no > parameters or messages related to preemption are > to be transported. > > I'd like to ask other representatives of operators for > their view. > > Regards, Rüdiger > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ personal home page: http://www.brubers.org/marcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu Apr 4 07:57:31 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12270 for ; Thu, 4 Apr 2002 07:57:30 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA27428 for nsis-archive@odin.ietf.org; Thu, 4 Apr 2002 07:57:33 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA26714; Thu, 4 Apr 2002 07:40:57 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA26684 for ; Thu, 4 Apr 2002 07:40:55 -0500 (EST) Received: from yamato.ccrle.nec.de (yamato.ccrle.nec.de [195.37.70.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11727 for ; Thu, 4 Apr 2002 07:40:51 -0500 (EST) Received: from citadel.mobility.ccrle.nec.de ([192.168.156.1]) by yamato.ccrle.nec.de (8.11.6/8.10.1) with ESMTP id g34CffL20351 for ; Thu, 4 Apr 2002 14:41:41 +0200 (CEST) Received: from [192.168.102.79] (madrid.heidelberg.ccrle.nec.de [192.168.102.79]) by citadel.mobility.ccrle.nec.de (Postfix on SuSE eMail Server 2.0) with ESMTP id 4F1E8C051 for ; Thu, 4 Apr 2002 14:40:00 +0200 (CEST) Date: Thu, 04 Apr 2002 14:54:15 +0200 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de To: nsis@ietf.org Message-ID: <16535196.1017932055@[192.168.102.79]> X-Mailer: Mulberry/2.1.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Subject: [NSIS] requirement draft structure Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit Dear all, At the IETF meeting in MPLS I proposed to change the structure of the document in the following way. This mail just checks whether there are major concerns with that. The changes include - put all the scenarios into an appendix - In Section 6 add text describing 3 different "parts of the network" -Host to first hop -access network -core networks better names are welcome, but I don't want to be religious about it - Prioritize the requirements according to the "parts of the network" (This means the the tables in Section 6 of the current draft will get three colums with the MUST, SHOULDs, and MAYs for each requirement If no major concerns are voiced I will go with this structure. Marcus -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ personal home page: http://www.brubers.org/marcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu Apr 4 08:18:57 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12982 for ; Thu, 4 Apr 2002 08:18:57 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA29077 for nsis-archive@odin.ietf.org; Thu, 4 Apr 2002 08:19:00 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA28539; Thu, 4 Apr 2002 08:09:14 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA28498 for ; Thu, 4 Apr 2002 08:09:09 -0500 (EST) Received: from yamato.ccrle.nec.de (yamato.ccrle.nec.de [195.37.70.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12726 for ; Thu, 4 Apr 2002 08:09:04 -0500 (EST) Received: from citadel.mobility.ccrle.nec.de ([192.168.156.1]) by yamato.ccrle.nec.de (8.11.6/8.10.1) with ESMTP id g34D9vL20568; Thu, 4 Apr 2002 15:09:57 +0200 (CEST) Received: from [192.168.102.79] (madrid.heidelberg.ccrle.nec.de [192.168.102.79]) by citadel.mobility.ccrle.nec.de (Postfix on SuSE eMail Server 2.0) with ESMTP id 13D5BC051; Thu, 4 Apr 2002 15:08:11 +0200 (CEST) Date: Thu, 04 Apr 2002 15:22:26 +0200 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de To: "Shahrier, Sharif M." Cc: nsis@ietf.org Subject: Re: [NSIS] On the definition of QoS flow and aggregate flow. Message-ID: <18226127.1017933746@[192.168.102.79]> In-Reply-To: References: X-Mailer: Mulberry/2.1.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit Sharif, I got the feeling in MPLS WG meeting that defining QoS parameters (or more general service descripions is currently out of scope of the NSIS work. We even have a number of requirements in the -00 draft that are service specific and will be removed. Marcus --On Wednesday, April 03, 2002 3:27 PM -0500 "Shahrier, Sharif M." wrote: > In the NSIS requirement draft, I have some points for discussion on the > definition of a "flow" from the presective of NSIS, and also on the > definition of "aggregate flow". > > I feel these need to be defined more fully in terms of QoS. > > It is defined in the requirements draft, that: > > A flow is a traffic stream between two endpoints for which "a specific > level of QoS is provided". > > My question is how to characterize such a flow in terms of quantitative > QoS parameters. > > A set of QoS parameters can be standardized for a flow. These parameters > could be: > > Maximum delay > Minimum throughput > Maximum response time (assuming buffering) > Maximum jitter > ....... > > These parameters should then be mapped to a specific "priority value", > i.e. a single parameter. > > The parameter can relate directly to ABR, CBR, UBR, ......... types of > flow. > > A 6-tuple (src. addr, dest. addr., src. port nbr., dest. port nbr, > protoID, Priority) should characterize a "flow" as far as the > requirements for NSIS working group. > > Having a single priority value would make it much easier to quantify QoS > to define a flow, as opposed to a whole set of parameters like delay, > throughput, jitter ............ > > A flow aggregate can be defined as a set of flows, where each flow has the > same QoS priority. > > Thus, a coarse grain, single QoS priority for "flow" characterization can > help to readily gather flows with the same priority value into a set to > form an aggregate flow set. > > Comments and feedback please......... > > Sharif. > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ personal home page: http://www.brubers.org/marcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu Apr 4 09:22:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15477 for ; Thu, 4 Apr 2002 09:22:41 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA03584 for nsis-archive@odin.ietf.org; Thu, 4 Apr 2002 09:22:44 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA03044; Thu, 4 Apr 2002 09:10:38 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA02999 for ; Thu, 4 Apr 2002 09:10:32 -0500 (EST) Received: from yamato.ccrle.nec.de (yamato.ccrle.nec.de [195.37.70.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15030 for ; Thu, 4 Apr 2002 09:10:28 -0500 (EST) Received: from citadel.mobility.ccrle.nec.de ([192.168.156.1]) by yamato.ccrle.nec.de (8.11.6/8.10.1) with ESMTP id g34EBJL21573; Thu, 4 Apr 2002 16:11:19 +0200 (CEST) Received: from [192.168.102.79] (madrid.heidelberg.ccrle.nec.de [192.168.102.79]) by citadel.mobility.ccrle.nec.de (Postfix on SuSE eMail Server 2.0) with ESMTP id B7A5EC051; Thu, 4 Apr 2002 16:09:42 +0200 (CEST) Date: Thu, 04 Apr 2002 16:23:58 +0200 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de To: Sven Van den Bosch Cc: nsis@ietf.org Message-ID: <21918026.1017937438@[192.168.102.79]> In-Reply-To: References: X-Mailer: Mulberry/2.1.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Subject: [NSIS] Re: text on layering - original mail Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit I got the feeling this might belong into a framework document. Or do you think it belongs into the reqs draft. Marcus --On Thursday, March 21, 2002 3:49 AM +0100 Sven Van den Bosch wrote: > Hi, > > We have been thinking about the QI/QC definitions and we have tried to > arrange the QC/QI functional entities in a logical relation that covers > the use case scenarios that have been proposed so far. From this, we hope > to derive clearer definitions. > > The general logical relationships are depicted below (for simplicity, only > signaling relations are drawn) > > +--+ (a) +--+ (a) +--+ (a) +---+ > +->|QI|---->|QC|---------------->|QC|---->| QR|--+ > QI,QC,QR roles for e2e QoS protocol > | +--+ /+--+\ /+--+\ +---+ | > | / \ / \ v > +--+ (b) +--+ +--+(b)+--+(b)+--+ +--+(b)+--+(b)+--+ +--+ (b) +--+ >| QI|---->|QR| |QI|-->|QC|-->|QR| |QI|-->|QC|-->|QR| |QI|---->|QR| > QI,QC,QR roles for local QoS protocol > +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ > > In this pictures we clearly distinguish two applications for the NSIS > protocol: > (a) NSIS as end-to-end QoS signaling protocol > (b) NSIS as local QoS signaling protocol > > Local, in this case, is defined as local to a QoS domain. A QoS domain is > defined as a contiguous part of the network supporting the same QoS > technology (e.g. RSVP). Note that for (a) NSIS is mandatory. For (b), NSIS > actually competes with other technologies offering local QoS, such as PDP, > RSVP, ... > > The above picture seems to suggest an out-of-band approach but this is not > the case. The QCs can be implemented in a distributed way and redrawing > the picture then gives a different view. > > +--+(a)+--+ (a) +--+(a)+--+ (a) +--+(a)+--+ > |QI|-->|QC|--------->|QC|-->|QC|--------->|QC|-->|QR| > QI,QC,QR roles for e2e QoS protocol > +--+ +--+ +--+ +--+ +--+ +--+ > ^ v ^ v ^ v > +--+ (b) +--+ +--+(b)+--+(b)+--+ +--+(b)+--+(b)+--+ +--+ (b) +--+ >| QI|---->|QR| |QI|-->|QC|-->|QR| |QI|-->|QC|-->|QR| |QI|---->|QR| > QI,QC,QR roles for local QoS protocol > +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ > > In this case, it is clear that an in-band solution is also supported. The > end-to-end QC/QI/QR and the local QC/QI/QR can then be colocated, e.g. on > a router. Note that in this picture, the signaling in the access is done > with a local QoS protocol. This can be either an existing protocol, or > the NSIS protocol in its role of local QoS signaling mechanism. This > leads to the following requirements: > > (a) If an NSIS protocol is only used end-to-end, then mobility need not be > supported > (b) If an NSIS protocol is used as a local QoS signaling mechanism then > mobility must be supported, both on the QI-QC and QC-QC interface > (c) If the same protocol is desired in (a) and (b), the protocol should be > modular and the mobility aspects need to be separable from the rest > > Both of the above scenarios assume that the host is not NSIS-aware. This > is a reasonable assumption in a first phase. In a later stage, when hosts > are NSIS-aware, the host speaks the NSIS protocol, but as a local QoS > signaling technology! This allows this case to be backwards compatible > with the above scenarios. It means that (b) in the access is an NSIS > protocol. It also means that the host will always trigger the local QoS > signaling mechanism. > > This suggests the following definitions for the QI, QC, QR > > - QoS Initiator: Network entity, located at the boundary of a QoS domain, > responsible for initiating a (local or end-to-end) QoS mechanism. If it is > the QI of a local protocol, it can be triggered by higher layers > (applications or end-to-end QoS Controller). If it is the QI of an > end-to-end protocol, it can be triggered by applications or by the QoS > Receiver of a local QoS signaling mechanism. > > - QoS Controller: Network entity responsible for interpreting and > implementing the signalled QoS in the network. Failure to do so implies an > admission control decision. It can only be triggered by a QI or another > QC. > > -QoS Receiver: Network entity, located at the boundary of a QoS domain, > responsible for terminating a (local or end-to-end) QoS mechanism. It has > the additional functionality that it may initiate an acknowledgment > towards the QI and that it may trigger a QI or QC in the NSIS end-to-end > protocol. > > If this can be accepted by the NSIS community, we propose to add this text > to the requirements document as a clarification of the QI/QC model that is > used there. > > > > > _________________________________________________________________ > Chat on line met vrienden en probeer MSN Messenger uit: > http://messenger.msn.nl > -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ personal home page: http://www.brubers.org/marcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu Apr 4 12:08:54 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23296 for ; Thu, 4 Apr 2002 12:08:54 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA16901 for nsis-archive@odin.ietf.org; Thu, 4 Apr 2002 12:08:57 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA16208; Thu, 4 Apr 2002 12:02:12 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA16177 for ; Thu, 4 Apr 2002 12:02:09 -0500 (EST) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22968 for ; Thu, 4 Apr 2002 12:02:05 -0500 (EST) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g34H1Zv19221; Thu, 4 Apr 2002 12:01:35 -0500 (EST) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 4 Apr 2002 12:01:37 -0500 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA49B9@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Schneider, Marco'" , "'NSIS'" Subject: RE: [NSIS] question on 5.3.3 Date: Thu, 4 Apr 2002 12:01:30 -0500 Sensitivity: Company-Confidential MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DBFA.2712887C" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1DBFA.2712887C Content-Type: text/plain; charset="iso-8859-1" Marco: Understood. I suspect that the IETF (i.e. the wg perhaps, and likely at least the IESG) will not be in favour of 2), and will support 1). The bottom line, at this point is that the requirement needs to be clarified, I think. Thanks, Gary -----Original Message----- From: Schneider, Marco [mailto:schneider@tri.sbc.com] Sent: April 3, 2002 17:39 To: Kenward, Gary [WDLN2:AN10:EXCH]; 'NSIS' Subject: RE: [NSIS] question on 5.3.3 Sensitivity: Confidential Gary, To answer your question I must make assumptions about the solution. For example: 1) In the case of a soft-state solution such as RSVP, Case #1 is explicityly supported. The refresh message acts as a "keep alive". The semantics of the protocol is that a reservation timeouts in a short duration if not refreshed. The refreshments are per flow. Behaviour #2 is not supported. If it were supported exclusively then refresh would not exist. 2) In contrast ATM UNI does not do per flow/connection refresh. My best recollection is as follows. If the signaling channel is detected as having gone down (via some sort of keep alive mechanism) then all associated connections are released. Because ATM "refreshes" the signaling channel and not the flows/connections, for any individual connection the protocol will reach a steady state in which no additional messages are sent. While this may be seen as implicit implementation of behaviour #1 from the overall layered perspective, from the UNI state machine perspective behaviour #2 is being supported. Not sure if this fully answers your question.... Marco -----Original Message----- From: Gary Kenward [mailto:gkenward@nortelnetworks.com] Sent: Wednesday, April 03, 2002 2:34 PM To: Schneider, Marco; 'NSIS' Subject: RE: [NSIS] question on 5.3.3 Sensitivity: Confidential Marco: I fully agree that resource allocations need to have the option for finite life times. However, I am unclear as to how 1) versus 2) would change the semantics of the protocol? As opposed to the semantics of resource reservation algorithms at a given node? To state this in another fashion, if I attached a protocol analyzer to a link carrying NSIS, what protocol semantics could I capture that would reflect this resource timing? Gary > -----Original Message----- > From: Schneider, Marco [ mailto:schneider@tri.sbc.com ] > Sent: April 3, 2002 15:22 > To: Kenward, Gary [WDLN2:AN10:EXCH]; 'NSIS' > Subject: RE: [NSIS] question on 5.3.3 > Sensitivity: Confidential > > > To me this is part of the semantics of the protocol. My > requirement is that > the protocol support the following two behaviours: > > 1) When the QOS Initiator goes down, the resources it > requested will be > released > 2) When the QOS Initiator goes down, the resources it > requested will not be > released > > The reason for supporting behaviour #2 is the case where an > entity in the > network proxy signals on behalf of a large number of > customers. We want the > ability for the corresponding connections to stay up should a > controller > fail. For policy reasons we may want to require that behaviour #1 be > enforced for some customers. Obviously if a customer is paying for a > connection that would want #1 to be enforced as well. > > Cheers, > Marco > > > > > -----Original Message----- > > From: Gary Kenward [ mailto:gkenward@nortelnetworks.com ] > > Sent: Wednesday, April 03, 2002 2:02 PM > > To: 'NSIS' > > Subject: [NSIS] question on 5.3.3 > > Sensitivity: Confidential > > > > > > Hello: > > > > I have a question regarding one of the requirements: > > > > 5.3.3 Possibility for automatic release of resources after failure > > > > When the QoS Initiator goes down, the resources it > requested should > > be released, since they will no longer be necessary. > > > > This does not seem to me to be a protocol requirement nor a > framework > > requirement, but rather an implementation requirement. > > > > Does this matter? > > > > Thanks, > > Gary > > > > > > > > > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > ------_=_NextPart_001_01C1DBFA.2712887C Content-Type: text/html; charset="iso-8859-1" RE: [NSIS] question on 5.3.3
Marco:
 
Understood. I suspect that the IETF (i.e. the wg perhaps, and likely at least the IESG)
will not be in favour of 2), and will support 1).
 
The bottom line, at this point is that the requirement needs to be clarified, I think.
 
Thanks,
Gary
-----Original Message-----
From: Schneider, Marco [mailto:schneider@tri.sbc.com]
Sent: April 3, 2002 17:39
To: Kenward, Gary [WDLN2:AN10:EXCH]; 'NSIS'
Subject: RE: [NSIS] question on 5.3.3
Sensitivity: Confidential

Gary,
 
To answer your question I must make assumptions about the solution. For example:
 
1) In the case of a soft-state solution such as RSVP, Case #1 is explicityly supported. The refresh message acts as a "keep alive". The semantics of the protocol is that a reservation timeouts in a short duration if not refreshed. The refreshments are per flow. Behaviour #2 is not supported. If it were supported exclusively then refresh would not exist.
 
2) In contrast ATM UNI does not do per flow/connection refresh. My best recollection is as follows. If the signaling channel is detected as having gone down (via some sort of keep alive mechanism) then all associated connections are released. Because ATM "refreshes" the signaling channel and not the flows/connections, for any individual connection the protocol will reach a steady state in which no additional messages are sent. While this may be seen as implicit implementation of behaviour #1 from the overall layered perspective, from the UNI state machine perspective behaviour #2 is being supported.
 
Not sure if this fully answers your question....
 
Marco
-----Original Message-----
From: Gary Kenward [mailto:gkenward@nortelnetworks.com]
Sent: Wednesday, April 03, 2002 2:34 PM
To: Schneider, Marco; 'NSIS'
Subject: RE: [NSIS] question on 5.3.3
Sensitivity: Confidential

Marco:

  I fully agree that resource allocations need to have the option for
finite life times.

  However, I am unclear as to how 1) versus 2) would change the semantics
of the protocol? As opposed to the semantics of resource reservation algorithms
at a given node?

  To state this in another fashion, if I attached a protocol
analyzer to a link carrying NSIS, what protocol semantics could
I capture that would reflect this resource timing?

Gary

> -----Original Message-----
> From: Schneider, Marco [mailto:schneider@tri.sbc.com]
> Sent: April 3, 2002 15:22
> To: Kenward, Gary [WDLN2:AN10:EXCH]; 'NSIS'
> Subject: RE: [NSIS] question on 5.3.3
> Sensitivity: Confidential
>
>
> To me this is part of the semantics of the protocol. My
> requirement is that
> the protocol support the following two behaviours:
>
> 1) When the QOS Initiator goes down, the resources it
> requested will be
> released
> 2) When the QOS Initiator goes down, the resources it
> requested will not be
> released
>
> The reason for supporting behaviour #2 is the case where an
> entity in the
> network proxy signals on behalf of a large number of
> customers. We want the
> ability for the corresponding connections to stay up should a
> controller
> fail. For policy reasons we may want to require that behaviour #1 be
> enforced for some customers. Obviously if a customer is paying for a
> connection that would want #1 to be enforced as well.
>
> Cheers,
> Marco
>
>
>
> > -----Original Message-----
> > From: Gary Kenward [mailto:gkenward@nortelnetworks.com]
> > Sent: Wednesday, April 03, 2002 2:02 PM
> > To: 'NSIS'
> > Subject: [NSIS] question on 5.3.3
> > Sensitivity: Confidential
> >
> >
> > Hello:
> >
> > I have a question regarding one of the requirements:
> >
> > 5.3.3 Possibility for automatic release of resources after failure
> >
> >    When the QoS Initiator goes down, the resources it
> requested should
> >    be released, since they will no longer be necessary.
> >
> > This does not seem to me to be a protocol requirement nor a
> framework
> > requirement, but rather an implementation requirement.
> >
> > Does this matter?
> >
> > Thanks,
> > Gary
> >
> >
> >
> >
> >
> > _______________________________________________
> > nsis mailing list
> > nsis@ietf.org
> > https://www1.ietf.org/mailman/listinfo/nsis
> >
>

------_=_NextPart_001_01C1DBFA.2712887C-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu Apr 4 12:41:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24910 for ; Thu, 4 Apr 2002 12:41:22 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA19269 for nsis-archive@odin.ietf.org; Thu, 4 Apr 2002 12:41:23 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA18573; Thu, 4 Apr 2002 12:30:57 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA18539 for ; Thu, 4 Apr 2002 12:30:54 -0500 (EST) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24514 for ; Thu, 4 Apr 2002 12:30:50 -0500 (EST) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g34HU8v20990; Thu, 4 Apr 2002 12:30:09 -0500 (EST) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 4 Apr 2002 12:30:10 -0500 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA49BD@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'sven.van_den_bosch@alcatel.be'" , "Schneider, Marco" Cc: "'marc.greis@nokia.com'" , nsis@ietf.org Subject: RE: [NSIS] question on 5.3.3 Date: Thu, 4 Apr 2002 12:30:00 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DBFD.C86220CC" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1DBFD.C86220CC Content-Type: text/plain; charset="iso-8859-1" The other, perhaps more significant question, is whether the fail over mechanism is NSIS protocol driven, as Marco is suggestion, or locally driven, as in a self-healing network, as in Internet routing. Pros and cons for both, and perhaps both are needed. Let's be careful about all the assumptions the lay behind a signalling approach to fault management. More to the original point, I believe the requirement needs to be clarified. There is a possibility that there are actually two requirements (based upon two different interpretations of the current requirement that have been expressed). Gary > -----Original Message----- > From: sven.van_den_bosch@alcatel.be > [mailto:sven.van_den_bosch@alcatel.be] > Sent: April 4, 2002 02:25 > To: Schneider, Marco > Cc: Kenward, Gary [WDLN2:AN10:EXCH]; 'marc.greis@nokia.com'; > nsis@ietf.org > Subject: RE: [NSIS] question on 5.3.3 > > > Hi Marco, all, > > I think this touches on the resiliency issue we discussed in > Minneapolis. > When the data plane and control plane are separate then it is > a question of > fate sharing. Should or shouldn't the data path be torn down > when a control > plane entity fails. I certainly wouldn't limit this to the QI > only, it is > also important for the QC. Also, we may need to consider > different types of > failures with different reactions. Personally, I think that > the behaviour > under failure conditions is a framework issue. For the moment > I think that > in terms of requirements, the suggestion that both > maintenance and release > of existing flows should be supported is a good starting > point. I thought, > however, that we were going to put all the failure behaviour > under open > issues for the requirements. > > Sven. > > > > > > "Schneider, Marco" on 04/04/2002 01:35:26 > > > > To: "'Gary Kenward'" > , > "'marc.greis@nokia.com'" > , nsis@ietf.org > > cc: (bcc: Sven VAN DEN BOSCH/BE/ALCATEL) > > > > Subject RE: [NSIS] question on 5.3.3 > : > > > > > > > Yes that's it, the protocol must support options for fault recovery > including the maintenance and the release of existing flows. > > Marco > > -----Original Message----- > From: Gary Kenward [mailto:gkenward@nortelnetworks.com] > Sent: Wednesday, April 03, 2002 4:06 PM > To: 'marc.greis@nokia.com'; Schneider, Marco; nsis@ietf.org > Subject: RE: [NSIS] question on 5.3.3 > Sensitivity: Confidential > > > Marc: > > Ok, but I think that this is a specific interpretation of the > requirement > that is not captured in the wording. > What you are referring to is more along the lines of protocol > support for > fault recovery. May be useful > (if the initiator is down, who are the protocol peers? if the > initiator is > in the path, how can the protocol > be used? etc.) > > Anyway, thanks. > Gary > > -----Original Message----- > From: marc.greis@nokia.com [mailto:marc.greis@nokia.com] > Sent: April 3, 2002 16:14 > To: Kenward, Gary [WDLN2:AN10:EXCH]; schneider@tri.sbc.com; > nsis@ietf.org > Subject: RE: [NSIS] question on 5.3.3 > Sensitivity: Confidential > > > Gary, > > I assume that based based on this requirement, there needs to be a > mechanism > in the protocol to determine if the QoS Initiator is actually > down. So to > come back to your original question, I do think that this is > actually a > protocol requirement and not merely an implementation issue. > > Marc > > > -----Original Message----- > From: ext Gary Kenward [mailto:gkenward@nortelnetworks.com] > Sent: 03 April, 2002 2:34 PM > To: 'Schneider, Marco'; 'NSIS' > Subject: RE: [NSIS] question on 5.3.3 > > > Marco: > > I fully agree that resource allocations need to have the option for > finite life times. > > However, I am unclear as to how 1) versus 2) would change > the semantics > of the protocol? As opposed to the semantics of resource reservation > algorithms > at a given node? > > To state this in another fashion, if I attached a protocol > analyzer to a link carrying NSIS, what protocol semantics could > I capture that would reflect this resource timing? > > Gary > > > -----Original Message----- > > From: Schneider, Marco [ mailto:schneider@tri.sbc.com > ] > > Sent: April 3, 2002 15:22 > > To: Kenward, Gary [WDLN2:AN10:EXCH]; 'NSIS' > > Subject: RE: [NSIS] question on 5.3.3 > > Sensitivity: Confidential > > > > > > To me this is part of the semantics of the protocol. My > > requirement is that > > the protocol support the following two behaviours: > > > > 1) When the QOS Initiator goes down, the resources it > > requested will be > > released > > 2) When the QOS Initiator goes down, the resources it > > requested will not be > > released > > > > The reason for supporting behaviour #2 is the case where an > > entity in the > > network proxy signals on behalf of a large number of > > customers. We want the > > ability for the corresponding connections to stay up should a > > controller > > fail. For policy reasons we may want to require that behaviour #1 be > > enforced for some customers. Obviously if a customer is paying for a > > connection that would want #1 to be enforced as well. > > > > Cheers, > > Marco > > > > > > > > > -----Original Message----- > > > From: Gary Kenward [ mailto:gkenward@nortelnetworks.com > ] > > > Sent: Wednesday, April 03, 2002 2:02 PM > > > To: 'NSIS' > > > Subject: [NSIS] question on 5.3.3 > > > Sensitivity: Confidential > > > > > > > > > Hello: > > > > > > I have a question regarding one of the requirements: > > > > > > 5.3.3 Possibility for automatic release of resources after failure > > > > > > When the QoS Initiator goes down, the resources it > > requested should > > > be released, since they will no longer be necessary. > > > > > > This does not seem to me to be a protocol requirement nor a > > framework > > > requirement, but rather an implementation requirement. > > > > > > Does this matter? > > > > > > Thanks, > > > Gary > > > > > > > > > > > > > > > > > > _______________________________________________ > > > nsis mailing list > > > nsis@ietf.org > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > (See attached file: att1.htm) > > ------_=_NextPart_001_01C1DBFD.C86220CC Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [NSIS] question on 5.3.3

The other, perhaps more significant question, is = whether the
fail over mechanism is NSIS protocol driven, as = Marco is suggestion,
or locally driven, as in a self-healing network, as = in Internet routing.

Pros and cons for both, and perhaps both are needed. = Let's be careful about
all the assumptions the lay behind a signalling = approach to fault management.

More to the original point, I believe the requirement = needs to be clarified.
There is a possibility that there are actually two = requirements (based upon
two different interpretations of the current = requirement that have been
expressed).

Gary

> -----Original Message-----
> From: sven.van_den_bosch@alcatel.be
> [mailto:sven.van_den_bosch@= alcatel.be]
> Sent: April 4, 2002 02:25
> To: Schneider, Marco
> Cc: Kenward, Gary [WDLN2:AN10:EXCH]; = 'marc.greis@nokia.com';
> nsis@ietf.org
> Subject: RE: [NSIS] question on 5.3.3
>
>
> Hi Marco, all,
>
> I think this touches on the resiliency issue we = discussed in
> Minneapolis.
> When the data plane and control plane are = separate then it is
> a question of
> fate sharing. Should or shouldn't the data path = be torn down
> when a control
> plane entity fails. I certainly wouldn't limit = this to the QI
> only, it is
> also important for the QC. Also, we may need to = consider
> different types of
> failures with different reactions. Personally, = I think that
> the behaviour
> under failure conditions is a framework issue. = For the moment
> I think that
> in terms of requirements, the suggestion that = both
> maintenance and release
> of existing flows should be supported is a good = starting
> point. I thought,
> however, that we were going to put all the = failure behaviour
> under open
> issues for the requirements.
>
> Sven.
>
>
>
>
>
> "Schneider, Marco" = <schneider@tri.sbc.com> on 04/04/2002 01:35:26
>          = ;            = ;            = ;            = ;            = ;    
>          = ;            = ;            = ;            = ;            = ;    
>          = ;            = ;            = ;            = ;            = ;    
>   = To:          "'Gary = Kenward'"         &nbs= p;           &nbs= p;        
>          = ;      = <gkenward@nortelnetworks.com>,      =           
>          = ;      = "'marc.greis@nokia.com'"      &n= bsp;           &n= bsp;   
>          = ;      <marc.greis@nokia.com>, = nsis@ietf.org          =
>          = ;            = ;            = ;            = ;            = ;    
>   = cc:          (bcc: Sven = VAN DEN = BOSCH/BE/ALCATEL)         &= nbsp;
>          = ;            = ;            = ;            = ;            = ;    
>          = ;            = ;            = ;            = ;            = ;    
>          = ;            = ;            = ;            = ;            = ;    
>   = Subject      RE: [NSIS] question on = 5.3.3           &= nbsp;      
>   = :            = ;            = ;            = ;            = ;          
>          = ;            = ;            = ;            = ;            = ;    
>
>
>
>
>
> Yes that's it, the protocol must support = options for fault recovery
> including the maintenance and the release of = existing flows.
>
> Marco
>
> -----Original Message-----
> From: Gary Kenward [mailto:gkenward@nortelnetwor= ks.com]
> Sent: Wednesday, April 03, 2002 4:06 PM
> To: 'marc.greis@nokia.com'; Schneider, Marco; = nsis@ietf.org
> Subject: RE: [NSIS] question on 5.3.3
> Sensitivity: Confidential
>
>
> Marc:
>
> Ok, but I think that this is a specific = interpretation of the
> requirement
> that is not captured in the wording.
> What you are referring to is more along the = lines of protocol
> support for
> fault recovery. May be useful
> (if the initiator is down, who are the protocol = peers? if the
> initiator is
> in the path, how can the protocol
> be used? etc.)
>
> Anyway, thanks.
> Gary
>
> -----Original Message-----
> From: marc.greis@nokia.com [mailto:marc.greis@nokia.com]
> Sent: April 3, 2002 16:14
> To: Kenward, Gary [WDLN2:AN10:EXCH]; = schneider@tri.sbc.com;
> nsis@ietf.org
> Subject: RE: [NSIS] question on 5.3.3
> Sensitivity: Confidential
>
>
> Gary,
>
> I assume that based based on this requirement, = there needs to be a
> mechanism
> in the protocol to determine if the QoS = Initiator is actually
> down. So to
> come back to your original question, I do think = that this is
> actually a
> protocol requirement and not merely an = implementation issue.
>
> Marc
>
>
> -----Original Message-----
> From: ext Gary Kenward [mailto:gkenward@nortelnetwor= ks.com]
> Sent: 03 April, 2002 2:34 PM
> To: 'Schneider, Marco'; 'NSIS'
> Subject: RE: [NSIS] question on 5.3.3
>
>
> Marco:
>
>   I fully agree that resource = allocations need to have the option for
> finite life times.
>
>   However, I am unclear as to how 1) = versus 2) would change
> the semantics
> of the protocol? As opposed to the semantics of = resource reservation
> algorithms
> at a given node?
>
>   To state this in another fashion, = if I attached a protocol
> analyzer to a link carrying NSIS, what protocol = semantics could
> I capture that would reflect this resource = timing?
>
> Gary
>
> > -----Original Message-----
> > From: Schneider, Marco [ mailto:schneider@tri.sbc.com
> <mailto:schneider@tri.sbc.com&g= t; ]
> > Sent: April 3, 2002 15:22
> > To: Kenward, Gary [WDLN2:AN10:EXCH]; = 'NSIS'
> > Subject: RE: [NSIS] question on = 5.3.3
> > Sensitivity: Confidential
> >
> >
> > To me this is part of the semantics of the = protocol. My
> > requirement is that
> > the protocol support the following two = behaviours:
> >
> > 1) When the QOS Initiator goes down, the = resources it
> > requested will be
> > released
> > 2) When the QOS Initiator goes down, the = resources it
> > requested will not be
> > released
> >
> > The reason for supporting behaviour #2 is = the case where an
> > entity in the
> > network proxy signals on behalf of a large = number of
> > customers. We want the
> > ability for the corresponding connections = to stay up should a
> > controller
> > fail. For policy reasons we may want to = require that behaviour #1 be
> > enforced for some customers. Obviously if = a customer is paying for a
> > connection that would want #1 to be = enforced as well.
> >
> > Cheers,
> > Marco
> >
> >
> >
> > > -----Original Message-----
> > > From: Gary Kenward [ mailto:gkenward@nortelnetwor= ks.com
> <mailto:gkenward@nortelnetwor= ks.com> ]
> > > Sent: Wednesday, April 03, 2002 2:02 = PM
> > > To: 'NSIS'
> > > Subject: [NSIS] question on = 5.3.3
> > > Sensitivity: Confidential
> > >
> > >
> > > Hello:
> > >
> > > I have a question regarding one of = the requirements:
> > >
> > > 5.3.3 Possibility for automatic = release of resources after failure
> > >
> > >    When the QoS = Initiator goes down, the resources it
> > requested should
> > >    be released, since = they will no longer be necessary.
> > >
> > > This does not seem to me to be a = protocol requirement nor a
> > framework
> > > requirement, but rather an = implementation requirement.
> > >
> > > Does this matter?
> > >
> > > Thanks,
> > > Gary
> > >
> > >
> > >
> > >
> > >
> > > = _______________________________________________
> > > nsis mailing list
> > > nsis@ietf.org
> > > https://www1.ietf.org/mailman/listinfo/nsis=
> <https://www1.ietf.org/mailman/listinfo/nsis>
> > >
> >
>
>
> (See attached file: att1.htm)
>
>

------_=_NextPart_001_01C1DBFD.C86220CC-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu Apr 4 12:46:17 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25430 for ; Thu, 4 Apr 2002 12:46:17 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA19565 for nsis-archive@odin.ietf.org; Thu, 4 Apr 2002 12:46:18 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA18031; Thu, 4 Apr 2002 12:26:09 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA17952 for ; Thu, 4 Apr 2002 12:26:02 -0500 (EST) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24316 for ; Thu, 4 Apr 2002 12:25:58 -0500 (EST) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g34HPOP10898; Thu, 4 Apr 2002 12:25:25 -0500 (EST) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 4 Apr 2002 12:25:27 -0500 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA49BC@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'john.loughney@nokia.com'" , nsis@ietf.org Subject: RE: [NSIS] notes from L2 Triggers meeting Date: Thu, 4 Apr 2002 12:25:24 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DBFD.A19F2598" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1DBFD.A19F2598 Content-Type: text/plain; charset="iso-8859-1" Sounds like it was a very productive meeting. Perhaps they should start serving beer at the wg meetings ;^} Gary > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: April 4, 2002 01:30 > To: nsis@ietf.org > Subject: [NSIS] notes from L2 Triggers meeting > > > L2-Trigger unofficial meeting > > Tuesday, March 18th, 2002 > IETF-53 Minneapolis, MN > > led by (& notes taken by) > Aaron Falk and > Carl Williams > attendance: about 55 people > > (beer courtesy of NTT DoCoMo) > > ============================= > > Based on interest from folks engaged in manet, mobileip, and seamoby > working groups, an unofficial meeting was held to discuss issues > surrounding the triggers at layer 2 to communicate information to > upper layers in a hosts protocol stack. Two drafts, one discussing > the issues (draft-manyfolks-l2-mobilereq-01.txt) and another proposing > an API (draft-guri-seamoby-paging-trigger-00.txt) had been previously > submitted. The objective of the meeting was to discover if the scope > should be more broad than the drafts proposed. This was accomplished > by a somewhat unstructured discussion that touched on several topics > including what information to express, how it is delivered, and some > possible next steps. The conversation and some perceived conclusions > are summarized below. > > WHAT TO EXPRESS > > Not a new problem, past experience likely useful: > > The need for communication about L2 state to L3 is not new. > Routers have > been handling it, largely with proprietary means for years. > Routers are in > fact the canonical customers for this function; they by > definition perform > their principal L3 function based on L2 state info. Routing > folks have > learned a lot about how links lie about their state (e.g., > links that fail > half-duplex). > > In fact, router manufacturers may have insight as to which > metrics would be > of interest or possibly how to extend or abstract them if > they are willing > to share the information. Getting input from people familiar > with routing > would be valuable. > > Small set of common functions seen as useful: > > The most common need expressed for information to be revealed was a > link up/down indicator. This might be extended to be a table > containing reachability to multiple access points for technologies > where that is possible. (There already exists an appropriate SNMP > message but it appears to be largely unused.) > > Interaction with MobileIP: > > In mobileIP on a wireless link, an L3 handover may, but does > not always, > occur when the mobile node moves to a new access point. Link layer > protocols provide more accurate, and possibly timelier, reachability > information than L3 'hello' protocols. There is great benefit if a > mobileIP L3 can learn that a handover is imminent, rather than waiting > until after the old link is gone. Early warning may allow mobileIP to > optimize the L3 hand-off process in a number of ways, such as > triggering an > L3 early hand-off or moving context to the new router. > > Discussion about architectural principles and amount of > revealed information: > > It was suggested that it might be valuable to reveal *any* > information that > might be of interest to any part of the host, e.g., bit error > rate, or link > bandwidth. For example, a video codec (e.g., MPEG-4) might behave > differently if it was aware of the bit error rate of the > wireless link. > This was widely thought to be a bad idea as it suggests an > architecture > which is not general - leading to applications that are too > tightly bound to > specific link types or depend on the assumption that the > 'difficult' link > is the one nearest the end host. The Internet layer, as the > 'waist in the > protocol hourglass' insulates the application from the link > layer. The > question of what information ought to be passed up from L3 is > separate from > what info L3 could usefully get from L2, and should be considered > separately. Only a very limited, general set of parameters would be > appropriate above L3 and defining appropriate parameters based on link > characteristics is a very difficult task. Even adding a > metric such as > signal strength is difficult when link technologies are heterogeneous. > > Some other caveats that were suggested: Triggers should only enable > performance enhancements and not be used for correct protocol > operation. There's value in finding implicit rather than explicit > mechanisms. Again: the focus should be firmly on L2/L3 communication, > rather than enabling applications (or, presumably, transport) to > interact directly with L2. Apps can fight with L3 if it's done wrong. > > Management applications considered a special case: > > In the context of the above discussion, management > applications were seen > as a special case that might require greater access to link > information > than would normally be made available to normal applications (or even > protocol stack internals). This is because the application is > intentionally associated with the management of a specific L2 > technology. > For example, 802.11 cards typically come with a management > application that > reveals information about the card status, link status, and access > point(s). This information is necessary to ensure the > correct functioning > of the card and should not be considered an Internet network > application. > > HOW IS L2 INFORMATION DELIVERED > > Options for how to implement L2/3 communication include an > API, a MIB, or a > protocol. Most of the applications discussed above do not require > communication across the wire and so a protocol does not seem to be > justified or appropriate. It's unclear whether an API or MIB is more > appropriate. MIBs were considered by some as somewhat 'heavyweight' > because accessing local information typically requires SNMP > to localhost > and implies ASN.1 marshaling that is not needed in this > situation. This > issue is particularly important to small memory and > power-limited wireless > devices. > > Most participants agreed that the difficult task that needs > to be done is to > determine the right set of metrics to abstract and capture > them in a common > location. It was widely recognized that the question of MIB or API is > really secondary to the question of what information should be passed > between L2 and L3. In the IETF, that process is frequently > captured in a > MIB. However, since the issue is really a matter of internal > communication > within a host, it may not be necessary to standardize or even > specify the > format or mechanism which is used to communicate across the > L2/L3 boundary. > > SOME NEXT STEPS > > Since the IETF doesn't develop link technologies, one output > of an IETF > effort might include an informational RFC on which information to > export/reveal. This document will likely be of interest to > other standards > bodies who standardize link technologies. (Some of these ideas have > already been taken to IEEE 802.11. The IEEE is also working > on related > issues in the context of OAM.) This might be considered a > natural extension > of the PILC working group document "Advice to Subnet Designers." > > The IESG will provide advice as to the next process steps. They could > include doing the work in PILC, possibly requiring rechartering, > holding a BoF, creating a new working group, or possibly just an > individual RFC submission. For the moment, the discussion should take > place on the PILC mail list. Subscription instructions are available > through the working group charter page at > http://www.ietf.org/html.charters/pilc-charter.html. Should the work > take place in a seperate working group, naturally a new mailing list > will be formed. > > --aaron (for aaron and carl) > > Postscript > > In the wireless directorate meeting (of chairs of > wireless-related working > groups, it was suggested that besides advising link > designers, we should > also consider an advisory document to upper layers on how to handle L2 > information. > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > ------_=_NextPart_001_01C1DBFD.A19F2598 Content-Type: text/html; charset="iso-8859-1" RE: [NSIS] notes from L2 Triggers meeting

Sounds like it was a very productive meeting.
Perhaps they should start serving beer at the wg meetings ;^}

Gary

> -----Original Message-----
> From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]
> Sent: April 4, 2002 01:30
> To: nsis@ietf.org
> Subject: [NSIS] notes from L2 Triggers meeting
>
>
> L2-Trigger unofficial meeting
>
> Tuesday, March 18th, 2002
> IETF-53 Minneapolis, MN
>
> led by (& notes taken by)
> Aaron Falk <falk@isi.edu> and
> Carl Williams <carlw@docomolabs-usa.com>
> attendance: about 55 people
>
> (beer courtesy of NTT DoCoMo)
>
> =============================
>
> Based on interest from folks engaged in manet, mobileip, and seamoby
> working groups, an unofficial meeting was held to discuss issues
> surrounding the triggers at layer 2 to communicate information to
> upper layers in a hosts protocol stack.  Two drafts, one discussing
> the issues (draft-manyfolks-l2-mobilereq-01.txt) and another proposing
> an API (draft-guri-seamoby-paging-trigger-00.txt) had been previously
> submitted.  The objective of the meeting was to discover if the scope
> should be more broad than the drafts proposed.  This was accomplished
> by a somewhat unstructured discussion that touched on several topics
> including what information to express, how it is delivered, and some
> possible next steps.  The conversation and some perceived conclusions
> are summarized below.
>
> WHAT TO EXPRESS
>
> Not a new problem, past experience likely useful:
>
> The need for communication about L2 state to L3 is not new. 
> Routers have
> been handling it, largely with proprietary means for years. 
> Routers are in
> fact the canonical customers for this function; they by
> definition perform
> their principal L3 function based on L2 state info.  Routing
> folks have
> learned a lot about how links lie about their state (e.g.,
> links that fail
> half-duplex).
>
> In fact, router manufacturers may have insight as to which
> metrics would be
> of interest or possibly how to extend or abstract them if
> they are willing
> to share the information.  Getting input from people familiar
> with routing
> would be valuable.
>
> Small set of common functions seen as useful:
>
> The most common need expressed for information to be revealed was a
> link up/down indicator.  This might be extended to be a table
> containing reachability to multiple access points for technologies
> where that is possible.  (There already exists an appropriate SNMP
> message but it appears to be largely unused.)
>
> Interaction with MobileIP:
>
> In mobileIP on a wireless link, an L3 handover may, but does
> not always,
> occur when the mobile node moves to a new access point.  Link layer
> protocols provide more accurate, and possibly timelier, reachability
> information than L3 'hello' protocols.  There is great benefit if a
> mobileIP L3 can learn that a handover is imminent, rather than waiting
> until after the old link is gone.  Early warning may allow mobileIP to
> optimize the L3 hand-off process in a number of ways, such as
> triggering an
> L3 early hand-off or moving context to the new router.
>
> Discussion about architectural principles and amount of
> revealed information:
>
> It was suggested that it might be valuable to reveal *any*
> information that
> might be of interest to any part of the host, e.g., bit error
> rate, or link
> bandwidth.  For example, a video codec (e.g., MPEG-4) might behave
> differently if it was aware of the bit error rate of the
> wireless link.
> This was widely thought to be a bad idea as it suggests an
> architecture
> which is not general - leading to applications that are too
> tightly bound to
> specific link types or depend on the assumption that the
> 'difficult' link
> is the one nearest the end host.  The Internet layer, as the
> 'waist in the
> protocol hourglass' insulates the application from the link
> layer.  The
> question of what information ought to be passed up from L3 is
> separate from
> what info L3 could usefully get from L2, and should be considered
> separately.  Only a very limited, general set of parameters would be
> appropriate above L3 and defining appropriate parameters based on link
> characteristics is a very difficult task.  Even adding a
> metric such as
> signal strength is difficult when link technologies are heterogeneous.
>
> Some other caveats that were suggested: Triggers should only enable
> performance enhancements and not be used for correct protocol
> operation.  There's value in finding implicit rather than explicit
> mechanisms.  Again: the focus should be firmly on L2/L3 communication,
> rather than enabling applications (or, presumably, transport) to
> interact directly with L2.  Apps can fight with L3 if it's done wrong.
>
> Management applications considered a special case:
>
> In the context of the above discussion, management
> applications were seen
> as a special case that might require greater access to link
> information
> than would normally be made available to normal applications (or even
> protocol stack internals).  This is because the application is
> intentionally associated with the management of a specific L2
> technology.
> For example, 802.11 cards typically come with a management
> application that
> reveals information about the card status, link status, and access
> point(s).  This information is necessary to ensure the
> correct functioning
> of the card and should not be considered an Internet network
> application.
>
> HOW IS L2 INFORMATION DELIVERED
>
> Options for how to implement L2/3 communication include an
> API, a MIB, or a
> protocol.  Most of the applications discussed above do not require
> communication across the wire and so a protocol does not seem to be
> justified or appropriate.  It's unclear whether an API or MIB is more
> appropriate.  MIBs were considered by some as somewhat 'heavyweight'
> because accessing local information typically requires SNMP
> to localhost
> and implies ASN.1 marshaling that is not needed in this
> situation.  This
> issue is particularly important to small memory and
> power-limited wireless
> devices.
>
> Most participants agreed that the difficult task that needs
> to be done is to
> determine the right set of metrics to abstract and capture
> them in a common
> location.  It was widely recognized that the question of MIB or API is
> really secondary to the question of what information should be passed
> between L2 and L3.  In the IETF, that process is frequently
> captured in a
> MIB. However, since the issue is really a matter of internal
> communication
> within a host, it may not be necessary to standardize or even
> specify the
> format or mechanism which is used to communicate across the
> L2/L3 boundary.
>
> SOME NEXT STEPS
>
> Since the IETF doesn't develop link technologies, one output
> of an IETF
> effort might include an informational RFC on which information to
> export/reveal.  This document will likely be of interest to
> other standards
> bodies who standardize link technologies.  (Some of these ideas have
> already been taken to IEEE 802.11.  The IEEE is also working
> on related
> issues in the context of OAM.) This might be considered a
> natural extension
> of the PILC working group document "Advice to Subnet Designers."
>
> The IESG will provide advice as to the next process steps.  They could
> include doing the work in PILC, possibly requiring rechartering,
> holding a BoF, creating a new working group, or possibly just an
> individual RFC submission.  For the moment, the discussion should take
> place on the PILC mail list.  Subscription instructions are available
> through the working group charter page at
> http://www.ietf.org/html.charters/pilc-charter.html.  Should the work
> take place in a seperate working group, naturally a new mailing list
> will be formed.
>
> --aaron (for aaron and carl)
>
> Postscript
>
> In the wireless directorate meeting (of chairs of
> wireless-related working
> groups, it was suggested that besides advising link
> designers, we should
> also consider an advisory document to upper layers on how to handle L2
> information.
>
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis
>

------_=_NextPart_001_01C1DBFD.A19F2598-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu Apr 4 13:00:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28516 for ; Thu, 4 Apr 2002 13:00:11 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA20375 for nsis-archive@odin.ietf.org; Thu, 4 Apr 2002 13:00:13 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA19215; Thu, 4 Apr 2002 12:40:23 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA19138 for ; Thu, 4 Apr 2002 12:40:18 -0500 (EST) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24852 for ; Thu, 4 Apr 2002 12:40:16 -0500 (EST) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g34Hbuv21469; Thu, 4 Apr 2002 12:37:56 -0500 (EST) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 4 Apr 2002 12:37:47 -0500 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA49BE@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'brunner@ccrle.nec.de'" , "Geib, Ruediger" , svenvandenbosch@hotmail.com Cc: nsis@ietf.org Subject: RE: pre-emption (was RE: [NSIS] proposals related to NSIS WG draf t) Date: Thu, 4 Apr 2002 12:37:41 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DBFE.80031E8E" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1DBFE.80031E8E Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I guess my main issue is that this "requirement" seems to embed definitions of flow treatment in the definition of the signalling protocol. This, to me, is simply the wrong thing to do, unless there is not clear reason why the two cannot be kept separate. I haven't heard this reason. BTW: the priority of a flow IS coupled to it's QoS requirements. As a counter example, what does an low priority EF flow mean? Could you support EF PHB for a flow if it had a "lower priority" (where lower priority implies a higher liklihood of pre-emption of service) then an AF or BE flow within a router? The answer is, very probably = not. Let's not debate QoS definitions in NSIS. I think John has stated that QoS definition is out of scope for NSIS, and declaring a particular = flow treatment such as priority as not being QoS doesn't help. Gary > -----Original Message----- > From: Marcus Brunner [mailto:brunner@ccrle.nec.de] > Sent: April 4, 2002 06:40 > To: Geib, Ruediger; svenvandenbosch@hotmail.com > Cc: nsis@ietf.org > Subject: pre-emption (was RE: [NSIS] proposals related to=20 > NSIS WG draft) >=20 >=20 > As Ruediger I would like to hear some other opinions as well.=20 > I think the=20 > whole fault handling is an open issue anyway and preempting=20 > flows might=20 > play a roll in fault handling as well. >=20 > Marcus >=20 > --On Tuesday, April 02, 2002 4:27 PM +0200 "Geib, Ruediger"=20 > wrote: >=20 > > Hi Sven, > > > > the comment is a bit late, but I've been offline for a while. > > Nevertheless: > > > >> * New requirements > >> - in section MUST support priority > >> The priority of a flow is essentially decoupled from > >> its QoS requirements. Therefore the protocol MUST > >> support priority. As a consequence, it MUST support > >> preemption of traffic flows in case of congestion or > >> failure. A preemption action MAY trigger an attempt > >> to resetup the request by means of another instance > >> of an NSIS signaling protocol. > > > > Could you provide some clearer argumentation why > > preemption is a requirement? I'd classify preemption > > as a "nice to have" feature, no more than a "MAY" > > requirement. I'd especially insist on preemption being > > completely decoupled from QoS and any other service > > related signalling. > > I.e. if it is not supported by an opperator, no > > parameters or messages related to preemption are > > to be transported. > > > > I'd like to ask other representatives of operators for > > their view. > > > > Regards, R=FCdiger > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis >=20 >=20 >=20 > -------------------------------------- > Dr. Marcus Brunner > Network Laboratories > NEC Europe Ltd. >=20 > E-Mail: brunner@ccrle.nec.de > WWW: http://www.ccrle.nec.de/ > personal home page: http://www.brubers.org/marcus >=20 >=20 >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 ------_=_NextPart_001_01C1DBFE.80031E8E Content-Type: text/html; charset="iso-8859-1" RE: pre-emption (was RE: [NSIS] proposals related to NSIS WG draft)

I guess my main issue is that this "requirement" seems to embed
definitions of flow treatment in the definition of the signalling
protocol. This, to me, is simply the wrong thing to do, unless there
is not clear reason why the two cannot be kept separate. I haven't
heard this reason.

BTW: the priority of a flow IS coupled to it's QoS requirements.
As a counter example, what does an low priority EF flow mean?
Could you support EF PHB for a flow if it had a "lower priority" (where
lower priority implies a higher liklihood of pre-emption of service)
then an AF or BE flow within a router? The answer is, very probably not.

Let's not debate QoS definitions in NSIS. I think John has stated that
QoS definition is out of scope for NSIS, and declaring a particular flow
treatment such as priority as not being QoS doesn't help.

Gary

> -----Original Message-----
> From: Marcus Brunner [mailto:brunner@ccrle.nec.de]
> Sent: April 4, 2002 06:40
> To: Geib, Ruediger; svenvandenbosch@hotmail.com
> Cc: nsis@ietf.org
> Subject: pre-emption (was RE: [NSIS] proposals related to
> NSIS WG draft)
>
>
> As Ruediger I would like to hear some other opinions as well.
> I think the
> whole fault handling is an open issue anyway and preempting
> flows might
> play a roll in fault handling as well.
>
> Marcus
>
> --On Tuesday, April 02, 2002 4:27 PM +0200 "Geib, Ruediger"
> <Ruediger.Geib@t-systems.com> wrote:
>
> > Hi Sven,
> >
> > the comment is a bit late, but I've been offline for a while.
> > Nevertheless:
> >
> >> * New requirements
> >> - in section MUST support priority
> >>   The priority of a flow is essentially decoupled from
> >>   its QoS requirements. Therefore the protocol MUST
> >>   support priority. As a consequence, it MUST support
> >>   preemption of traffic flows in case of congestion or
> >>   failure. A preemption action MAY trigger an attempt
> >>   to resetup the request by means of another instance
> >>   of an NSIS signaling protocol.
> >
> > Could you provide some clearer argumentation why
> > preemption is a requirement? I'd classify preemption
> > as a "nice to have" feature, no more than a "MAY"
> > requirement. I'd especially insist on preemption being
> > completely decoupled from QoS and any other service
> > related signalling.
> > I.e. if it is not supported by an opperator, no
> > parameters or messages related to preemption are
> > to be transported.
> >
> > I'd like to ask other representatives of operators for
> > their view.
> >
> > Regards, Rüdiger
> >
> > _______________________________________________
> > nsis mailing list
> > nsis@ietf.org
> > https://www1.ietf.org/mailman/listinfo/nsis
>
>
>
> --------------------------------------
> Dr. Marcus Brunner
> Network Laboratories
> NEC Europe Ltd.
>
> E-Mail: brunner@ccrle.nec.de
> WWW:    http://www.ccrle.nec.de/
> personal home page: http://www.brubers.org/marcus
>
>
>
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis
>

------_=_NextPart_001_01C1DBFE.80031E8E-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu Apr 4 15:32:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07788 for ; Thu, 4 Apr 2002 15:32:46 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA00482 for nsis-archive@odin.ietf.org; Thu, 4 Apr 2002 15:32:49 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA29565; Thu, 4 Apr 2002 15:23:17 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA29532 for ; Thu, 4 Apr 2002 15:23:14 -0500 (EST) Received: from idcpa4.pa.interdigital.com (idcmail.interdigital.com [12.32.197.142]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07355 for ; Thu, 4 Apr 2002 15:23:11 -0500 (EST) Received: by idcpa4.pa.interdigital.com with Internet Mail Service (5.5.2653.19) id ; Thu, 4 Apr 2002 15:21:38 -0500 Message-ID: From: "Shahrier, Sharif M." To: "'brunner@ccrle.nec.de'" , "Shahrier, Sharif M." Cc: nsis@ietf.org Subject: RE: [NSIS] On the definition of QoS flow and aggregate flow. Date: Thu, 4 Apr 2002 15:21:32 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Marcus, The question was how to derive the QSCs, and I suggested that the QSCs can be mappable from a set of performance metrics that capture the constraints on the QoS. My understanding from your message is that NSIS is not required to come up with a standardized performance metrics? However, the notion of QSCs are in the draft, which I support, and hoping to send text shortly to the list on its classification. Sharif. -----Original Message----- From: Marcus Brunner [mailto:brunner@ccrle.nec.de] Sent: Thursday, April 04, 2002 8:22 AM To: Shahrier, Sharif M. Cc: nsis@ietf.org Subject: Re: [NSIS] On the definition of QoS flow and aggregate flow. Sharif, I got the feeling in MPLS WG meeting that defining QoS parameters (or more general service descripions is currently out of scope of the NSIS work. We even have a number of requirements in the -00 draft that are service specific and will be removed. Marcus --On Wednesday, April 03, 2002 3:27 PM -0500 "Shahrier, Sharif M." wrote: > In the NSIS requirement draft, I have some points for discussion on the > definition of a "flow" from the presective of NSIS, and also on the > definition of "aggregate flow". > > I feel these need to be defined more fully in terms of QoS. > > It is defined in the requirements draft, that: > > A flow is a traffic stream between two endpoints for which "a specific > level of QoS is provided". > > My question is how to characterize such a flow in terms of quantitative > QoS parameters. > > A set of QoS parameters can be standardized for a flow. These parameters > could be: > > Maximum delay > Minimum throughput > Maximum response time (assuming buffering) > Maximum jitter > ....... > > These parameters should then be mapped to a specific "priority value", > i.e. a single parameter. > > The parameter can relate directly to ABR, CBR, UBR, ......... types of > flow. > > A 6-tuple (src. addr, dest. addr., src. port nbr., dest. port nbr, > protoID, Priority) should characterize a "flow" as far as the > requirements for NSIS working group. > > Having a single priority value would make it much easier to quantify QoS > to define a flow, as opposed to a whole set of parameters like delay, > throughput, jitter ............ > > A flow aggregate can be defined as a set of flows, where each flow has the > same QoS priority. > > Thus, a coarse grain, single QoS priority for "flow" characterization can > help to readily gather flows with the same priority value into a set to > form an aggregate flow set. > > Comments and feedback please......... > > Sharif. > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ personal home page: http://www.brubers.org/marcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu Apr 4 15:58:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08481 for ; Thu, 4 Apr 2002 15:58:15 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA01527 for nsis-archive@odin.ietf.org; Thu, 4 Apr 2002 15:58:15 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA00701; Thu, 4 Apr 2002 15:36:37 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA00670 for ; Thu, 4 Apr 2002 15:36:34 -0500 (EST) Received: from idcpa4.pa.interdigital.com (idcmail.interdigital.com [12.32.197.142]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07856 for ; Thu, 4 Apr 2002 15:36:31 -0500 (EST) Received: by idcpa4.pa.interdigital.com with Internet Mail Service (5.5.2653.19) id ; Thu, 4 Apr 2002 15:34:58 -0500 Message-ID: From: "Shahrier, Sharif M." To: "Shahrier, Sharif M." Cc: "'nsis@ietf.org'" Subject: [NSIS] Establishing QoS after handoff. Date: Thu, 4 Apr 2002 15:34:56 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org I have a question for clarification. I think it was stated that NSIS should only be concerned with the establishment of QoS after handoff. This is inconvienent with respect to IP-level QoS negotiation, which ideally should be done before handoff has taken place. QoS negotiation is in the current requirements draft. So, NSIS signaling protocol development should be concerned with activity before handoff occurs. Sharif. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu Apr 4 16:31:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09674 for ; Thu, 4 Apr 2002 16:31:44 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA03862 for nsis-archive@odin.ietf.org; Thu, 4 Apr 2002 16:31:48 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA03066; Thu, 4 Apr 2002 16:24:50 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA03035 for ; Thu, 4 Apr 2002 16:24:48 -0500 (EST) Received: from idcpa4.pa.interdigital.com (idcmail.interdigital.com [12.32.197.142]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09345 for ; Thu, 4 Apr 2002 16:24:43 -0500 (EST) Received: by idcpa4.pa.interdigital.com with Internet Mail Service (5.5.2653.19) id ; Thu, 4 Apr 2002 16:23:10 -0500 Message-ID: From: "Shahrier, Sharif M." To: "Shahrier, Sharif M." Cc: "'nsis@ietf.org'" Subject: [NSIS] IP packet scheduler with QoS control. Date: Thu, 4 Apr 2002 16:23:06 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org If anyone has references on IP packet schedulers with QoS capability, I'd appreciate if you can send me information. I'd also be interested to know if you're working on such projects. Thanks. Sharif. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu Apr 4 16:38:52 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09878 for ; Thu, 4 Apr 2002 16:38:52 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA04307 for nsis-archive@odin.ietf.org; Thu, 4 Apr 2002 16:38:55 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA03971; Thu, 4 Apr 2002 16:32:36 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA03930 for ; Thu, 4 Apr 2002 16:32:33 -0500 (EST) Received: from auds953.usa.alcatel.com (auds953.usa.alcatel.com [143.209.238.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09709 for ; Thu, 4 Apr 2002 16:32:29 -0500 (EST) Received: from morgoth.pet.usa.alcatel.com (localhost [127.0.0.1]) by auds953.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g34LW1605543; Thu, 4 Apr 2002 15:32:01 -0600 (CST) Received: from alcatel.com (localhost [127.0.0.1]) by morgoth.pet.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g34LVxW29325; Thu, 4 Apr 2002 13:31:59 -0800 (PST) Message-ID: <3CACC64F.1FD831@alcatel.com> Date: Thu, 04 Apr 2002 13:31:59 -0800 From: Mudhafar Hassan-Ali Organization: Alcatel, USA X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Shahrier, Sharif M." CC: "'nsis@ietf.org'" Subject: Re: [NSIS] IP packet scheduler with QoS control. References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit If you are asking about the actual design of IP packet scheduling algorithms, then try to see: http://www-2.cs.cmu.edu/~hzhang/ Hui Zhang is very active in this field. Mudhafar "Shahrier, Sharif M." wrote: > If anyone has references on IP packet schedulers with QoS capability, I'd > appreciate if you can send me information. > > I'd also be interested to know if you're working on such projects. > > Thanks. > > Sharif. > > _______________________________________________ > 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 daemon@optimus.ietf.org Thu Apr 4 16:53:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10193 for ; Thu, 4 Apr 2002 16:53:50 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA04954 for nsis-archive@odin.ietf.org; Thu, 4 Apr 2002 16:53:53 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA04699; Thu, 4 Apr 2002 16:45:43 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA04670 for ; Thu, 4 Apr 2002 16:45:41 -0500 (EST) Received: from nazare.cin.ufpe.br ([150.161.2.30]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10002 for ; Thu, 4 Apr 2002 16:45:32 -0500 (EST) Received: from zumbi.cin.ufpe.br (zumbi [172.19.33.201]) by nazare.cin.ufpe.br (8.11.6/8.11.6) with ESMTP id g34BjhY78470; Thu, 4 Apr 2002 08:45:43 -0300 (EST) (envelope-from jamel@cin.ufpe.br) Received: from localhost (jamel@localhost) by zumbi.cin.ufpe.br (8.9.3+Sun/8.9.1) with ESMTP id IAA18813; Thu, 4 Apr 2002 08:45:43 -0300 (EST) X-Authentication-Warning: zumbi.cin.ufpe.br: jamel owned process doing -bs Date: Thu, 4 Apr 2002 08:45:43 -0300 (EST) From: "DJamel H. Sadok" X-X-Sender: To: "Shahrier, Sharif M." cc: , Carlos Alberto Kamienski Subject: Re: [NSIS] On the definition of QoS flow and aggregate flow. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org > Having a single priority value would make it much easier to quantify QoS to > define a flow, as opposed to a whole set of parameters like delay, > throughput, jitter ............ > I did not follow this thread and consequently I am not sure of what a priority in this context is, but it seems to me that it would mean some information that refers to a set of QoS parameters for a given flow. So, why not consider the use of well known services (WKS) and defining well known service ids (WKS-IDs) as some class of a service specification with delay, bandwidth, etc.. information and use a flow-id or a WKS-ID to refer to it. Of course there is the problem of having these predefined for scalability. I am using the term service here to refer to a class of flows with some common QoS characteristics. The goal here is NOT to define services but to identify using these WKS-IDs some classes and build some templates for them that some domains may aggree to use for end-to-end QoS. So for example in the DSCP field one may have this WKS-ID that represents an aggreagate flow class and which may locally be mapped to any QoS domain specific technology (IntServ, DiffServ, over provisionning, ...) Their mapping depends on the local domain policies and its QoS technology. Flows may be aggregated at the domain for example if we have two flows that require delay values of 10ms and 5 ms, a domain may aggregate both specifications and offer resources for the aggregate as long as the delay is maintained bellow 5 ms. Of course considering this field, only a limited number of classes may be defined, so if we need to maintain information on individual flows and not simply on their aggregates, for example to deal with those that may breach access policies or apply admission or other control, then another field may be used to contain flow ids. Djamel > A flow aggregate can be defined as a set of flows, where each flow has the > same QoS priority. > > Thus, a coarse grain, single QoS priority for "flow" characterization can > help to readily gather flows with the same priority value into a set to form > an aggregate flow set. > > Comments and feedback please......... > > Sharif. > > > _______________________________________________ > 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 daemon@optimus.ietf.org Thu Apr 4 17:26:42 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11123 for ; Thu, 4 Apr 2002 17:26:42 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA07146 for nsis-archive@odin.ietf.org; Thu, 4 Apr 2002 17:26:46 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA06987; Thu, 4 Apr 2002 17:20:51 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA06956 for ; Thu, 4 Apr 2002 17:20:49 -0500 (EST) Received: from hunter.ee.tu-berlin.de (pD9E100FA.dip.t-dialin.net [217.225.0.250]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10964 for ; Thu, 4 Apr 2002 17:20:44 -0500 (EST) Received: from hunter ([127.0.0.1]) by hunter.ee.tu-berlin.de with Microsoft SMTPSVC(5.0.2172.1); Fri, 5 Apr 2002 00:19:24 +0200 Message-ID: <003901c1dc26$c6846d40$6b1dfea9@ee.tuberlin.de> Reply-To: "Xiaoming Fu" From: "Xiaoming Fu" To: "Shahrier, Sharif M." Cc: References: Subject: Re: [NSIS] Establishing QoS after handoff. Date: Fri, 5 Apr 2002 00:19:23 +0200 Organization: Telecommunication Networks Group, TU-Berlin MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-OriginalArrivalTime: 04 Apr 2002 22:19:24.0062 (UTC) FILETIME=[C685F3E0:01C1DC26] Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit Hi Sharif, I think most users will be glad to have a basic "best effort" service first during handoffs. However in the case a user wants the service only when the QoS can be met, beforehand or parrerally signal the QoS information so that the such a handoff can be made only upon this might be helpful. In this sense I agree with your concern regarding the sequence of QoS signaling(and establishment if necessary) and handoff. Decoupling QoS signaling and handoff is fine for NSIS design, but IMO there is also need for providing QoS for some stringent users. Regards Xiaoming ----- Original Message ----- From: "Shahrier, Sharif M." To: "Shahrier, Sharif M." Cc: Sent: Thursday, April 04, 2002 10:34 PM Subject: [NSIS] Establishing QoS after handoff. > > I have a question for clarification. > > I think it was stated that NSIS should only be concerned with the > establishment of QoS after handoff. > > This is inconvienent with respect to IP-level QoS negotiation, which ideally > should be done before handoff has taken place. > > QoS negotiation is in the current requirements draft. > > So, NSIS signaling protocol development should be concerned with activity > before handoff occurs. > > Sharif. > > > > _______________________________________________ > 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 daemon@optimus.ietf.org Thu Apr 4 22:39:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17890 for ; Thu, 4 Apr 2002 22:39:55 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA22701 for nsis-archive@odin.ietf.org; Thu, 4 Apr 2002 22:39:57 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA22460; Thu, 4 Apr 2002 22:32:53 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA22429 for ; Thu, 4 Apr 2002 22:32:51 -0500 (EST) Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17775 for ; Thu, 4 Apr 2002 22:32:47 -0500 (EST) From: Hemant.Chaskar@nokia.com Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g353XAs19032 for ; Thu, 4 Apr 2002 21:33:10 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 4 Apr 2002 21:32:50 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Thu, 4 Apr 2002 21:32:49 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] Establishing QoS after handoff. Date: Thu, 4 Apr 2002 22:32:48 -0500 Message-ID: Thread-Topic: [NSIS] Establishing QoS after handoff. Thread-Index: AcHcGKnaA4BqqIajRO2c17zwJ4xpLgAOVzUA To: X-OriginalArrivalTime: 05 Apr 2002 03:32:49.0510 (UTC) FILETIME=[8F719860:01C1DC52] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id WAA22430 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Sharif: There is currently a debate going on in Seamoby as to whether this QoS negotiation be covered by NSIS or Seamoby (CAR discovery protocol). IMHO it should be covered by CAR discovery and not NSIS. CAR discovery is supposed to identify candidate access routers for handoff and QoS is an important property for candidacy. Br, Hemant -----Original Message----- From: ext Shahrier, Sharif M. [mailto:Sharif.Shahrier@InterDigital.com] Sent: Thursday, April 04, 2002 3:35 PM To: Shahrier, Sharif M. Cc: 'nsis@ietf.org' Subject: [NSIS] Establishing QoS after handoff. I have a question for clarification. I think it was stated that NSIS should only be concerned with the establishment of QoS after handoff. This is inconvienent with respect to IP-level QoS negotiation, which ideally should be done before handoff has taken place. QoS negotiation is in the current requirements draft. So, NSIS signaling protocol development should be concerned with activity before handoff occurs. Sharif. _______________________________________________ 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 daemon@optimus.ietf.org Thu Apr 4 23:29:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18725 for ; Thu, 4 Apr 2002 23:29:28 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id XAA24719 for nsis-archive@odin.ietf.org; Thu, 4 Apr 2002 23:29:31 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA24685; Thu, 4 Apr 2002 23:28:12 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA24626 for ; Thu, 4 Apr 2002 23:28:06 -0500 (EST) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18639 for ; Thu, 4 Apr 2002 23:28:02 -0500 (EST) From: john.loughney@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g354SJ500353 for ; Fri, 5 Apr 2002 07:28:19 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 5 Apr 2002 07:28:00 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Fri, 5 Apr 2002 07:28:02 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] Re: text on layering - original mail Date: Fri, 5 Apr 2002 07:28:01 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD8E5E9@esebe004.NOE.Nokia.com> Thread-Topic: [NSIS] Re: text on layering - original mail Thread-Index: AcHb4uHOCnpySYkOQYyyD5EyM/+ZNQAdf3kg To: , Cc: X-OriginalArrivalTime: 05 Apr 2002 04:28:02.0402 (UTC) FILETIME=[4614CC20:01C1DC5A] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id XAA24628 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Marcus, > I got the feeling this might belong into a framework > document. I agree. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu Apr 4 23:29:39 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18753 for ; Thu, 4 Apr 2002 23:29:38 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id XAA24751 for nsis-archive@odin.ietf.org; Thu, 4 Apr 2002 23:29:41 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA24636; Thu, 4 Apr 2002 23:28:07 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA24601 for ; Thu, 4 Apr 2002 23:28:03 -0500 (EST) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18636 for ; Thu, 4 Apr 2002 23:27:59 -0500 (EST) From: john.loughney@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g354RCu02458 for ; Fri, 5 Apr 2002 07:27:12 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 5 Apr 2002 07:28:01 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Fri, 5 Apr 2002 07:28:01 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] requirement draft structure Date: Fri, 5 Apr 2002 07:28:00 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD8E5E8@esebe004.NOE.Nokia.com> Thread-Topic: [NSIS] requirement draft structure Thread-Index: AcHb1gZaF4uzZZ1pS8SqShrlU+CeewAgqYNw To: , X-OriginalArrivalTime: 05 Apr 2002 04:28:01.0236 (UTC) FILETIME=[4562E140:01C1DC5A] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id XAA24602 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Marcus, This sounds like a good proposal. I look forward to the new draft. John > At the IETF meeting in MPLS I proposed to change the structure of the > document in the following way. This mail just checks whether > there are > major concerns with that. > > The changes include > - put all the scenarios into an appendix > - In Section 6 add text describing 3 different "parts of the network" > -Host to first hop > -access network > -core networks > better names are welcome, but I don't want to be religious about it > > - Prioritize the requirements according to the "parts of the > network" (This > means the the tables in Section 6 of the current draft will get three > colums with the MUST, SHOULDs, and MAYs for each requirement _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Apr 5 00:25:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18726 for ; Thu, 4 Apr 2002 23:29:28 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id XAA24725 for nsis-archive@odin.ietf.org; Thu, 4 Apr 2002 23:29:31 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA24599; Thu, 4 Apr 2002 23:28:02 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA24564 for ; Thu, 4 Apr 2002 23:27:58 -0500 (EST) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18633 for ; Thu, 4 Apr 2002 23:27:54 -0500 (EST) From: john.loughney@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g354SB500318 for ; Fri, 5 Apr 2002 07:28:12 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 5 Apr 2002 07:27:57 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Fri, 5 Apr 2002 07:27:56 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] Establishing QoS after handoff. Date: Fri, 5 Apr 2002 07:27:55 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD8E5E5@esebe004.NOE.Nokia.com> Thread-Topic: [NSIS] Establishing QoS after handoff. Thread-Index: AcHcGKnaA4BqqIajRO2c17zwJ4xpLgAOVzUAAAFdhQA= To: , X-OriginalArrivalTime: 05 Apr 2002 04:27:56.0934 (UTC) FILETIME=[42D27260:01C1DC5A] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id XAA24565 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi all, Just to follow on to Hemant's comment: > There is currently a debate going on in Seamoby as to whether > this QoS negotiation be covered by NSIS or Seamoby (CAR > discovery protocol). > > IMHO it should be covered by CAR discovery and not NSIS. CAR > discovery is supposed to identify candidate access routers > for handoff and QoS is an important property for candidacy. CAR discovery may be used to select handoff targets with correct QoS support / capabilities. Context Transfer (CT) can be used with the handoff procedure to ensure proper QoS state gets transfered to the new access router. If there is anyone interested in this work, please let me know. The SeaMoby chairs asked me to see if NSIS can provide them any information about QoS needs. thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Apr 5 01:56:44 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20732 for ; Fri, 5 Apr 2002 01:56:42 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA11280 for nsis-archive@odin.ietf.org; Fri, 5 Apr 2002 01:56:45 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA11127; Fri, 5 Apr 2002 01:51:50 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA11095 for ; Fri, 5 Apr 2002 01:51:44 -0500 (EST) Received: from relay1.alcatel.be (alc119.alcatel.be [195.207.101.119]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20674 for ; Fri, 5 Apr 2002 01:51:40 -0500 (EST) From: sven.van_den_bosch@alcatel.be Received: from bemail04.net.alcatel.be (localhost [127.0.0.1]) by relay1.alcatel.be (8.10.1/8.10.1) with ESMTP id g356opd03691; Fri, 5 Apr 2002 08:51:01 +0200 (MET DST) Subject: Re: [NSIS] Re: text on layering - original mail To: brunner@ccrle.nec.de Cc: nsis@ietf.org X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Fri, 5 Apr 2002 08:50:40 +0200 X-MIMETrack: Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 04/05/2002 08:51:01 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi Marcus, I agree that it is primarily suited for a framework draft. However, we introduced it also as a rationale for the distinction between the different uses of an NSIS protocol. As such, it may have some relevance there too. Given the evolution of the requirements draft, I would agree to save this for inclusion in the framework. Sven. Marcus Brunner on 04/04/2002 16:23:58 Please respond to brunner@ccrle.nec.de To: Sven Van den Bosch cc: nsis@ietf.org(bcc: Sven VAN DEN BOSCH/BE/ALCATEL) Subject [NSIS] Re: text on layering - original mail : I got the feeling this might belong into a framework document. Or do you think it belongs into the reqs draft. Marcus --On Thursday, March 21, 2002 3:49 AM +0100 Sven Van den Bosch wrote: > Hi, > > We have been thinking about the QI/QC definitions and we have tried to > arrange the QC/QI functional entities in a logical relation that covers > the use case scenarios that have been proposed so far. From this, we hope > to derive clearer definitions. > > The general logical relationships are depicted below (for simplicity, only > signaling relations are drawn) > > +--+ (a) +--+ (a) +--+ (a) +---+ > +->|QI|---->|QC|---------------->|QC|---->| QR|--+ > QI,QC,QR roles for e2e QoS protocol > | +--+ /+--+\ /+--+\ +---+ | > | / \ / \ v > +--+ (b) +--+ +--+(b)+--+(b)+--+ +--+(b)+--+(b)+--+ +--+ (b) +--+ >| QI|---->|QR| |QI|-->|QC|-->|QR| |QI|-->|QC|-->|QR| |QI|---->|QR| > QI,QC,QR roles for local QoS protocol > +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ > > In this pictures we clearly distinguish two applications for the NSIS > protocol: > (a) NSIS as end-to-end QoS signaling protocol > (b) NSIS as local QoS signaling protocol > > Local, in this case, is defined as local to a QoS domain. A QoS domain is > defined as a contiguous part of the network supporting the same QoS > technology (e.g. RSVP). Note that for (a) NSIS is mandatory. For (b), NSIS > actually competes with other technologies offering local QoS, such as PDP, > RSVP, ... > > The above picture seems to suggest an out-of-band approach but this is not > the case. The QCs can be implemented in a distributed way and redrawing > the picture then gives a different view. > > +--+(a)+--+ (a) +--+(a)+--+ (a) +--+(a)+--+ > |QI|-->|QC|--------->|QC|-->|QC|--------->|QC|-->|QR| > QI,QC,QR roles for e2e QoS protocol > +--+ +--+ +--+ +--+ +--+ +--+ > ^ v ^ v ^ v > +--+ (b) +--+ +--+(b)+--+(b)+--+ +--+(b)+--+(b)+--+ +--+ (b) +--+ >| QI|---->|QR| |QI|-->|QC|-->|QR| |QI|-->|QC|-->|QR| |QI|---->|QR| > QI,QC,QR roles for local QoS protocol > +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ > > In this case, it is clear that an in-band solution is also supported. The > end-to-end QC/QI/QR and the local QC/QI/QR can then be colocated, e.g. on > a router. Note that in this picture, the signaling in the access is done > with a local QoS protocol. This can be either an existing protocol, or > the NSIS protocol in its role of local QoS signaling mechanism. This > leads to the following requirements: > > (a) If an NSIS protocol is only used end-to-end, then mobility need not be > supported > (b) If an NSIS protocol is used as a local QoS signaling mechanism then > mobility must be supported, both on the QI-QC and QC-QC interface > (c) If the same protocol is desired in (a) and (b), the protocol should be > modular and the mobility aspects need to be separable from the rest > > Both of the above scenarios assume that the host is not NSIS-aware. This > is a reasonable assumption in a first phase. In a later stage, when hosts > are NSIS-aware, the host speaks the NSIS protocol, but as a local QoS > signaling technology! This allows this case to be backwards compatible > with the above scenarios. It means that (b) in the access is an NSIS > protocol. It also means that the host will always trigger the local QoS > signaling mechanism. > > This suggests the following definitions for the QI, QC, QR > > - QoS Initiator: Network entity, located at the boundary of a QoS domain, > responsible for initiating a (local or end-to-end) QoS mechanism. If it is > the QI of a local protocol, it can be triggered by higher layers > (applications or end-to-end QoS Controller). If it is the QI of an > end-to-end protocol, it can be triggered by applications or by the QoS > Receiver of a local QoS signaling mechanism. > > - QoS Controller: Network entity responsible for interpreting and > implementing the signalled QoS in the network. Failure to do so implies an > admission control decision. It can only be triggered by a QI or another > QC. > > -QoS Receiver: Network entity, located at the boundary of a QoS domain, > responsible for terminating a (local or end-to-end) QoS mechanism. It has > the additional functionality that it may initiate an acknowledgment > towards the QI and that it may trigger a QI or QC in the NSIS end-to-end > protocol. > > If this can be accepted by the NSIS community, we propose to add this text > to the requirements document as a clarification of the QI/QC model that is > used there. > > > > > _________________________________________________________________ > Chat on line met vrienden en probeer MSN Messenger uit: > http://messenger.msn.nl > -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ personal home page: http://www.brubers.org/marcus _______________________________________________ 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 daemon@optimus.ietf.org Fri Apr 5 02:00:31 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21443 for ; Fri, 5 Apr 2002 02:00:31 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA11535 for nsis-archive@odin.ietf.org; Fri, 5 Apr 2002 02:00:33 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA11252; Fri, 5 Apr 2002 01:55:50 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA11221 for ; Fri, 5 Apr 2002 01:55:48 -0500 (EST) Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20701 for ; Fri, 5 Apr 2002 01:55:44 -0500 (EST) From: Hemant.Chaskar@nokia.com Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g356u7s26267 for ; Fri, 5 Apr 2002 00:56:07 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 5 Apr 2002 00:55:47 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Fri, 5 Apr 2002 00:54:24 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] Establishing QoS after handoff. Date: Fri, 5 Apr 2002 01:54:23 -0500 Message-ID: Thread-Topic: [NSIS] Establishing QoS after handoff. Thread-Index: AcHcGKnaA4BqqIajRO2c17zwJ4xpLgAOVzUAAAFdhQAABaehgA== To: X-OriginalArrivalTime: 05 Apr 2002 06:54:24.0321 (UTC) FILETIME=[B8834B10:01C1DC6E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id BAA11222 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi John: Some comments below: -----Original Message----- From: Loughney John (NRC/Helsinki) Sent: Thursday, April 04, 2002 11:28 PM To: Chaskar Hemant (NRC/Boston); nsis@ietf.org Subject: RE: [NSIS] Establishing QoS after handoff. Hi all, Just to follow on to Hemant's comment: > There is currently a debate going on in Seamoby as to whether > this QoS negotiation be covered by NSIS or Seamoby (CAR > discovery protocol). > > IMHO it should be covered by CAR discovery and not NSIS. CAR > discovery is supposed to identify candidate access routers > for handoff and QoS is an important property for candidacy. CAR discovery may be used to select handoff targets with correct QoS support / capabilities. Context Transfer (CT) can be used with the handoff procedure to ensure proper QoS state gets transfered to the new access router. [HC] I agree with this. If there is anyone interested in this work, please let me know. The SeaMoby chairs asked me to see if NSIS can provide them any information about QoS needs. [HC] Yes, NSIS protocol must have provisions to *accept* session's QoS data (transferred by CT) from new AR during QoS signalling. Still, IMHO target selection and CT aspects as such should be out of scope of NSIS. thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Apr 5 02:16:31 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29343 for ; Fri, 5 Apr 2002 02:16:30 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA12463 for nsis-archive@odin.ietf.org; Fri, 5 Apr 2002 02:16:32 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA12323; Fri, 5 Apr 2002 02:12:54 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA12292 for ; Fri, 5 Apr 2002 02:12:51 -0500 (EST) Received: from relay1.alcatel.be (alc119.alcatel.be [195.207.101.119]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29321 for ; Fri, 5 Apr 2002 02:12:45 -0500 (EST) From: sven.van_den_bosch@alcatel.be Received: from bemail04.net.alcatel.be (localhost [127.0.0.1]) by relay1.alcatel.be (8.10.1/8.10.1) with ESMTP id g357Bcv08315; Fri, 5 Apr 2002 09:11:47 +0200 (MET DST) Subject: RE: pre-emption (was RE: [NSIS] proposals related to NSIS WG draf t) To: "Gary Kenward" Cc: "'brunner@ccrle.nec.de'" , "Geib, Ruediger" , svenvandenbosch@hotmail.com, nsis@ietf.org X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Fri, 5 Apr 2002 09:11:16 +0200 X-MIMETrack: Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 04/05/2002 09:11:56 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Gary, >BTW: the priority of a flow IS coupled to it's QoS requirements. >As a counter example, what does an low priority EF flow mean? >Could you support EF PHB for a flow if it had a "lower priority" (where >lower priority implies a higher liklihood of pre-emption of service) >then an AF or BE flow within a router? The answer is, very probably not. I absolutely disagree on this one. Priority is related to the question how badly you want a certain connection to be set up and how badly you want to keep it in place once it is there. QoS refers to the characteristics for the flow once it is set up. In the TE-WG we came to the same conclusion regarding DiffServ and priority. They are completely orthogonal. Sven. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Apr 5 02:32:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29541 for ; Fri, 5 Apr 2002 02:32:24 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA13415 for nsis-archive@odin.ietf.org; Fri, 5 Apr 2002 02:32:25 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA12883; Fri, 5 Apr 2002 02:29:37 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA12848 for ; Fri, 5 Apr 2002 02:29:34 -0500 (EST) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29491 for ; Fri, 5 Apr 2002 02:29:30 -0500 (EST) From: john.loughney@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g357Tk510066 for ; Fri, 5 Apr 2002 10:29:47 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 5 Apr 2002 10:29:29 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Fri, 5 Apr 2002 10:29:31 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Fri, 5 Apr 2002 10:29:31 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64DD1@esebe004.NOE.Nokia.com> Thread-Topic: Interim Meeting Plan Thread-Index: AcHcc6DhU4Uu8cBLSh6tPI72PXyyxQ== To: X-OriginalArrivalTime: 05 Apr 2002 07:29:31.0962 (UTC) FILETIME=[A0C3C9A0:01C1DC73] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id CAA12849 Subject: [NSIS] Interim Meeting Plan Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi all, It seems the most likely candidate for the interim meeting will be: Helsinki, May 21 - 23 Does this work for everybody? Topics would include. 1) Requirements 2) Protocol Comparison 3) Framework Issues 4) Relations to other work thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Apr 5 02:52:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29748 for ; Fri, 5 Apr 2002 02:52:49 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA14040 for nsis-archive@odin.ietf.org; Fri, 5 Apr 2002 02:52:52 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA13933; Fri, 5 Apr 2002 02:48:29 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA13906 for ; Fri, 5 Apr 2002 02:48:27 -0500 (EST) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29724 for ; Fri, 5 Apr 2002 02:48:23 -0500 (EST) From: john.loughney@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g357lcu00732 for ; Fri, 5 Apr 2002 10:47:38 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 5 Apr 2002 10:48:25 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Fri, 5 Apr 2002 10:48:23 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] Establishing QoS after handoff. Date: Fri, 5 Apr 2002 10:48:23 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64DDA@esebe004.NOE.Nokia.com> Thread-Topic: [NSIS] Establishing QoS after handoff. Thread-Index: AcHcGKnaA4BqqIajRO2c17zwJ4xpLgAOVzUAAAFdhQAABaehgAACBSLw To: , X-OriginalArrivalTime: 05 Apr 2002 07:48:23.0512 (UTC) FILETIME=[43389D80:01C1DC76] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id CAA13907 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Hemant, > [HC] Yes, NSIS protocol must have provisions to *accept* > session's QoS data (transferred by CT) from new AR during QoS > signalling. Still, IMHO target selection and CT aspects as > such should be out of scope of NSIS. Yes, and if NSIS list members have input for QoS issues into SeaMoby, that would be good. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Apr 5 03:29:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00062 for ; Fri, 5 Apr 2002 03:29:08 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA15593 for nsis-archive@odin.ietf.org; Fri, 5 Apr 2002 03:29:12 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA15457; Fri, 5 Apr 2002 03:22:47 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA15421 for ; Fri, 5 Apr 2002 03:22:43 -0500 (EST) Received: from mail.zrz.tu-berlin.de (mail.zrz.TU-Berlin.DE [130.149.4.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00020 for ; Fri, 5 Apr 2002 03:22:39 -0500 (EST) Received: from ftsu07.ee.tu-berlin.de ([130.149.49.87] helo=ftmail.ee.tu-berlin.de) by mail.zrz.tu-berlin.de with esmtp (exim-3.36) id 16tOz6-0006Jv-00; Fri, 05 Apr 2002 10:22:12 +0200 Received: from ee.tu-berlin.de (fu@sinope.ee.TU-Berlin.DE [130.149.49.127]) by ftmail.ee.tu-berlin.de (8.11.3/8.11.3) with ESMTP id g358MB900770; Fri, 5 Apr 2002 10:22:11 +0200 Message-ID: <3CAD5EB3.8249D6F2@ee.tu-berlin.de> Date: Fri, 05 Apr 2002 10:22:11 +0200 From: Xiaoming Fu Reply-To: fu@ee.tu-berlin.de Organization: Telecommunication Networks Group, TU-Berlin X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.9-686 i686) X-Accept-Language: en-US, de, zh-CN MIME-Version: 1.0 To: Hemant.Chaskar@nokia.com CC: nsis@ietf.org Subject: Re: [NSIS] Establishing QoS after handoff. References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit Hi Hemant, John, Yes, I agree that target selection and CT aspects as such should be out of scope of NSIS, instead, task of SEAMOBY. However, following req-draft "exclusions" section 4.3.2: 4.3.2. Specific mechanisms (APIs and so on) for interaction between transport/applications and the network layer are not considered, except to clarify the requirements on the negotiation capabilities and information semantics that would be needed of the signaling protocol. The same applies to application adaptation mechanisms. and section 5.10.3 - Combination with Mobility management: Combining mobility and QoS signaling should be supported for economic signaling behavior (e.g., negotiation with the new access network: Mobile IP message to acquire new care-of address and query for QoS information could be combined, in order to preserve bandwidth and reduce latency). I think NSIS should clarify the interaction of negotiation (via SEAMOBY or other mechanisms) and QoS signaling though. If we simply exclude other possibilities and only allow "QoS signaling after handoff", we may get a QoS losing much beauty in mobility scenarios. Cheers, Xiaoming Hemant.Chaskar@nokia.com wrote: > > Hi John: > > Some comments below: > > -----Original Message----- > From: Loughney John (NRC/Helsinki) > Sent: Thursday, April 04, 2002 11:28 PM > To: Chaskar Hemant (NRC/Boston); nsis@ietf.org > Subject: RE: [NSIS] Establishing QoS after handoff. > > Hi all, > > Just to follow on to Hemant's comment: > > > There is currently a debate going on in Seamoby as to whether > > this QoS negotiation be covered by NSIS or Seamoby (CAR > > discovery protocol). > > > > IMHO it should be covered by CAR discovery and not NSIS. CAR > > discovery is supposed to identify candidate access routers > > for handoff and QoS is an important property for candidacy. > > CAR discovery may be used to select handoff targets with > correct QoS support / capabilities. Context Transfer (CT) > can be used with the handoff procedure to ensure proper > QoS state gets transfered to the new access router. > > [HC] I agree with this. > > If there is anyone interested in this work, please let me > know. The SeaMoby chairs asked me to see if NSIS can provide > them any information about QoS needs. > > [HC] Yes, NSIS protocol must have provisions to *accept* session's QoS data (transferred by CT) from new AR during QoS signalling. Still, IMHO target selection and CT aspects as such should be out of scope of NSIS. > > thanks, > John > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis  _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Apr 5 04:10:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00429 for ; Fri, 5 Apr 2002 04:10:06 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA17773 for nsis-archive@odin.ietf.org; Fri, 5 Apr 2002 04:10:09 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA16891; Fri, 5 Apr 2002 03:56:10 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA16810 for ; Fri, 5 Apr 2002 03:56:00 -0500 (EST) Received: from tms002bb.han.telia.se (tms002bb.han.telia.se [131.115.230.133]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00308 for ; Fri, 5 Apr 2002 03:55:55 -0500 (EST) From: Anders.P.Bergsten@telia.se Received: from TMS041MB.tcad.telia.se ([131.115.230.167]) by tms002bb.han.telia.se with Microsoft SMTPSVC(5.0.2195.2966); Fri, 5 Apr 2002 10:56:02 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Fri, 5 Apr 2002 10:56:02 +0200 Message-ID: <1BF8A5964E4EFA41A094B835FCA712912CCC49@TMS041MB.tcad.telia.se> Thread-Topic: Looking back at RFC 1633 Thread-Index: AcHcf5n2VcSeYChUQJC0/Gv9e4ieUg== To: X-OriginalArrivalTime: 05 Apr 2002 08:56:02.0282 (UTC) FILETIME=[B66FC4A0:01C1DC7F] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id DAA16812 Subject: [NSIS] Looking back at RFC 1633 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Dear all, I just reread RFC 1633. It was very interesting reading and for those on the nsis-list that haven't read it during the last years I suggest you do. It's very interesting to read remarks like "there is an inescabable requirement for routers to be able to reserve resources... This in turn requires flow-specific state in the routers" and "We take the view that there should be a single service model for the Internet". One can ask oneself, has anyone of these statements truly changed? It's even more interesting to think of in conjunction with (pure) diffserv where neither of these are true. To my main point though, there are 6 points I could find that ought to be interesting to discuss in regards to NSIS. These are either listed as further work, or in one instance I found the text to be vague. [Please, if you choose to respond to this email, alter the header so it is clear which one of the six points you are addressing] 1) Usage Feedback. "Another important issue in the service is the model for usage feedback, also known as accounting...", "this is a highly contentious issue, and we are not prepared to say more about this at this time". Have we collectively learned more about what "accounting"-models to support today so we can determine what the requirements truly are? 2) Reservation model "The 'reservation model' describes how an application negotiates for a QoS level.", "Further work is needed to define the amount of generality, with a corresponding level of complexity, that is required in the reservation model." Once again, have we learned more on this issue, or are we still at a point where we do not know the answer? I see people asking for very complex models and others (such as myself) that states that a yes/no reply is enough. 3) Flow Id (under section 4.1.3) "One approach to reducing the overhead of classification would be to provide a 'flow-id' field in the Internet-layer packet header... There are a number of variations of this concept, and engineering is required to choose the best design." Have we learned what is the best design? Or at least a reasonable good design so we can get it deployed? Another related question, do we need a definition of "flows" in NSIS? 4) Receiver initiation "... For simplicity and economy, a setup protocol should support only one direction of initiation, and, and receiver initiation appears to us to be the clear winner." I know there were some discussions on this topic at the IETF, but I find it good to re-iterate this again. Is receiver initiation still the clear winner? [for those who jump up a scream an immediate no, please pay attention to multicast... :-)] And, does the accounting-model have any impact on the reservation initiation direction? 5) Routing and reservation "Some have suggested that reservation setup necessarily requires route set up, i.e., the imposition of a virtual-circuit internet layer. However, our goal is to simply extend the Internet architecture, not replace it.". I see (once again) some folks at the NSIS list advocating that a route set up or VC-like mechanisms is necessary. With our current knowledge, is there substansial reasons to change the conclusion of Braden et al? (in later chapters) "It may eventually be possible to fold together the routing and reservation setup problems, but we do not yet understand enough to do that." Do we understand this issue better today? (this is perhaps somebody elses problem... irtf-rrg?). 6) Mobility "The last routing-related issue is provided by mobile hosts. Our conjecture is that mobility is not essentially different from other route changes, so that the mechanism suggested ... will suffice. More study and experimentation is needed to prove or disprove this conjecture." Have somebody been able to prove or disprove this conjecture? best regards, Anders ps, one issue I deliberately left out was the most obvious: "We conclude that there is an inescapable requirement for routers to be able to reserve resources, in order to provide special QoS for specific user packet streams, or "flows". This in turn requires flow-specific state in the routers,", with Frank Kelly's and others work - is this true today, or can we do something much simpler? Or is reservations simply a dead end... psps I know we have touched on some of these issues, but I do not see them as resolved. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Apr 5 05:59:31 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01548 for ; Fri, 5 Apr 2002 05:59:27 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA22637 for nsis-archive@odin.ietf.org; Fri, 5 Apr 2002 05:59:31 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA22520; Fri, 5 Apr 2002 05:54:36 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA22488 for ; Fri, 5 Apr 2002 05:54:33 -0500 (EST) Received: from yamato.ccrle.nec.de (yamato.ccrle.nec.de [195.37.70.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01502 for ; Fri, 5 Apr 2002 05:54:28 -0500 (EST) Received: from citadel.mobility.ccrle.nec.de ([192.168.156.1]) by yamato.ccrle.nec.de (8.11.6/8.10.1) with ESMTP id g35AtKL26152; Fri, 5 Apr 2002 12:55:20 +0200 (CEST) Received: from [192.168.102.79] (madrid.heidelberg.ccrle.nec.de [192.168.102.79]) by citadel.mobility.ccrle.nec.de (Postfix on SuSE eMail Server 2.0) with ESMTP id 3F9B1C051; Fri, 5 Apr 2002 12:53:32 +0200 (CEST) Date: Fri, 05 Apr 2002 13:07:51 +0200 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de To: Gary Kenward , "Geib, Ruediger" , svenvandenbosch@hotmail.com Cc: nsis@ietf.org Subject: RE: pre-emption (was RE: [NSIS] proposals related to NSIS WG draf t) Message-ID: <11401834.1018012071@[192.168.102.79]> In-Reply-To: <9FBD322B7824D511B36900508BF93C9C01AA49BE@zcard031.ca.nortel.com> References: <9FBD322B7824D511B36900508BF93C9C01AA49BE@zcard031.ca.nortel.com > X-Mailer: Mulberry/2.1.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id FAA22489 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit We are not talking about priority of data traffic overothers, but on the case of the capacity already completly give away and a new service request arriving. One can then specify, whether it is possible to preempt guaranteed reservations. I would like see whether this is worth a reqirement. Marcus --On Thursday, April 04, 2002 12:37 PM -0500 Gary Kenward wrote: > > I guess my main issue is that this "requirement" seems to embed > definitions of flow treatment in the definition of the signalling > protocol. This, to me, is simply the wrong thing to do, unless there > is not clear reason why the two cannot be kept separate. I haven't > heard this reason. > > BTW: the priority of a flow IS coupled to it's QoS requirements. > As a counter example, what does an low priority EF flow mean? > Could you support EF PHB for a flow if it had a "lower priority" (where > lower priority implies a higher liklihood of pre-emption of service) > then an AF or BE flow within a router? The answer is, very probably not. > > Let's not debate QoS definitions in NSIS. I think John has stated that > QoS definition is out of scope for NSIS, and declaring a particular flow > treatment such as priority as not being QoS doesn't help. > > Gary > >> -----Original Message----- >> From: Marcus Brunner [mailto:brunner@ccrle.nec.de] >> Sent: April 4, 2002 06:40 >> To: Geib, Ruediger; svenvandenbosch@hotmail.com >> Cc: nsis@ietf.org >> Subject: pre-emption (was RE: [NSIS] proposals related to >> NSIS WG draft) >> >> >> As Ruediger I would like to hear some other opinions as well. >> I think the >> whole fault handling is an open issue anyway and preempting >> flows might >> play a roll in fault handling as well. >> >> Marcus >> >> --On Tuesday, April 02, 2002 4:27 PM +0200 "Geib, Ruediger" >> wrote: >> >> > Hi Sven, >> > >> > the comment is a bit late, but I've been offline for a while. >> > Nevertheless: >> > >> >> * New requirements >> >> - in section MUST support priority >> >> The priority of a flow is essentially decoupled from >> >> its QoS requirements. Therefore the protocol MUST >> >> support priority. As a consequence, it MUST support >> >> preemption of traffic flows in case of congestion or >> >> failure. A preemption action MAY trigger an attempt >> >> to resetup the request by means of another instance >> >> of an NSIS signaling protocol. >> > >> > Could you provide some clearer argumentation why >> > preemption is a requirement? I'd classify preemption >> > as a "nice to have" feature, no more than a "MAY" >> > requirement. I'd especially insist on preemption being >> > completely decoupled from QoS and any other service >> > related signalling. >> > I.e. if it is not supported by an opperator, no >> > parameters or messages related to preemption are >> > to be transported. >> > >> > I'd like to ask other representatives of operators for >> > their view. >> > >> > Regards, Rüdiger >> > >> > _______________________________________________ >> > nsis mailing list >> > nsis@ietf.org >> > https://www1.ietf.org/mailman/listinfo/nsis >> >> >> >> -------------------------------------- >> Dr. Marcus Brunner >> Network Laboratories >> NEC Europe Ltd. >> >> E-Mail: brunner@ccrle.nec.de >> WWW: http://www.ccrle.nec.de/ >> personal home page: http://www.brubers.org/marcus >> >> >> >> _______________________________________________ >> nsis mailing list >> nsis@ietf.org >> https://www1.ietf.org/mailman/listinfo/nsis -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ personal home page: http://www.brubers.org/marcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Apr 5 06:04:21 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01622 for ; Fri, 5 Apr 2002 06:04:21 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA23270 for nsis-archive@odin.ietf.org; Fri, 5 Apr 2002 06:04:25 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA22626; Fri, 5 Apr 2002 05:59:18 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA22593 for ; Fri, 5 Apr 2002 05:59:14 -0500 (EST) Received: from yamato.ccrle.nec.de (yamato.ccrle.nec.de [195.37.70.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01541 for ; Fri, 5 Apr 2002 05:59:08 -0500 (EST) Received: from citadel.mobility.ccrle.nec.de ([192.168.156.1]) by yamato.ccrle.nec.de (8.11.6/8.10.1) with ESMTP id g35B04L26199; Fri, 5 Apr 2002 13:00:04 +0200 (CEST) Received: from [192.168.102.79] (madrid.heidelberg.ccrle.nec.de [192.168.102.79]) by citadel.mobility.ccrle.nec.de (Postfix on SuSE eMail Server 2.0) with ESMTP id D6FA1C051; Fri, 5 Apr 2002 12:58:23 +0200 (CEST) Date: Fri, 05 Apr 2002 13:12:43 +0200 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de To: "Shahrier, Sharif M." Cc: nsis@ietf.org Subject: RE: [NSIS] On the definition of QoS flow and aggregate flow. Message-ID: <11693444.1018012363@[192.168.102.79]> In-Reply-To: References: X-Mailer: Mulberry/2.1.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit Actually, we do not want to go down the path of defining nore standardizing QoS service classes or something the like. I think the definition of QSC might vanish, or at least not further defined nor any requirements are listed concerning the QSC. Actually, we most likly remove some requirements, which seam to be very service-specific. Marcus --On Thursday, April 04, 2002 3:21 PM -0500 "Shahrier, Sharif M." wrote: > Marcus, > > The question was how to derive the QSCs, and I suggested that the QSCs can > be mappable from a set of performance metrics that capture the constraints > on the QoS. > > My understanding from your message is that NSIS is not required to come up > with a standardized performance metrics? > > However, the notion of QSCs are in the draft, which I support, and hoping > to send text shortly to the list on its classification. > > Sharif. > > -----Original Message----- > From: Marcus Brunner [mailto:brunner@ccrle.nec.de] > Sent: Thursday, April 04, 2002 8:22 AM > To: Shahrier, Sharif M. > Cc: nsis@ietf.org > Subject: Re: [NSIS] On the definition of QoS flow and aggregate flow. > > Sharif, > > I got the feeling in MPLS WG meeting that defining QoS parameters (or > more general service descripions is currently out of scope of the NSIS > work. > > We even have a number of requirements in the -00 draft that are service > specific and will be removed. > > Marcus > > > --On Wednesday, April 03, 2002 3:27 PM -0500 "Shahrier, Sharif M." > wrote: > >> In the NSIS requirement draft, I have some points for discussion on the >> definition of a "flow" from the presective of NSIS, and also on the >> definition of "aggregate flow". >> >> I feel these need to be defined more fully in terms of QoS. >> >> It is defined in the requirements draft, that: >> >> A flow is a traffic stream between two endpoints for which "a specific >> level of QoS is provided". >> >> My question is how to characterize such a flow in terms of quantitative >> QoS parameters. >> >> A set of QoS parameters can be standardized for a flow. These parameters >> could be: >> >> Maximum delay >> Minimum throughput >> Maximum response time (assuming buffering) >> Maximum jitter >> ....... >> >> These parameters should then be mapped to a specific "priority value", >> i.e. a single parameter. >> >> The parameter can relate directly to ABR, CBR, UBR, ......... types of >> flow. >> >> A 6-tuple (src. addr, dest. addr., src. port nbr., dest. port nbr, >> protoID, Priority) should characterize a "flow" as far as the >> requirements for NSIS working group. >> >> Having a single priority value would make it much easier to quantify QoS >> to define a flow, as opposed to a whole set of parameters like delay, >> throughput, jitter ............ >> >> A flow aggregate can be defined as a set of flows, where each flow has >> the same QoS priority. >> >> Thus, a coarse grain, single QoS priority for "flow" characterization can >> help to readily gather flows with the same priority value into a set to >> form an aggregate flow set. >> >> Comments and feedback please......... >> >> Sharif. >> >> >> _______________________________________________ >> nsis mailing list >> nsis@ietf.org >> https://www1.ietf.org/mailman/listinfo/nsis > > > > -------------------------------------- > Dr. Marcus Brunner > Network Laboratories > NEC Europe Ltd. > > E-Mail: brunner@ccrle.nec.de > WWW: http://www.ccrle.nec.de/ > personal home page: http://www.brubers.org/marcus > -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ personal home page: http://www.brubers.org/marcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Apr 5 07:00:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02099 for ; Fri, 5 Apr 2002 07:00:16 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA25381 for nsis-archive@odin.ietf.org; Fri, 5 Apr 2002 07:00:19 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA25181; Fri, 5 Apr 2002 06:55:33 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA25153 for ; Fri, 5 Apr 2002 06:55:31 -0500 (EST) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02059 for ; Fri, 5 Apr 2002 06:55:27 -0500 (EST) From: john.loughney@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g35Bti517348 for ; Fri, 5 Apr 2002 14:55:45 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 5 Apr 2002 14:55:28 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Fri, 5 Apr 2002 14:55:27 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] Establishing QoS after handoff. Date: Fri, 5 Apr 2002 14:55:26 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64DE4@esebe004.NOE.Nokia.com> Thread-Topic: [NSIS] Establishing QoS after handoff. Thread-Index: AcHceyL79aMeT70CR/6wuq/t37HmXQAHXJAA To: , Cc: X-OriginalArrivalTime: 05 Apr 2002 11:55:27.0737 (UTC) FILETIME=[C725D690:01C1DC98] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id GAA25154 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Xiaoming, > Yes, I agree that target selection and CT aspects as such > should be out of scope of NSIS, instead, task of SEAMOBY. > > However, following req-draft "exclusions" section 4.3.2: > 4.3.2. Specific mechanisms (APIs and so on) for interaction between > transport/applications and the network layer are not considered, > except to clarify the requirements on the negotiation capabilities > and information semantics that would be needed of the signaling > protocol. The same applies to application adaptation mechanisms. > > and section 5.10.3 - Combination with Mobility management: > Combining mobility and QoS signaling should be supported for > economic signaling behavior (e.g., negotiation with the new access > network: Mobile IP message to acquire new care-of address and query > for QoS information could be combined, in order to preserve > bandwidth and reduce latency). > > I think NSIS should clarify the interaction of negotiation > (via SEAMOBY or > other mechanisms) and QoS signaling though. If we simply exclude other > possibilities and only allow "QoS signaling after handoff", > we may get a QoS losing much beauty in mobility scenarios. I think that interested parties should write up possibilities for these interactions, so that they can be discussed.d I don't think we can put anything into the requirements for this, but perhaps in the framework document. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Apr 5 07:06:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02367 for ; Fri, 5 Apr 2002 07:06:36 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA26078 for nsis-archive@odin.ietf.org; Fri, 5 Apr 2002 07:06:39 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA25563; Fri, 5 Apr 2002 07:00:50 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA25532 for ; Fri, 5 Apr 2002 07:00:47 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02199; Fri, 5 Apr 2002 07:00:43 -0500 (EST) Message-Id: <200204051200.HAA02199@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: nsis@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 05 Apr 2002 07:00:42 -0500 Subject: [NSIS] I-D ACTION:draft-venkata-ospf-te-only-option-00.txt Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Next Steps in Signaling Working Group of the IETF. Title : OSPF TE Only Option Author(s) : V. Naidu Filename : draft-venkata-ospf-te-only-option-00.txt Pages : 4 Date : 04-Apr-02 OSPF is a link state routing protocol used for IP-network topology discovery using different types of Link State Advertisements. The resulting Link State Database (LSDB) is used to compute IP address forwarding table based on shortest-path criteria. OSPF has been extended to support Traffic Engineering, QoS in packet and non-packet networks. These has been a serious concern regarding scalability and convergence of information in large networks. This memo documents an optional OSPF capability to support TE only functionality. This OSPF TE Only option is to support existing and future Traffic Engineering extensions for packet and/or non-packet networks with out exchanging any hop-by-hop routing information. This is accomplished by exchanging T-bit option in OSPF Hello packets. This gives flexibility of supporting larger TE areas, increased scalability and improved convergence. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-venkata-ospf-te-only-option-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-venkata-ospf-te-only-option-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-venkata-ospf-te-only-option-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020404153333.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-venkata-ospf-te-only-option-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-venkata-ospf-te-only-option-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020404153333.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Apr 5 09:41:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06000 for ; Fri, 5 Apr 2002 09:41:27 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA03773 for nsis-archive@odin.ietf.org; Fri, 5 Apr 2002 09:41:32 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA03465; Fri, 5 Apr 2002 09:34:58 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA03434 for ; Fri, 5 Apr 2002 09:34:54 -0500 (EST) Received: from howler.tri.sbc.com (howler.tri.sbc.com [205.173.58.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05891 for ; Fri, 5 Apr 2002 09:34:45 -0500 (EST) Received: from sbctri.tri.sbc.com (sbctri [144.60.1.10]) by howler.tri.sbc.com (8.11.6+Sun/8.11.0) with ESMTP id g35EbYN10128; Fri, 5 Apr 2002 08:37:34 -0600 (CST) Received: from TRIMAIL2.ad.tri.sbc.com (localhost [127.0.0.1]) by sbctri.tri.sbc.com (8.11.6+Sun/8.9.3) with ESMTP id g35EY4M27574; Fri, 5 Apr 2002 08:34:05 -0600 (CST) Received: by TRIMAIL2.ad.tri.sbc.com with Internet Mail Service (5.5.2653.19) id <2HFW56D8>; Fri, 5 Apr 2002 08:34:47 -0600 Message-ID: <905A1C4ABF353F4C8CC16FA9F53DD0D6322563@TRIMAIL2.ad.tri.sbc.com> From: "Chen, Weijing" To: "'Anders.P.Bergsten@telia.se'" , nsis@ietf.org Subject: RE: [NSIS] Looking back at RFC 1633 Date: Fri, 5 Apr 2002 08:34:47 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Well said. We are so quick to discard previous work since it is not our invention, and so eager to re-invent the wheel since it will have our name on it. A sadden state of current technology industries, we may know more about technology, but we lost fundamental engineering and scientific discipline. -- Weijing Chen SBC Technology Resources 9505 Arboretum Blvd. Austin, TX 78759 512 372 5710 wchen@tri.sbc.com -----Original Message----- From: Anders.P.Bergsten@telia.se [mailto:Anders.P.Bergsten@telia.se] Sent: Friday, April 05, 2002 2:56 AM To: nsis@ietf.org Subject: [NSIS] Looking back at RFC 1633 Dear all, I just reread RFC 1633. It was very interesting reading and for those on the nsis-list that haven't read it during the last years I suggest you do. It's very interesting to read remarks like "there is an inescabable requirement for routers to be able to reserve resources... This in turn requires flow-specific state in the routers" and "We take the view that there should be a single service model for the Internet". One can ask oneself, has anyone of these statements truly changed? It's even more interesting to think of in conjunction with (pure) diffserv where neither of these are true. To my main point though, there are 6 points I could find that ought to be interesting to discuss in regards to NSIS. These are either listed as further work, or in one instance I found the text to be vague. [Please, if you choose to respond to this email, alter the header so it is clear which one of the six points you are addressing] 1) Usage Feedback. "Another important issue in the service is the model for usage feedback, also known as accounting...", "this is a highly contentious issue, and we are not prepared to say more about this at this time". Have we collectively learned more about what "accounting"-models to support today so we can determine what the requirements truly are? 2) Reservation model "The 'reservation model' describes how an application negotiates for a QoS level.", "Further work is needed to define the amount of generality, with a corresponding level of complexity, that is required in the reservation model." Once again, have we learned more on this issue, or are we still at a point where we do not know the answer? I see people asking for very complex models and others (such as myself) that states that a yes/no reply is enough. 3) Flow Id (under section 4.1.3) "One approach to reducing the overhead of classification would be to provide a 'flow-id' field in the Internet-layer packet header... There are a number of variations of this concept, and engineering is required to choose the best design." Have we learned what is the best design? Or at least a reasonable good design so we can get it deployed? Another related question, do we need a definition of "flows" in NSIS? 4) Receiver initiation "... For simplicity and economy, a setup protocol should support only one direction of initiation, and, and receiver initiation appears to us to be the clear winner." I know there were some discussions on this topic at the IETF, but I find it good to re-iterate this again. Is receiver initiation still the clear winner? [for those who jump up a scream an immediate no, please pay attention to multicast... :-)] And, does the accounting-model have any impact on the reservation initiation direction? 5) Routing and reservation "Some have suggested that reservation setup necessarily requires route set up, i.e., the imposition of a virtual-circuit internet layer. However, our goal is to simply extend the Internet architecture, not replace it.". I see (once again) some folks at the NSIS list advocating that a route set up or VC-like mechanisms is necessary. With our current knowledge, is there substansial reasons to change the conclusion of Braden et al? (in later chapters) "It may eventually be possible to fold together the routing and reservation setup problems, but we do not yet understand enough to do that." Do we understand this issue better today? (this is perhaps somebody elses problem... irtf-rrg?). 6) Mobility "The last routing-related issue is provided by mobile hosts. Our conjecture is that mobility is not essentially different from other route changes, so that the mechanism suggested ... will suffice. More study and experimentation is needed to prove or disprove this conjecture." Have somebody been able to prove or disprove this conjecture? best regards, Anders ps, one issue I deliberately left out was the most obvious: "We conclude that there is an inescapable requirement for routers to be able to reserve resources, in order to provide special QoS for specific user packet streams, or "flows". This in turn requires flow-specific state in the routers,", with Frank Kelly's and others work - is this true today, or can we do something much simpler? Or is reservations simply a dead end... psps I know we have touched on some of these issues, but I do not see them as resolved. _______________________________________________ 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 daemon@optimus.ietf.org Fri Apr 5 10:12:10 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06897 for ; Fri, 5 Apr 2002 10:11:56 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA05600 for nsis-archive@odin.ietf.org; Fri, 5 Apr 2002 10:12:01 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA05468; Fri, 5 Apr 2002 10:09:50 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA05390 for ; Fri, 5 Apr 2002 10:09:44 -0500 (EST) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06828 for ; Fri, 5 Apr 2002 10:09:38 -0500 (EST) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g35F7Zw18552; Fri, 5 Apr 2002 10:07:36 -0500 (EST) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 5 Apr 2002 10:07:35 -0500 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA49C3@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'brunner@ccrle.nec.de'" , "Geib, Ruediger" , svenvandenbosch@hotmail.com Cc: nsis@ietf.org Subject: RE: pre-emption (was RE: [NSIS] proposals related to NSIS WG draf t) Date: Fri, 5 Apr 2002 10:07:28 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DCB3.8B09D09C" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1DCB3.8B09D09C Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Interesting. Why would this not be a policy decision? gary > -----Original Message----- > From: Marcus Brunner [mailto:brunner@ccrle.nec.de] > Sent: April 5, 2002 06:08 > To: Kenward, Gary [WDLN2:AN10:EXCH]; Geib, Ruediger; > svenvandenbosch@hotmail.com > Cc: nsis@ietf.org > Subject: RE: pre-emption (was RE: [NSIS] proposals related to NSIS WG > draf t) >=20 >=20 > We are not talking about priority of data traffic overothers,=20 > but on the=20 > case of the capacity already completly give away and a new=20 > service request=20 > arriving. One can then specify, whether it is possible to preempt=20 > guaranteed reservations. >=20 > I would like see whether this is worth a reqirement. >=20 > Marcus >=20 > --On Thursday, April 04, 2002 12:37 PM -0500 Gary Kenward=20 > wrote: >=20 > > > > I guess my main issue is that this "requirement" seems to embed > > definitions of flow treatment in the definition of the signalling > > protocol. This, to me, is simply the wrong thing to do, unless = there > > is not clear reason why the two cannot be kept separate. I haven't > > heard this reason. > > > > BTW: the priority of a flow IS coupled to it's QoS requirements. > > As a counter example, what does an low priority EF flow mean? > > Could you support EF PHB for a flow if it had a "lower=20 > priority" (where > > lower priority implies a higher liklihood of pre-emption of = service) > > then an AF or BE flow within a router? The answer is, very=20 > probably not. > > > > Let's not debate QoS definitions in NSIS. I think John has=20 > stated that > > QoS definition is out of scope for NSIS, and declaring a=20 > particular flow > > treatment such as priority as not being QoS doesn't help. > > > > Gary > > > >> -----Original Message----- > >> From: Marcus Brunner [mailto:brunner@ccrle.nec.de] > >> Sent: April 4, 2002 06:40 > >> To: Geib, Ruediger; svenvandenbosch@hotmail.com > >> Cc: nsis@ietf.org > >> Subject: pre-emption (was RE: [NSIS] proposals related to > >> NSIS WG draft) > >> > >> > >> As Ruediger I would like to hear some other opinions as well. > >> I think the > >> whole fault handling is an open issue anyway and preempting > >> flows might > >> play a roll in fault handling as well. > >> > >> Marcus > >> > >> --On Tuesday, April 02, 2002 4:27 PM +0200 "Geib, Ruediger" > >> wrote: > >> > >> > Hi Sven, > >> > > >> > the comment is a bit late, but I've been offline for a while. > >> > Nevertheless: > >> > > >> >> * New requirements > >> >> - in section MUST support priority > >> >> The priority of a flow is essentially decoupled from > >> >> its QoS requirements. Therefore the protocol MUST > >> >> support priority. As a consequence, it MUST support > >> >> preemption of traffic flows in case of congestion or > >> >> failure. A preemption action MAY trigger an attempt > >> >> to resetup the request by means of another instance > >> >> of an NSIS signaling protocol. > >> > > >> > Could you provide some clearer argumentation why > >> > preemption is a requirement? I'd classify preemption > >> > as a "nice to have" feature, no more than a "MAY" > >> > requirement. I'd especially insist on preemption being > >> > completely decoupled from QoS and any other service > >> > related signalling. > >> > I.e. if it is not supported by an opperator, no > >> > parameters or messages related to preemption are > >> > to be transported. > >> > > >> > I'd like to ask other representatives of operators for > >> > their view. > >> > > >> > Regards, R=FCdiger > >> > > >> > _______________________________________________ > >> > nsis mailing list > >> > nsis@ietf.org > >> > https://www1.ietf.org/mailman/listinfo/nsis > >> > >> > >> > >> -------------------------------------- > >> Dr. Marcus Brunner > >> Network Laboratories > >> NEC Europe Ltd. > >> > >> E-Mail: brunner@ccrle.nec.de > >> WWW: http://www.ccrle.nec.de/ > >> personal home page: http://www.brubers.org/marcus > >> > >> > >> > >> _______________________________________________ > >> nsis mailing list > >> nsis@ietf.org > >> https://www1.ietf.org/mailman/listinfo/nsis >=20 >=20 >=20 > -------------------------------------- > Dr. Marcus Brunner > Network Laboratories > NEC Europe Ltd. >=20 > E-Mail: brunner@ccrle.nec.de > WWW: http://www.ccrle.nec.de/ > personal home page: http://www.brubers.org/marcus >=20 >=20 >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 ------_=_NextPart_001_01C1DCB3.8B09D09C Content-Type: text/html; charset="iso-8859-1" RE: pre-emption (was RE: [NSIS] proposals related to NSIS WG draf t)

Interesting. Why would this not be a policy decision?

gary

> -----Original Message-----
> From: Marcus Brunner [mailto:brunner@ccrle.nec.de]
> Sent: April 5, 2002 06:08
> To: Kenward, Gary [WDLN2:AN10:EXCH]; Geib, Ruediger;
> svenvandenbosch@hotmail.com
> Cc: nsis@ietf.org
> Subject: RE: pre-emption (was RE: [NSIS] proposals related to NSIS WG
> draf t)
>
>
> We are not talking about priority of data traffic overothers,
> but on the
> case of the capacity already completly give away and a new
> service request
> arriving. One can then specify, whether it is possible to preempt
> guaranteed reservations.
>
> I would like see whether this is worth a reqirement.
>
> Marcus
>
> --On Thursday, April 04, 2002 12:37 PM -0500 Gary Kenward
> <gkenward@nortelnetworks.com> wrote:
>
> >
> > I guess my main issue is that this "requirement" seems to embed
> > definitions of flow treatment in the definition of the signalling
> > protocol. This, to me, is simply the wrong thing to do, unless there
> > is not clear reason why the two cannot be kept separate. I haven't
> > heard this reason.
> >
> > BTW: the priority of a flow IS coupled to it's QoS requirements.
> > As a counter example, what does an low priority EF flow mean?
> > Could you support EF PHB for a flow if it had a "lower
> priority" (where
> > lower priority implies a higher liklihood of pre-emption of service)
> > then an AF or BE flow within a router? The answer is, very
> probably not.
> >
> > Let's not debate QoS definitions in NSIS. I think John has
> stated that
> > QoS definition is out of scope for NSIS, and declaring a
> particular flow
> > treatment such as priority as not being QoS doesn't help.
> >
> > Gary
> >
> >> -----Original Message-----
> >> From: Marcus Brunner [mailto:brunner@ccrle.nec.de]
> >> Sent: April 4, 2002 06:40
> >> To: Geib, Ruediger; svenvandenbosch@hotmail.com
> >> Cc: nsis@ietf.org
> >> Subject: pre-emption (was RE: [NSIS] proposals related to
> >> NSIS WG draft)
> >>
> >>
> >> As Ruediger I would like to hear some other opinions as well.
> >> I think the
> >> whole fault handling is an open issue anyway and preempting
> >> flows might
> >> play a roll in fault handling as well.
> >>
> >> Marcus
> >>
> >> --On Tuesday, April 02, 2002 4:27 PM +0200 "Geib, Ruediger"
> >> <Ruediger.Geib@t-systems.com> wrote:
> >>
> >> > Hi Sven,
> >> >
> >> > the comment is a bit late, but I've been offline for a while.
> >> > Nevertheless:
> >> >
> >> >> * New requirements
> >> >> - in section MUST support priority
> >> >>   The priority of a flow is essentially decoupled from
> >> >>   its QoS requirements. Therefore the protocol MUST
> >> >>   support priority. As a consequence, it MUST support
> >> >>   preemption of traffic flows in case of congestion or
> >> >>   failure. A preemption action MAY trigger an attempt
> >> >>   to resetup the request by means of another instance
> >> >>   of an NSIS signaling protocol.
> >> >
> >> > Could you provide some clearer argumentation why
> >> > preemption is a requirement? I'd classify preemption
> >> > as a "nice to have" feature, no more than a "MAY"
> >> > requirement. I'd especially insist on preemption being
> >> > completely decoupled from QoS and any other service
> >> > related signalling.
> >> > I.e. if it is not supported by an opperator, no
> >> > parameters or messages related to preemption are
> >> > to be transported.
> >> >
> >> > I'd like to ask other representatives of operators for
> >> > their view.
> >> >
> >> > Regards, Rüdiger
> >> >
> >> > _______________________________________________
> >> > nsis mailing list
> >> > nsis@ietf.org
> >> > https://www1.ietf.org/mailman/listinfo/nsis
> >>
> >>
> >>
> >> --------------------------------------
> >> Dr. Marcus Brunner
> >> Network Laboratories
> >> NEC Europe Ltd.
> >>
> >> E-Mail: brunner@ccrle.nec.de
> >> WWW:    http://www.ccrle.nec.de/
> >> personal home page: http://www.brubers.org/marcus
> >>
> >>
> >>
> >> _______________________________________________
> >> nsis mailing list
> >> nsis@ietf.org
> >> https://www1.ietf.org/mailman/listinfo/nsis
>
>
>
> --------------------------------------
> Dr. Marcus Brunner
> Network Laboratories
> NEC Europe Ltd.
>
> E-Mail: brunner@ccrle.nec.de
> WWW:    http://www.ccrle.nec.de/
> personal home page: http://www.brubers.org/marcus
>
>
>
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis
>

------_=_NextPart_001_01C1DCB3.8B09D09C-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Apr 5 10:40:23 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07738 for ; Fri, 5 Apr 2002 10:40:23 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA08479 for nsis-archive@odin.ietf.org; Fri, 5 Apr 2002 10:40:25 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA07967; Fri, 5 Apr 2002 10:34:37 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA07935 for ; Fri, 5 Apr 2002 10:34:34 -0500 (EST) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07604 for ; Fri, 5 Apr 2002 10:34:26 -0500 (EST) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g35FSIe20362; Fri, 5 Apr 2002 10:28:18 -0500 (EST) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 5 Apr 2002 10:28:17 -0500 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA49C4@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'sven.van_den_bosch@alcatel.be'" Cc: "'brunner@ccrle.nec.de'" , "Geib, Ruediger" , svenvandenbosch@hotmail.com, nsis@ietf.org Subject: RE: pre-emption (was RE: [NSIS] proposals related to NSIS WG draf t) Date: Fri, 5 Apr 2002 10:28:14 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DCB3.ACCA1AAC" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1DCB3.ACCA1AAC Content-Type: text/plain; charset="iso-8859-1" Sven: Yes, I misinterpreted the application of priority. My apologies. I do not agree that DS and priority are orthogonal, but the application of priority to admission of new flows is a different dimension on the problem. I say that they are not orthogonal, because it would seem to me that if you were going to make a decision on whether or not to pre-empt established traffic for new traffic, then you must consider QoS. Example: the nature of the decision to admit new BE flows should be completely different then the decision to admit new EF flows because of the tighter, more deterministic, constraints on resource allocation for EF versus BE. More important is the consideration that from a user perspective, QoS is ultimately part of the service contract, implicit or explicit, between the network and the user (or between two networks). Any pre-emption actions must fit within the agreed upon service model, and this is a policy decision, not a routing decision nor is it an admission control decision, in the strictest sense of admission control. The possibility that a users flows could be dropped for reasons outside the control of the user is part of the quality of the service offering. BTW: when I refer to "policy", I do not necessarily imply that a policy management system is required. While there are, perhaps, advantages to a PM approach, the policy decisions and enforcement could be performed in other fashions, e.g. through a local, access network dependent mechanism. And so, it is not clear to me why NSIS has to be worried about this admission "priority", per se. If relevant to the network, it should be encapsulated in the TLA, which should be encapsulated in the QoS description, whatever form that description takes. The net benefit here is by putting this priority where it belongs, in the QoS description, NSIS is not implying a preferred operational model for the access network, nor preferred functionality. And, still, the capability can still be supported. Again, making priority explicitly in NSIS is still defining QoS models. Regards, Gary > -----Original Message----- > From: sven.van_den_bosch@alcatel.be > [mailto:sven.van_den_bosch@alcatel.be] > Sent: April 5, 2002 02:11 > To: Kenward, Gary [WDLN2:AN10:EXCH] > Cc: 'brunner@ccrle.nec.de'; Geib, Ruediger; > svenvandenbosch@hotmail.com; > nsis@ietf.org > Subject: RE: pre-emption (was RE: [NSIS] proposals related to NSIS WG > draf t) > > > Gary, > > >BTW: the priority of a flow IS coupled to it's QoS requirements. > >As a counter example, what does an low priority EF flow mean? > >Could you support EF PHB for a flow if it had a "lower > priority" (where > >lower priority implies a higher liklihood of pre-emption of service) > >then an AF or BE flow within a router? The answer is, very > probably not. > > I absolutely disagree on this one. Priority is related to the > question how > badly you want a certain connection to be set up and how > badly you want to > keep it in place once it is there. QoS refers to the > characteristics for > the flow once it is set up. In the TE-WG we came to the same > conclusion > regarding DiffServ and priority. They are completely orthogonal. > > Sven. > > ------_=_NextPart_001_01C1DCB3.ACCA1AAC Content-Type: text/html; charset="iso-8859-1" RE: pre-emption (was RE: [NSIS] proposals related to NSIS WG draf t)

Sven:

  Yes, I misinterpreted the application of priority. My apologies.
I do not agree that DS and priority are orthogonal, but the application
of priority to admission of new flows is a different dimension on the problem.

  I say that they are not orthogonal, because it would seem to me that if
you were going to make a decision on whether or not to pre-empt established
traffic for new traffic, then you must consider QoS. Example: the nature of
the decision to admit new BE flows should be completely different then the
decision to admit new EF flows because of the tighter, more deterministic,
constraints on resource allocation for EF versus BE.

  More important is the consideration that from a user perspective, QoS is
ultimately part of the service contract, implicit or explicit, between the
network and the user (or between two networks). Any pre-emption actions must
fit within the agreed upon service model, and this is a policy decision,
not a routing decision nor is it an admission control decision, in the
strictest sense of admission control. The possibility that a users flows
could be dropped for reasons outside the control of the user is part of the
quality of the service offering.

  BTW: when I refer to "policy", I do not necessarily imply that a policy
management system is required. While there are, perhaps, advantages to a PM
approach, the policy decisions and enforcement could be performed in other fashions,
e.g. through a local, access network dependent mechanism.

  And so, it is not clear to me why NSIS has to be worried about this admission
"priority", per se. If relevant to the network, it should be encapsulated in
the TLA, which should be encapsulated in the QoS description, whatever form that
description takes.

  The net benefit here is by putting this priority where it belongs, in the
QoS description, NSIS is not implying a preferred operational model for the
access network, nor preferred functionality. And, still, the capability can
still be supported.

  Again, making priority explicitly in NSIS is still defining QoS models.

Regards,
Gary

> -----Original Message-----
> From: sven.van_den_bosch@alcatel.be
> [mailto:sven.van_den_bosch@alcatel.be]
> Sent: April 5, 2002 02:11
> To: Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: 'brunner@ccrle.nec.de'; Geib, Ruediger;
> svenvandenbosch@hotmail.com;
> nsis@ietf.org
> Subject: RE: pre-emption (was RE: [NSIS] proposals related to NSIS WG
> draf t)
>
>
> Gary,
>
> >BTW: the priority of a flow IS coupled to it's QoS requirements.
> >As a counter example, what does an low priority EF flow mean?
> >Could you support EF PHB for a flow if it had a "lower
> priority" (where
> >lower priority implies a higher liklihood of pre-emption of service)
> >then an AF or BE flow within a router? The answer is, very
> probably not.
>
> I absolutely disagree on this one. Priority is related to the
> question how
> badly you want a certain connection to be set up and how
> badly you want to
> keep it in place once it is there. QoS refers to the
> characteristics for
> the flow once it is set up. In the TE-WG we came to the same
> conclusion
> regarding DiffServ and priority. They are completely orthogonal.
>
> Sven.
>
>

------_=_NextPart_001_01C1DCB3.ACCA1AAC-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Apr 5 10:52:14 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08001 for ; Fri, 5 Apr 2002 10:52:14 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA09590 for nsis-archive@odin.ietf.org; Fri, 5 Apr 2002 10:52:19 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA08804; Fri, 5 Apr 2002 10:43:50 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA08769 for ; Fri, 5 Apr 2002 10:43:43 -0500 (EST) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07817 for ; Fri, 5 Apr 2002 10:43:36 -0500 (EST) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g35FdCw20513; Fri, 5 Apr 2002 10:39:12 -0500 (EST) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 5 Apr 2002 10:39:12 -0500 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA49C6@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'DJamel H. Sadok'" , "Shahrier, Sharif M." Cc: nsis@ietf.org, Carlos Alberto Kamienski Subject: RE: [NSIS] On the definition of QoS flow and aggregate flow. Date: Fri, 5 Apr 2002 10:39:08 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DCB7.14DEE0A2" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1DCB7.14DEE0A2 Content-Type: text/plain; charset="iso-8859-1" Ok, first observation: clearly I am not alone in my mis-interpretation of what this priority means. Second, I am confused as to why NSIS would be concerned with defining what amounts to a class of service identifier. I concur with Djamel on the need for an identifier, but only with respect to the type of identifies that have been discussed in so many other wgs: as one of the defined value fields in a VTD data chunk carried by the protocol. Some values of this identifier may require standardization through IANA - as well known services, but do these values have to be determined by NSIS? Perhaps I am missing an important issue here with the semantics of a QoS control protocol, but given the scope of the requirements, I see NSIS as being more of a container protocol then an SS7 or UNI protocol. This allows NSIS to be used in a variety of network implementations. Does anyone know of semantic/performance issues with this approach? Gary > -----Original Message----- > From: DJamel H. Sadok [mailto:jamel@cin.ufpe.br] > Sent: April 4, 2002 06:46 > To: Shahrier, Sharif M. > Cc: nsis@ietf.org; Carlos Alberto Kamienski > Subject: Re: [NSIS] On the definition of QoS flow and aggregate flow. > > > > > > Having a single priority value would make it much easier to > quantify QoS to > > define a flow, as opposed to a whole set of parameters like delay, > > throughput, jitter ............ > > > > I did not follow this thread and consequently I am not sure of what a > priority in this context is, but it seems to me > that it would mean some information that refers to a set of > QoS parameters > for a given flow. So, why not consider the use of well known > services (WKS) and defining well known service ids (WKS-IDs) > as some class > of a service specification with delay, bandwidth, etc.. > information and > use a flow-id or a WKS-ID to refer to it. Of course there is > the problem > of having these predefined for scalability. I am using the > term service > here to refer to a class of flows with some common QoS > characteristics. > The goal here is NOT to define services but to identify using these > WKS-IDs some classes and build some templates for them that > some domains > may aggree to use for end-to-end QoS. > > So for example in the DSCP field one may have this WKS-ID > that represents an > aggreagate flow class and which may locally be mapped > to any QoS domain specific technology (IntServ, DiffServ, > over provisionning, ...) > Their mapping depends on the local domain policies and its > QoS technology. > > Flows may be aggregated at the domain for example if we have two flows > that require delay values of 10ms and 5 ms, a domain may > aggregate both > specifications and offer resources for the aggregate as long > as the delay > is maintained bellow 5 ms. Of course considering this field, only a > limited number of classes may be defined, so if we need to maintain > information on individual flows and not simply on their > aggregates, for > example to deal with those that may breach access policies or apply > admission or other control, then another field may be used to contain > flow ids. > > Djamel > > > A flow aggregate can be defined as a set of flows, where > each flow has the > > same QoS priority. > > > > Thus, a coarse grain, single QoS priority for "flow" > characterization can > > help to readily gather flows with the same priority value > into a set to form > > an aggregate flow set. > > > > Comments and feedback please......... > > > > Sharif. > > > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > ------_=_NextPart_001_01C1DCB7.14DEE0A2 Content-Type: text/html; charset="iso-8859-1" RE: [NSIS] On the definition of QoS flow and aggregate flow.

Ok, first observation: clearly I am not alone in my mis-interpretation of
what this priority means.

Second, I am confused as to why NSIS would be concerned with defining what
amounts to a class of service identifier.

I concur with Djamel on the need for an identifier, but only with respect
to the type of identifies that have been discussed in so many other wgs:
as one of the defined value fields in a VTD data chunk carried by the protocol.
Some values of this identifier may require standardization through IANA -
as well known services, but do these values have to be determined by NSIS?

Perhaps I am missing an important issue here with the semantics of a QoS
control protocol, but given the scope of the requirements, I see NSIS as
being more of a container protocol then an SS7 or UNI protocol. This allows
NSIS to be used in a variety of network implementations.

Does anyone know of semantic/performance issues with this approach?

Gary


> -----Original Message-----
> From: DJamel H. Sadok [mailto:jamel@cin.ufpe.br]
> Sent: April 4, 2002 06:46
> To: Shahrier, Sharif M.
> Cc: nsis@ietf.org; Carlos Alberto Kamienski
> Subject: Re: [NSIS] On the definition of QoS flow and aggregate flow.
>
>
>
>
> > Having a single priority value would make it much easier to
> quantify QoS to
> > define a flow, as opposed to a whole set of parameters like delay,
> > throughput, jitter ............
> >
>
> I did not follow this thread and consequently I am not sure of what a
> priority in this context is, but it seems to me
> that it would mean some information that refers to a set of
> QoS parameters
> for a given flow. So, why not consider  the use of well known
> services (WKS) and defining well known service ids (WKS-IDs)
> as some class
> of a service specification with delay, bandwidth, etc..
> information and
> use a flow-id or a WKS-ID to refer to it. Of course there is
> the problem
> of having these predefined for scalability. I am using the
> term service
> here to refer to a class of flows with some common QoS
> characteristics.
> The goal here is NOT to define services but to identify using these
> WKS-IDs some classes and build some templates for them that
> some domains
> may aggree to use for end-to-end QoS.
>
> So for example in the DSCP field one may have this WKS-ID
> that represents an
> aggreagate flow class and which may locally be mapped
> to any QoS domain specific technology (IntServ, DiffServ,
> over provisionning, ...)
> Their mapping depends on the local domain policies and its
> QoS technology.
>
> Flows may be aggregated at the domain for example if we have two flows
> that require delay values of 10ms and 5 ms, a domain may
> aggregate both
> specifications and offer resources for the aggregate as long
> as the delay
> is maintained bellow 5 ms. Of course considering this field, only a
> limited number of classes may be defined, so if we need to maintain
> information on individual flows and not simply on their
> aggregates, for
> example to deal with those that may breach access policies or apply
> admission or other  control, then another field may be used to contain
> flow ids.
>
> Djamel
>
> > A flow aggregate can be defined as a set of flows, where
> each flow has the
> > same QoS priority.
> >
> > Thus, a coarse grain, single QoS priority for "flow"
> characterization can
> > help to readily gather flows with the same priority value
> into a set to form
> > an aggregate flow set.
> >
> > Comments and feedback please.........
> >
> > Sharif.
> >
> >
> > _______________________________________________
> > nsis mailing list
> > nsis@ietf.org
> > https://www1.ietf.org/mailman/listinfo/nsis
> >
>
>
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis
>

------_=_NextPart_001_01C1DCB7.14DEE0A2-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Apr 5 10:55:40 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08082 for ; Fri, 5 Apr 2002 10:55:40 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA09770 for nsis-archive@odin.ietf.org; Fri, 5 Apr 2002 10:55:45 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA09413; Fri, 5 Apr 2002 10:49:27 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA09379 for ; Fri, 5 Apr 2002 10:49:25 -0500 (EST) Received: from aifhs8.alcatel.fr (mail3.alcatel.fr [194.133.58.53]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07932 for ; Fri, 5 Apr 2002 10:49:18 -0500 (EST) From: Alban.Couturier@alcatel.fr Received: from frmail30.netfr.alcatel.fr (frmail30.netfr.alcatel.fr [155.132.182.163]) by aifhs8.alcatel.fr (ALCANET/SMTP2) with ESMTP id RAA26540; Fri, 5 Apr 2002 17:45:58 +0200 (MET DST) Received: from alcatel.fr ([139.54.208.245]) by frmail30.netfr.alcatel.fr (Lotus Domino Release 5.0.9a) with ESMTP id 2002040517455649:8269 ; Fri, 5 Apr 2002 17:45:56 +0200 Message-ID: <3CADC6CB.1CD86E37@alcatel.fr> Date: Fri, 05 Apr 2002 17:46:19 +0200 Organization: Alcatel X-Mailer: Mozilla 4.78 [fr] (Windows NT 5.0; U) X-Accept-Language: fr MIME-Version: 1.0 To: Gary Kenward Cc: "'brunner@ccrle.nec.de'" , "Geib, Ruediger" , svenvandenbosch@hotmail.com, nsis@ietf.org Subject: Re: pre-emption (was RE: [NSIS] proposals related to NSIS WG draft) References: <9FBD322B7824D511B36900508BF93C9C01AA49C3@zcard031.ca.nortel.com> X-MIMETrack: Itemize by SMTP Server on FRMAIL30/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 04/05/2002 17:45:56, Serialize by Router on FRMAIL30/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 04/05/2002 17:45:57, Serialize complete at 04/05/2002 17:45:57 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id KAA09380 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit > Gary Kenward a écrit : > > Interesting. Why would this not be a policy decision? I dont understand the trouble here. We are making signaling, which is per se the interface to an admission control function. Admission control's role is to reject (hopefully not too much) users who want to consume concurrently the same resources (such as an EF). The first feature we can add to a "rough" signaling, is priority. For example, when I want to call 911, I want the same QoS than a normal call, this is normal voice, but I prefer not to be rejected by the admission control. A way to implement priority is preemption. Which means to me to interrupt the EF marking of already accepted flows, and notifying this "normal" EF users they have no more the EF/voice quality. There are other ways. For instance, an admission control can refuse normal calls when some treshold is reached, and then only accept priority calls. So I would conclude that preemption is not a requirement for NSIS, but priority should be supported by nsis. > gary > > > -----Original Message----- > > From: Marcus Brunner [mailto:brunner@ccrle.nec.de] > > Sent: April 5, 2002 06:08 > > To: Kenward, Gary [WDLN2:AN10:EXCH]; Geib, Ruediger; > > svenvandenbosch@hotmail.com > > Cc: nsis@ietf.org > > Subject: RE: pre-emption (was RE: [NSIS] proposals related to NSIS > WG > > draf t) > > > > > > We are not talking about priority of data traffic overothers, > > but on the > > case of the capacity already completly give away and a new > > service request > > arriving. One can then specify, whether it is possible to preempt > > guaranteed reservations. > > > > I would like see whether this is worth a reqirement. > > > > Marcus > > > > --On Thursday, April 04, 2002 12:37 PM -0500 Gary Kenward > > wrote: > > > > > > > > I guess my main issue is that this "requirement" seems to embed > > > definitions of flow treatment in the definition of the signalling > > > protocol. This, to me, is simply the wrong thing to do, unless > there > > > is not clear reason why the two cannot be kept separate. I haven't > > > > heard this reason. > > > > > > BTW: the priority of a flow IS coupled to it's QoS requirements. > > > As a counter example, what does an low priority EF flow mean? > > > Could you support EF PHB for a flow if it had a "lower > > priority" (where > > > lower priority implies a higher liklihood of pre-emption of > service) > > > then an AF or BE flow within a router? The answer is, very > > probably not. > > > > > > Let's not debate QoS definitions in NSIS. I think John has > > stated that > > > QoS definition is out of scope for NSIS, and declaring a > > particular flow > > > treatment such as priority as not being QoS doesn't help. > > > > > > Gary > > > > > >> -----Original Message----- > > >> From: Marcus Brunner [mailto:brunner@ccrle.nec.de] > > >> Sent: April 4, 2002 06:40 > > >> To: Geib, Ruediger; svenvandenbosch@hotmail.com > > >> Cc: nsis@ietf.org > > >> Subject: pre-emption (was RE: [NSIS] proposals related to > > >> NSIS WG draft) > > >> > > >> > > >> As Ruediger I would like to hear some other opinions as well. > > >> I think the > > >> whole fault handling is an open issue anyway and preempting > > >> flows might > > >> play a roll in fault handling as well. > > >> > > >> Marcus > > >> > > >> --On Tuesday, April 02, 2002 4:27 PM +0200 "Geib, Ruediger" > > >> wrote: > > >> > > >> > Hi Sven, > > >> > > > >> > the comment is a bit late, but I've been offline for a while. > > >> > Nevertheless: > > >> > > > >> >> * New requirements > > >> >> - in section MUST support priority > > >> >> The priority of a flow is essentially decoupled from > > >> >> its QoS requirements. Therefore the protocol MUST > > >> >> support priority. As a consequence, it MUST support > > >> >> preemption of traffic flows in case of congestion or > > >> >> failure. A preemption action MAY trigger an attempt > > >> >> to resetup the request by means of another instance > > >> >> of an NSIS signaling protocol. > > >> > > > >> > Could you provide some clearer argumentation why > > >> > preemption is a requirement? I'd classify preemption > > >> > as a "nice to have" feature, no more than a "MAY" > > >> > requirement. I'd especially insist on preemption being > > >> > completely decoupled from QoS and any other service > > >> > related signalling. > > >> > I.e. if it is not supported by an opperator, no > > >> > parameters or messages related to preemption are > > >> > to be transported. > > >> > > > >> > I'd like to ask other representatives of operators for > > >> > their view. > > >> > > > >> > Regards, Rüdiger > > >> > > > >> > _______________________________________________ > > >> > nsis mailing list > > >> > nsis@ietf.org > > >> > https://www1.ietf.org/mailman/listinfo/nsis > > >> > > >> > > >> > > >> -------------------------------------- > > >> Dr. Marcus Brunner > > >> Network Laboratories > > >> NEC Europe Ltd. > > >> > > >> E-Mail: brunner@ccrle.nec.de > > >> WWW: http://www.ccrle.nec.de/ > > >> personal home page: http://www.brubers.org/marcus > > >> > > >> > > >> > > >> _______________________________________________ > > >> nsis mailing list > > >> nsis@ietf.org > > >> https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > -------------------------------------- > > Dr. Marcus Brunner > > Network Laboratories > > NEC Europe Ltd. > > > > E-Mail: brunner@ccrle.nec.de > > WWW: http://www.ccrle.nec.de/ > > personal home page: http://www.brubers.org/marcus > > > > > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > -- Alban Couturier --------------------------------------------------------------------- Alcatel Research and Innovation Ets de Marcoussis R&I/ULC Route de Nozay mailto:Alban.Couturier@alcatel.fr F-91461 Marcoussis CEDEX tel: +33 1 69 63 11 97 --------------------------------------------------------------------- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Apr 5 11:11:19 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08444 for ; Fri, 5 Apr 2002 11:11:18 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA10893 for nsis-archive@odin.ietf.org; Fri, 5 Apr 2002 11:11:24 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA10826; Fri, 5 Apr 2002 11:08:18 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA10792 for ; Fri, 5 Apr 2002 11:08:16 -0500 (EST) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08373 for ; Fri, 5 Apr 2002 11:08:09 -0500 (EST) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g35G7be23504; Fri, 5 Apr 2002 11:07:37 -0500 (EST) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 5 Apr 2002 11:07:36 -0500 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA49C8@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'john.loughney@nokia.com'" , Hemant.Chaskar@nokia.com, nsis@ietf.org Subject: RE: [NSIS] Establishing QoS after handoff. Date: Fri, 5 Apr 2002 11:07:34 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DCBB.DC2024F6" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1DCBB.DC2024F6 Content-Type: text/plain; charset="iso-8859-1" John: Sorry, I may be just thick between the ears, but did you mean "QoS needs" or "QoS signalling needs"???? Gary > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: April 4, 2002 23:28 > To: Hemant.Chaskar@nokia.com; nsis@ietf.org > Subject: RE: [NSIS] Establishing QoS after handoff. > > > Hi all, > > Just to follow on to Hemant's comment: > > > There is currently a debate going on in Seamoby as to whether > > this QoS negotiation be covered by NSIS or Seamoby (CAR > > discovery protocol). > > > > IMHO it should be covered by CAR discovery and not NSIS. CAR > > discovery is supposed to identify candidate access routers > > for handoff and QoS is an important property for candidacy. > > CAR discovery may be used to select handoff targets with > correct QoS support / capabilities. Context Transfer (CT) > can be used with the handoff procedure to ensure proper > QoS state gets transfered to the new access router. > > If there is anyone interested in this work, please let me > know. The SeaMoby chairs asked me to see if NSIS can provide > them any information about QoS needs. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > thanks, > John > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > ------_=_NextPart_001_01C1DCBB.DC2024F6 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [NSIS] Establishing QoS after handoff.

John:

  Sorry, I may be just thick between the ears, = but did you mean
"QoS needs" or "QoS signalling = needs"????

Gary

> -----Original Message-----
> From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]
> Sent: April 4, 2002 23:28
> To: Hemant.Chaskar@nokia.com; = nsis@ietf.org
> Subject: RE: [NSIS] Establishing QoS after = handoff.
>
>
> Hi all,
>
> Just to follow on to Hemant's comment:
>
> > There is currently a debate going on in = Seamoby as to whether
> > this QoS negotiation be covered by NSIS or = Seamoby (CAR
> > discovery protocol).
> >
> > IMHO it should be covered by CAR discovery = and not NSIS. CAR
> > discovery is supposed to identify = candidate access routers
> > for handoff and QoS is an important = property for candidacy.
>
> CAR discovery may be used to select handoff = targets with
> correct QoS support / capabilities.  = Context Transfer (CT)
> can be used with the handoff procedure to = ensure proper
> QoS state gets transfered to the new access = router.
>
> If there is anyone interested in this work, = please let me
> know.  The SeaMoby chairs asked me to see = if NSIS can provide
> them any information about QoS needs.
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> thanks,
> John
>
> = _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis=
>

------_=_NextPart_001_01C1DCBB.DC2024F6-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Apr 5 11:11:48 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08476 for ; Fri, 5 Apr 2002 11:11:47 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA10920 for nsis-archive@odin.ietf.org; Fri, 5 Apr 2002 11:11:53 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA10766; Fri, 5 Apr 2002 11:07:14 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA10655 for ; Fri, 5 Apr 2002 11:07:07 -0500 (EST) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08328; Fri, 5 Apr 2002 11:06:44 -0500 (EST) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g35G67w25668; Fri, 5 Apr 2002 11:06:07 -0500 (EST) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 5 Apr 2002 11:06:07 -0500 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA49C7@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Hemant.Chaskar@nokia.com'" , nsis@ietf.org Cc: "'seamoby@ietf.org'" Subject: RE: [NSIS] Establishing QoS after handoff. Date: Fri, 5 Apr 2002 11:06:04 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DCB8.3380F6AC" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1DCB8.3380F6AC Content-Type: text/plain; charset="iso-8859-1" Hemant: Just a point of clarification, but as I understand CARD (and I don't understand it well), it is not a QoS negotiation protocol. The main application that you are referring to primarily arises out of a perceived need to determine at the MN the best link layer to handover over to when inter-technology handovers are involved. It can be applied to intra-technology handovers, but the value in that situation is highly questionable (e.g. since it is a discovery protocol, the implication is that the purpose is to determine the choice of channels available; for intra-technology handovers, there are many, many reasons why this "choice" may not be available). There is a requirement, 5.1.2, which seems to imply NSIS involvement during/after a handover. John has stated that this is not the intention (please correct me if I have this wrong John), in which case I think 5.1.2 needs to be clarified. Specifically, is NSIS to be used to negotiated new QoS for an existing flow after a handover, or is it specifically for establishing QoS for a new flow? I don't think the answer is boolean: the role of NSIS in QoS re-negotiation is still open, I believe, and clearly handover is a dynamic situation that could cause the QoS provided to change. I have been told there is no issue, but here's a frightening scenario: - a handover takes place, and context transfer has been used to move the QoS context to the new routers (by the requirements for CT this could be intra-, or inter- technology. Some of us believe that for "seamless" handovers, the context will be available at routers before the first packets need to be forwarded. This implies that there is a relationship, probabilistic perhaps, between the handover process and the target ARs for CT. - CARD is used by the MN to influence the handover decision (it is not clear to me how this happens, but it seems clear that for a more "seamless" handover, the MN should chose an AR that has received the appropriate context; if not, then what? - NSIS kicks in and starts re-negotiating QoS because of changes introduced by the handover; How do these three protocols interact to produce predictable outcomes? Or, perhaps, the question is, how do the functional entities associated with the three protocols interact before, during and after a handover? If it the interaction is within the functional entities, the respective wg's could declare the issue out of scope, but this approach does not sit well with me, for it seems to defer the problem to the people who have to implement this "stuff". Am I imagining things? Cheers, Gary > -----Original Message----- > From: Hemant.Chaskar@nokia.com [mailto:Hemant.Chaskar@nokia.com] > Sent: April 4, 2002 22:33 > To: nsis@ietf.org > Subject: RE: [NSIS] Establishing QoS after handoff. > > > Hi Sharif: > > There is currently a debate going on in Seamoby as to whether > this QoS negotiation be covered by NSIS or Seamoby (CAR > discovery protocol). > > IMHO it should be covered by CAR discovery and not NSIS. CAR > discovery is supposed to identify candidate access routers > for handoff and QoS is an important property for candidacy. > > Br, > Hemant > > -----Original Message----- > From: ext Shahrier, Sharif M. > [mailto:Sharif.Shahrier@InterDigital.com] > Sent: Thursday, April 04, 2002 3:35 PM > To: Shahrier, Sharif M. > Cc: 'nsis@ietf.org' > Subject: [NSIS] Establishing QoS after handoff. > > > > I have a question for clarification. > > I think it was stated that NSIS should only be concerned with the > establishment of QoS after handoff. > > This is inconvienent with respect to IP-level QoS > negotiation, which ideally > should be done before handoff has taken place. > > QoS negotiation is in the current requirements draft. > > So, NSIS signaling protocol development should be concerned > with activity > before handoff occurs. > > Sharif. > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > ------_=_NextPart_001_01C1DCB8.3380F6AC Content-Type: text/html; charset="iso-8859-1" RE: [NSIS] Establishing QoS after handoff.

Hemant:

  Just a point of clarification, but as I understand CARD (and
I don't understand it well), it is not a QoS negotiation
protocol. The main application that you are referring to primarily
arises out of a perceived need to determine at the MN the best link
layer to handover over to when inter-technology handovers are involved.
It can be applied to intra-technology handovers, but the value in
that situation is highly questionable (e.g. since it is a discovery
protocol, the implication is that the purpose is to determine the
choice of channels available; for intra-technology handovers, there
are many, many reasons why this "choice" may not be available).

  There is a requirement, 5.1.2, which seems to imply NSIS involvement
during/after a handover. John has stated that this is not the intention
(please correct me if I have this wrong John), in which case I think
5.1.2 needs to be clarified.

  Specifically, is NSIS to be used to negotiated new QoS for an
existing flow after a handover, or is it specifically for establishing
QoS for a new flow? I don't think the answer is boolean: the role
of NSIS in QoS re-negotiation is still open, I believe, and clearly
handover is a dynamic situation that could cause the QoS provided to change.

  I have been told there is no issue, but here's a frightening scenario:

        - a handover takes place, and context transfer has been used to
       move the QoS context to the new routers (by the requirements for
       CT this could be intra-, or inter- technology. Some of us believe
       that for "seamless" handovers, the context will be available at
       routers before the first packets need to be forwarded. This implies
       that there is a relationship, probabilistic perhaps, between
       the handover process and the target ARs for CT.

     - CARD is used by the MN to influence the handover decision (it
       is not clear to me how this happens, but it seems clear that
       for a more "seamless" handover, the MN should chose an AR that
       has received the appropriate context; if not, then what?

     - NSIS kicks in and starts re-negotiating QoS because of changes
       introduced by the handover;

  How do these three protocols interact to produce predictable outcomes?
Or, perhaps, the question is, how do the functional entities associated
with the three protocols interact before, during and after a handover?
If it the interaction is within the functional entities, the respective
wg's could declare the issue out of scope, but this approach does not
sit well with me, for it seems to defer the problem to the people who
have to implement this "stuff".

  Am I imagining things?

Cheers,
Gary


> -----Original Message-----
> From: Hemant.Chaskar@nokia.com [mailto:Hemant.Chaskar@nokia.com]
> Sent: April 4, 2002 22:33
> To: nsis@ietf.org
> Subject: RE: [NSIS] Establishing QoS after handoff.
>
>
> Hi Sharif:
>
> There is currently a debate going on in Seamoby as to whether
> this QoS negotiation be covered by NSIS or Seamoby (CAR
> discovery protocol).
>
> IMHO it should be covered by CAR discovery and not NSIS. CAR
> discovery is supposed to identify candidate access routers
> for handoff and QoS is an important property for candidacy.
>
> Br,
> Hemant
>
> -----Original Message-----
> From: ext Shahrier, Sharif M.
> [mailto:Sharif.Shahrier@InterDigital.com]
> Sent: Thursday, April 04, 2002 3:35 PM
> To: Shahrier, Sharif M.
> Cc: 'nsis@ietf.org'
> Subject: [NSIS] Establishing QoS after handoff.
>
>
>
> I have a question for clarification.
>
> I think it was stated that NSIS should only be concerned with the
> establishment of QoS after handoff.
>
> This is inconvienent with respect to IP-level QoS
> negotiation, which ideally
> should be done before handoff has taken place.
>
> QoS negotiation is in the current requirements draft.
>
> So, NSIS signaling protocol development should be concerned
> with activity
> before handoff occurs.
>
> Sharif.
>
>
>
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis
>
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis
>

------_=_NextPart_001_01C1DCB8.3380F6AC-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Apr 5 11:33:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09068 for ; Fri, 5 Apr 2002 11:33:28 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA12167 for nsis-archive@odin.ietf.org; Fri, 5 Apr 2002 11:33:34 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA11498; Fri, 5 Apr 2002 11:28:58 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA11464 for ; Fri, 5 Apr 2002 11:28:55 -0500 (EST) Received: from iraun2.uka.de (iraun2.uka.de [129.13.10.91]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08926 for ; Fri, 5 Apr 2002 11:28:45 -0500 (EST) Received: from irams1.ira.uka.de ([129.13.10.5]) by iraun2.uka.de with esmtp (Exim 3.30 #7 (Debian)) id 16tWZz-000349-00; Fri, 05 Apr 2002 18:28:47 +0200 Received: from i72pc127.tm.uni-karlsruhe.de ([141.3.70.78] helo=i72pc127.tm.uka.de) by irams1.ira.uka.de with esmtp (Exim 3.30 #7 (Debian)) id 16tWZz-0002kF-00; Fri, 05 Apr 2002 18:28:47 +0200 Received: from tpce10.ipv6.tm.uka.de (localhost [127.0.0.1]) by i72pc127.tm.uka.de (8.11.6/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id g35GSkf05197; Fri, 5 Apr 2002 18:28:46 +0200 Message-Id: <200204051628.g35GSkf05197@i72pc127.tm.uka.de> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4+dev To: Alban.Couturier@alcatel.fr cc: Gary Kenward , "'brunner@ccrle.nec.de'" , "Geib, Ruediger" , svenvandenbosch@hotmail.com, nsis@ietf.org Subject: Re: pre-emption (was RE: [NSIS] proposals related to NSIS WG draft) In-Reply-To: Message from Alban.Couturier@alcatel.fr of "Fri, 05 Apr 2002 17:46:19 +0200." <3CADC6CB.1CD86E37@alcatel.fr> References: <9FBD322B7824D511B36900508BF93C9C01AA49C3@zcard031.ca.nortel.com> <3CADC6CB.1CD86E37@alcatel.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Date: Fri, 05 Apr 2002 18:28:46 +0200 From: Roland Bless Content-Transfer-Encoding: 8bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Alban, the question is: is it really required to signal the priority of a reservation? I think Gary just said that both priority and preemption can be determined by the provider policy. Otherwise end-users can always signal highest priority for their requests, so the provider has to decide when to preempt and what to preempt anyway. While a preemption mechanism for reservations is perfectly reasonable (e.g. for 911 or possibly for handovers), I currently don't see a real requirement or benefit to _signal_ reservation priority. This should rather be a (local) policy issue. Regards, Roland > > Gary Kenward a écrit : > > > > Interesting. Why would this not be a policy decision? > > I dont understand the trouble here. We are making signaling, which is > per se the interface to an admission control function. Admission > control's role is to reject (hopefully not too much) users who want to > consume concurrently the same resources (such as an EF). > The first feature we can add to a "rough" signaling, is priority. For > example, when I want to call 911, I want the same QoS than a normal > call, this is normal voice, but I prefer not to be rejected by the > admission control. > > A way to implement priority is preemption. Which means to me to > interrupt the EF marking of already accepted flows, and notifying this > "normal" EF users they have no more the EF/voice quality. > There are other ways. For instance, an admission control can refuse > normal calls when some treshold is reached, and then only accept > priority calls. > > So I would conclude that preemption is not a requirement for NSIS, but > priority should be supported by nsis. > > > > > gary > > > > > -----Original Message----- > > > From: Marcus Brunner [mailto:brunner@ccrle.nec.de] > > > Sent: April 5, 2002 06:08 > > > To: Kenward, Gary [WDLN2:AN10:EXCH]; Geib, Ruediger; > > > svenvandenbosch@hotmail.com > > > Cc: nsis@ietf.org > > > Subject: RE: pre-emption (was RE: [NSIS] proposals related to NSIS > > WG > > > draf t) > > > > > > > > > We are not talking about priority of data traffic overothers, > > > but on the > > > case of the capacity already completly give away and a new > > > service request > > > arriving. One can then specify, whether it is possible to preempt > > > guaranteed reservations. > > > > > > I would like see whether this is worth a reqirement. > > > > > > Marcus > > > > > > --On Thursday, April 04, 2002 12:37 PM -0500 Gary Kenward > > > wrote: > > > > > > > > > > > I guess my main issue is that this "requirement" seems to embed > > > > definitions of flow treatment in the definition of the signalling > > > > protocol. This, to me, is simply the wrong thing to do, unless > > there > > > > is not clear reason why the two cannot be kept separate. I haven't > > > > > > heard this reason. > > > > > > > > BTW: the priority of a flow IS coupled to it's QoS requirements. > > > > As a counter example, what does an low priority EF flow mean? > > > > Could you support EF PHB for a flow if it had a "lower > > > priority" (where > > > > lower priority implies a higher liklihood of pre-emption of > > service) > > > > then an AF or BE flow within a router? The answer is, very > > > probably not. > > > > > > > > Let's not debate QoS definitions in NSIS. I think John has > > > stated that > > > > QoS definition is out of scope for NSIS, and declaring a > > > particular flow > > > > treatment such as priority as not being QoS doesn't help. > > > > > > > > Gary > > > > > > > >> -----Original Message----- > > > >> From: Marcus Brunner [mailto:brunner@ccrle.nec.de] > > > >> Sent: April 4, 2002 06:40 > > > >> To: Geib, Ruediger; svenvandenbosch@hotmail.com > > > >> Cc: nsis@ietf.org > > > >> Subject: pre-emption (was RE: [NSIS] proposals related to > > > >> NSIS WG draft) > > > >> > > > >> > > > >> As Ruediger I would like to hear some other opinions as well. > > > >> I think the > > > >> whole fault handling is an open issue anyway and preempting > > > >> flows might > > > >> play a roll in fault handling as well. > > > >> > > > >> Marcus > > > >> > > > >> --On Tuesday, April 02, 2002 4:27 PM +0200 "Geib, Ruediger" > > > >> wrote: > > > >> > > > >> > Hi Sven, > > > >> > > > > >> > the comment is a bit late, but I've been offline for a while. > > > >> > Nevertheless: > > > >> > > > > >> >> * New requirements > > > >> >> - in section MUST support priority > > > >> >> The priority of a flow is essentially decoupled from > > > >> >> its QoS requirements. Therefore the protocol MUST > > > >> >> support priority. As a consequence, it MUST support > > > >> >> preemption of traffic flows in case of congestion or > > > >> >> failure. A preemption action MAY trigger an attempt > > > >> >> to resetup the request by means of another instance > > > >> >> of an NSIS signaling protocol. > > > >> > > > > >> > Could you provide some clearer argumentation why > > > >> > preemption is a requirement? I'd classify preemption > > > >> > as a "nice to have" feature, no more than a "MAY" > > > >> > requirement. I'd especially insist on preemption being > > > >> > completely decoupled from QoS and any other service > > > >> > related signalling. > > > >> > I.e. if it is not supported by an opperator, no > > > >> > parameters or messages related to preemption are > > > >> > to be transported. > > > >> > > > > >> > I'd like to ask other representatives of operators for > > > >> > their view. > > > >> > > > > >> > Regards, Rüdiger > > > >> > > > > >> > _______________________________________________ > > > >> > nsis mailing list > > > >> > nsis@ietf.org > > > >> > https://www1.ietf.org/mailman/listinfo/nsis > > > >> > > > >> > > > >> > > > >> -------------------------------------- > > > >> Dr. Marcus Brunner > > > >> Network Laboratories > > > >> NEC Europe Ltd. > > > >> > > > >> E-Mail: brunner@ccrle.nec.de > > > >> WWW: http://www.ccrle.nec.de/ > > > >> personal home page: http://www.brubers.org/marcus > > > >> > > > >> > > > >> > > > >> _______________________________________________ > > > >> nsis mailing list > > > >> nsis@ietf.org > > > >> https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > > > -------------------------------------- > > > Dr. Marcus Brunner > > > Network Laboratories > > > NEC Europe Ltd. > > > > > > E-Mail: brunner@ccrle.nec.de > > > WWW: http://www.ccrle.nec.de/ > > > personal home page: http://www.brubers.org/marcus > > > > > > > > > > > > _______________________________________________ > > > nsis mailing list > > > nsis@ietf.org > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > -- > Alban Couturier > --------------------------------------------------------------------- > Alcatel Research and Innovation > Ets de Marcoussis R&I/ULC > Route de Nozay mailto:Alban.Couturier@alcatel.fr > F-91461 Marcoussis CEDEX tel: +33 1 69 63 11 97 > --------------------------------------------------------------------- > > _______________________________________________ > 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 daemon@optimus.ietf.org Fri Apr 5 11:40:13 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09220 for ; Fri, 5 Apr 2002 11:40:13 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA12411 for nsis-archive@odin.ietf.org; Fri, 5 Apr 2002 11:40:18 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA12304; Fri, 5 Apr 2002 11:35:23 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA12227 for ; Fri, 5 Apr 2002 11:35:18 -0500 (EST) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09104 for ; Fri, 5 Apr 2002 11:35:11 -0500 (EST) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g35GSpw27223; Fri, 5 Apr 2002 11:28:51 -0500 (EST) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 5 Apr 2002 11:28:51 -0500 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA49C9@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Alban.Couturier@alcatel.fr'" Cc: "'brunner@ccrle.nec.de'" , "Geib, Ruediger" , svenvandenbosch@hotmail.com, nsis@ietf.org Subject: RE: pre-emption (was RE: [NSIS] proposals related to NSIS WG draf t) Date: Fri, 5 Apr 2002 11:28:49 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DCBE.C219D798" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1DCBE.C219D798 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The issue is whether this is a new feature that needs to be addressed = by an NSIS solution or whether it is an interworking issue. NSIS should not be attempting to replace the existing IETF solutions = unless there is a clear issue to be resolved. Gary > -----Original Message----- > From: Alban.Couturier@alcatel.fr [mailto:Alban.Couturier@alcatel.fr] > Sent: April 5, 2002 10:46 > To: Kenward, Gary [WDLN2:AN10:EXCH] > Cc: 'brunner@ccrle.nec.de'; Geib, Ruediger;=20 > svenvandenbosch@hotmail.com; > nsis@ietf.org > Subject: Re: pre-emption (was RE: [NSIS] proposals related to NSIS WG > draft) >=20 >=20 >=20 >=20 > > Gary Kenward a =E9crit : > >=20 > > Interesting. Why would this not be a policy decision? > =20 > I dont understand the trouble here. We are making signaling, which is > per se the interface to an admission control function. Admission > control's role is to reject (hopefully not too much) users who want = to > consume concurrently the same resources (such as an EF). > The first feature we can add to a "rough" signaling, is priority. For > example, when I want to call 911, I want the same QoS than a normal > call, this is normal voice, but I prefer not to be rejected by the > admission control. >=20 > A way to implement priority is preemption. Which means to me to > interrupt the EF marking of already accepted flows, and notifying = this > "normal" EF users they have no more the EF/voice quality. > There are other ways. For instance, an admission control can refuse > normal calls when some treshold is reached, and then only accept > priority calls. > =20 > So I would conclude that preemption is not a requirement for NSIS, = but > priority should be supported by nsis.=20 >=20 >=20 >=20 > > gary > >=20 > > > -----Original Message----- > > > From: Marcus Brunner [mailto:brunner@ccrle.nec.de] > > > Sent: April 5, 2002 06:08 > > > To: Kenward, Gary [WDLN2:AN10:EXCH]; Geib, Ruediger; > > > svenvandenbosch@hotmail.com > > > Cc: nsis@ietf.org > > > Subject: RE: pre-emption (was RE: [NSIS] proposals related to = NSIS > > WG > > > draf t) > > > > > > > > > We are not talking about priority of data traffic overothers, > > > but on the > > > case of the capacity already completly give away and a new > > > service request > > > arriving. One can then specify, whether it is possible to preempt > > > guaranteed reservations. > > > > > > I would like see whether this is worth a reqirement. > > > > > > Marcus > > > > > > --On Thursday, April 04, 2002 12:37 PM -0500 Gary Kenward > > > wrote: > > > > > > > > > > > I guess my main issue is that this "requirement" seems to embed > > > > definitions of flow treatment in the definition of the=20 > signalling > > > > protocol. This, to me, is simply the wrong thing to do, unless > > there > > > > is not clear reason why the two cannot be kept=20 > separate. I haven't > >=20 > > > > heard this reason. > > > > > > > > BTW: the priority of a flow IS coupled to it's QoS = requirements. > > > > As a counter example, what does an low priority EF flow mean? > > > > Could you support EF PHB for a flow if it had a "lower > > > priority" (where > > > > lower priority implies a higher liklihood of pre-emption of > > service) > > > > then an AF or BE flow within a router? The answer is, very > > > probably not. > > > > > > > > Let's not debate QoS definitions in NSIS. I think John has > > > stated that > > > > QoS definition is out of scope for NSIS, and declaring a > > > particular flow > > > > treatment such as priority as not being QoS doesn't help. > > > > > > > > Gary > > > > > > > >> -----Original Message----- > > > >> From: Marcus Brunner [mailto:brunner@ccrle.nec.de] > > > >> Sent: April 4, 2002 06:40 > > > >> To: Geib, Ruediger; svenvandenbosch@hotmail.com > > > >> Cc: nsis@ietf.org > > > >> Subject: pre-emption (was RE: [NSIS] proposals related to > > > >> NSIS WG draft) > > > >> > > > >> > > > >> As Ruediger I would like to hear some other opinions as well. > > > >> I think the > > > >> whole fault handling is an open issue anyway and preempting > > > >> flows might > > > >> play a roll in fault handling as well. > > > >> > > > >> Marcus > > > >> > > > >> --On Tuesday, April 02, 2002 4:27 PM +0200 "Geib, Ruediger" > > > >> wrote: > > > >> > > > >> > Hi Sven, > > > >> > > > > >> > the comment is a bit late, but I've been offline for a = while. > > > >> > Nevertheless: > > > >> > > > > >> >> * New requirements > > > >> >> - in section MUST support priority > > > >> >> The priority of a flow is essentially decoupled from > > > >> >> its QoS requirements. Therefore the protocol MUST > > > >> >> support priority. As a consequence, it MUST support > > > >> >> preemption of traffic flows in case of congestion or > > > >> >> failure. A preemption action MAY trigger an attempt > > > >> >> to resetup the request by means of another instance > > > >> >> of an NSIS signaling protocol. > > > >> > > > > >> > Could you provide some clearer argumentation why > > > >> > preemption is a requirement? I'd classify preemption > > > >> > as a "nice to have" feature, no more than a "MAY" > > > >> > requirement. I'd especially insist on preemption being > > > >> > completely decoupled from QoS and any other service > > > >> > related signalling. > > > >> > I.e. if it is not supported by an opperator, no > > > >> > parameters or messages related to preemption are > > > >> > to be transported. > > > >> > > > > >> > I'd like to ask other representatives of operators for > > > >> > their view. > > > >> > > > > >> > Regards, R=FCdiger > > > >> > > > > >> > _______________________________________________ > > > >> > nsis mailing list > > > >> > nsis@ietf.org > > > >> > https://www1.ietf.org/mailman/listinfo/nsis > > > >> > > > >> > > > >> > > > >> -------------------------------------- > > > >> Dr. Marcus Brunner > > > >> Network Laboratories > > > >> NEC Europe Ltd. > > > >> > > > >> E-Mail: brunner@ccrle.nec.de > > > >> WWW: http://www.ccrle.nec.de/ > > > >> personal home page: http://www.brubers.org/marcus > > > >> > > > >> > > > >> > > > >> _______________________________________________ > > > >> nsis mailing list > > > >> nsis@ietf.org > > > >> https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > > > -------------------------------------- > > > Dr. Marcus Brunner > > > Network Laboratories > > > NEC Europe Ltd. > > > > > > E-Mail: brunner@ccrle.nec.de > > > WWW: http://www.ccrle.nec.de/ > > > personal home page: http://www.brubers.org/marcus > > > > > > > > > > > > _______________________________________________ > > > nsis mailing list > > > nsis@ietf.org > > > https://www1.ietf.org/mailman/listinfo/nsis > > > >=20 > --=20 > Alban Couturier > --------------------------------------------------------------------- > Alcatel Research and Innovation > Ets de Marcoussis R&I/ULC > Route de Nozay mailto:Alban.Couturier@alcatel.fr > F-91461 Marcoussis CEDEX tel: +33 1 69 63 11 97 > --------------------------------------------------------------------- >=20 ------_=_NextPart_001_01C1DCBE.C219D798 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: pre-emption (was RE: [NSIS] proposals related to NSIS WG = draft)

The issue is whether this is a new feature that needs = to be addressed by
an NSIS solution or whether it is an interworking = issue.

NSIS should not be attempting to replace the existing = IETF solutions unless
there is a clear issue to be resolved.

Gary

> -----Original Message-----
> From: Alban.Couturier@alcatel.fr [mailto:Alban.Couturier@alcate= l.fr]
> Sent: April 5, 2002 10:46
> To: Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: 'brunner@ccrle.nec.de'; Geib, Ruediger; =
> svenvandenbosch@hotmail.com;
> nsis@ietf.org
> Subject: Re: pre-emption (was RE: [NSIS] = proposals related to NSIS WG
> draft)
>
>
>
>
> > Gary Kenward a =E9crit :
> >
> > Interesting. Why would this not be a = policy decision?
> 
> I dont understand the trouble here. We are = making signaling, which is
> per se the interface to an admission control = function. Admission
> control's role is to reject (hopefully not too = much) users who want to
> consume concurrently the same resources (such = as an EF).
> The first feature we can add to a = "rough" signaling, is priority. For
> example, when I want to call 911, I want the = same QoS than a normal
> call, this is normal voice, but I prefer not to = be rejected by the
> admission control.
>
> A way to implement priority is preemption. = Which  means to me to
> interrupt the EF marking of already accepted = flows, and notifying this
> "normal" EF users they have no more = the EF/voice quality.
> There are other ways. For instance, an = admission control can refuse
> normal calls when some treshold is reached, and = then only accept
> priority calls.
> 
> So I would conclude that preemption is not a = requirement for NSIS, but
> priority should be supported by nsis.
>
>
>
> > gary
> >
> > > -----Original Message-----
> > > From: Marcus Brunner [mailto:brunner@ccrle.nec.de]
> > > Sent: April 5, 2002 06:08
> > > To: Kenward, Gary [WDLN2:AN10:EXCH]; = Geib, Ruediger;
> > > svenvandenbosch@hotmail.com
> > > Cc: nsis@ietf.org
> > > Subject: RE: pre-emption (was RE: = [NSIS] proposals related to NSIS
> > WG
> > > draf t)
> > >
> > >
> > > We are not talking about priority of = data traffic overothers,
> > > but on the
> > > case of the capacity already = completly give away and a new
> > > service request
> > > arriving. One can then specify, = whether it is possible to preempt
> > > guaranteed reservations.
> > >
> > > I would like see whether this is = worth a reqirement.
> > >
> > > Marcus
> > >
> > > --On Thursday, April 04, 2002 12:37 = PM -0500 Gary Kenward
> > > <gkenward@nortelnetworks.com> = wrote:
> > >
> > > >
> > > > I guess my main issue is that = this "requirement" seems to embed
> > > > definitions of flow treatment in = the definition of the
> signalling
> > > > protocol. This, to me, is simply = the wrong thing to do, unless
> > there
> > > > is not clear reason why the two = cannot be kept
> separate. I haven't
> >
> > > > heard this reason.
> > > >
> > > > BTW: the priority of a flow IS = coupled to it's QoS requirements.
> > > > As a counter example, what does = an low priority EF flow mean?
> > > > Could you support EF PHB for a = flow if it had a "lower
> > > priority" (where
> > > > lower priority implies a higher = liklihood of pre-emption of
> > service)
> > > > then an AF or BE flow within a = router? The answer is, very
> > > probably not.
> > > >
> > > > Let's not debate QoS definitions = in NSIS. I think John has
> > > stated that
> > > > QoS definition is out of scope = for NSIS, and declaring a
> > > particular flow
> > > > treatment such as priority as = not being QoS doesn't help.
> > > >
> > > > Gary
> > > >
> > > >> -----Original = Message-----
> > > >> From: Marcus Brunner [mailto:brunner@ccrle.nec.de]
> > > >> Sent: April 4, 2002 = 06:40
> > > >> To: Geib, Ruediger; = svenvandenbosch@hotmail.com
> > > >> Cc: nsis@ietf.org
> > > >> Subject: pre-emption (was = RE: [NSIS] proposals related to
> > > >> NSIS WG draft)
> > > >>
> > > >>
> > > >> As Ruediger I would like to = hear some other opinions as well.
> > > >> I think the
> > > >> whole fault handling is an = open issue anyway and preempting
> > > >> flows might
> > > >> play a roll in fault = handling as well.
> > > >>
> > > >> Marcus
> > > >>
> > > >> --On Tuesday, April 02, 2002 = 4:27 PM +0200 "Geib, Ruediger"
> > > >> = <Ruediger.Geib@t-systems.com> wrote:
> > > >>
> > > >> > Hi Sven,
> > > >> >
> > > >> > the comment is a bit = late, but I've been offline for a while.
> > > >> > Nevertheless:
> > > >> >
> > > >> >> * New = requirements
> > > >> >> - in section MUST = support priority
> > > >> >>   The = priority of a flow is essentially decoupled from
> > > >> >>   its QoS = requirements. Therefore the protocol MUST
> > > >> >>   support = priority. As a consequence, it MUST support
> > > >> >>   = preemption of traffic flows in case of congestion or
> > > >> >>   = failure. A preemption action MAY trigger an attempt
> > > >> >>   to = resetup the request by means of another instance
> > > >> >>   of an = NSIS signaling protocol.
> > > >> >
> > > >> > Could you provide some = clearer argumentation why
> > > >> > preemption is a = requirement? I'd classify preemption
> > > >> > as a "nice to = have" feature, no more than a "MAY"
> > > >> > requirement. I'd = especially insist on preemption being
> > > >> > completely decoupled = from QoS and any other service
> > > >> > related = signalling.
> > > >> > I.e. if it is not = supported by an opperator, no
> > > >> > parameters or messages = related to preemption are
> > > >> > to be = transported.
> > > >> >
> > > >> > I'd like to ask other = representatives of operators for
> > > >> > their view.
> > > >> >
> > > >> > Regards, = R=FCdiger
> > > >> >
> > > >> > = _______________________________________________
> > > >> > nsis mailing = list
> > > >> > nsis@ietf.org
> > > >> > https://www1.ietf.org/mailman/listinfo/nsis=
> > > >>
> > > >>
> > > >>
> > > >> = --------------------------------------
> > > >> Dr. Marcus Brunner
> > > >> Network Laboratories
> > > >> NEC Europe Ltd.
> > > >>
> > > >> E-Mail: = brunner@ccrle.nec.de
> > > >> WWW:    http://www.ccrle.nec.de/
> > > >> personal home page: http://www.brubers.org/marcus
> > > >>
> > > >>
> > > >>
> > > >> = _______________________________________________
> > > >> nsis mailing list
> > > >> nsis@ietf.org
> > > >> https://www1.ietf.org/mailman/listinfo/nsis=
> > >
> > >
> > >
> > > = --------------------------------------
> > > Dr. Marcus Brunner
> > > Network Laboratories
> > > NEC Europe Ltd.
> > >
> > > E-Mail: brunner@ccrle.nec.de
> > > WWW:    http://www.ccrle.nec.de/
> > > personal home page: http://www.brubers.org/marcus
> > >
> > >
> > >
> > > = _______________________________________________
> > > nsis mailing list
> > > nsis@ietf.org
> > > https://www1.ietf.org/mailman/listinfo/nsis=
> > >
>
> --
> Alban Couturier
> = ---------------------------------------------------------------------
> Alcatel Research and Innovation
> Ets de Marcoussis R&I/ULC
> Route de = Nozay           &= nbsp;          mailto:Alban.Couturier@alcate= l.fr
> F-91461 Marcoussis = CEDEX           &= nbsp;           tel: = +33 1 69 63 11 97
> = ---------------------------------------------------------------------
>

------_=_NextPart_001_01C1DCBE.C219D798-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Apr 5 11:50:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09555 for ; Fri, 5 Apr 2002 11:50:00 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA12750 for nsis-archive@odin.ietf.org; Fri, 5 Apr 2002 11:49:53 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA12676; Fri, 5 Apr 2002 11:45:18 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA12649 for ; Fri, 5 Apr 2002 11:45:16 -0500 (EST) Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09445 for ; Fri, 5 Apr 2002 11:45:08 -0500 (EST) Received: from JMPOLK-W2K (ssh-sjc-1.cisco.com [171.68.225.134]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id IAA13570 for ; Fri, 5 Apr 2002 08:44:41 -0800 (PST) Message-Id: <4.1.20020405101745.0c36f420@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Fri, 05 Apr 2002 10:44:11 -0600 To: nsis@ietf.org From: "James M. Polk" In-Reply-To: <9FBD322B7824D511B36900508BF93C9C01AA49C4@zcard031.ca.norte l.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_1167177963==_.ALT" Subject: [NSIS] Preemption Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org --=====================_1167177963==_.ALT Content-Type: text/plain; charset="us-ascii" Preemption is real and will continue to be real in the real world for decades and/or longer. Preemption, other than by randomizing mechanisms, is a deterministic action based on local policy *only* when there are in place certain differentiators between packets/flows to appropriately perform this action. Preemption shouldn't be mandatory in all product implementations. However, the ability to perform this action shouldn't be omitted from this WG's output. The ability to preempt should be optional, and if chosen, should have specific definitions to follow coming from NSIS. For examples of preemption in today's networks, merely look at eMLPP in GSM networks which has 15 levels of Priority with 5 of these levels having hierarchical preemption characteristics operational. Look at MLPP in US DOD and NATO networks (5 levels). Verizon and VoiceStream petitioned the US FCC (Nov 01) to each "enable" eMLPP Preemption in their public deployments of Wireless throughout the US (if not North America). Many countries have preemption within their existing PSTN today, many others forbid it (to clarify - the US is *NOT* one of them). If NSIS wants to migrate any of these networks over to IP, or be part of any migration or transition, preemption ought to be defined the WG, albeit as an option - with specifics surrounding that/those options. ************************************* "People generally demand more respect for their own rights than they are willing to allow for others" James M. Polk Consulting Engineer Office of the CTO Cisco Systems 2200 East President George Bush Turnpike Richardson, TX 75082 USA w) 972.813.5208 f) 972.813.5280 www.cisco.com --=====================_1167177963==_.ALT Content-Type: text/html; charset="us-ascii" Preemption is real and will continue to be real in the real world for decades and/or longer.

Preemption, other than by randomizing mechanisms, is a deterministic action based on local policy *only* when there are in place certain differentiators between packets/flows to appropriately perform this action.

Preemption shouldn't be mandatory in all product implementations. However, the ability to perform this action shouldn't be omitted from this WG's output.

The ability to preempt should be optional, and if chosen, should have specific definitions to follow coming from NSIS.

For examples of preemption in today's networks, merely look at eMLPP in GSM networks which has 15 levels of Priority with 5 of these levels having hierarchical preemption characteristics operational. Look at MLPP in US DOD and NATO networks (5 levels). Verizon and VoiceStream petitioned the US FCC (Nov 01) to each "enable" eMLPP Preemption in their public deployments of Wireless throughout the US (if not North America). Many countries have preemption within their existing PSTN today, many others forbid it (to clarify - the US is *NOT* one of them).

If NSIS wants to migrate any of these networks over to IP, or be part of any migration or transition, preemption ought to be defined the WG, albeit as an option - with specifics surrounding that/those options.


*************************************
"People generally demand more respect for their own rights than they are willing to allow for others"

James M. Polk
Consulting Engineer
Office of the CTO

Cisco Systems
2200 East President George Bush Turnpike
Richardson, TX  75082 USA
w) 972.813.5208
f)  972.813.5280
www.cisco.com --=====================_1167177963==_.ALT-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Apr 5 12:03:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10015 for ; Fri, 5 Apr 2002 12:03:49 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA14708 for nsis-archive@odin.ietf.org; Fri, 5 Apr 2002 12:03:54 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA13083; Fri, 5 Apr 2002 11:58:57 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA13053 for ; Fri, 5 Apr 2002 11:58:55 -0500 (EST) Received: from aifhs8.alcatel.fr (mail3-c.alcatel.fr [213.223.66.53]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09794 for ; Fri, 5 Apr 2002 11:58:48 -0500 (EST) From: Alban.Couturier@alcatel.fr Received: from frmail30.netfr.alcatel.fr (frmail30.netfr.alcatel.fr [155.132.182.163]) by aifhs8.alcatel.fr (ALCANET/SMTP2) with ESMTP id SAA05972; Fri, 5 Apr 2002 18:57:21 +0200 (MET DST) Received: from alcatel.fr ([139.54.208.245]) by frmail30.netfr.alcatel.fr (Lotus Domino Release 5.0.9a) with ESMTP id 2002040518571956:8861 ; Fri, 5 Apr 2002 18:57:19 +0200 Message-ID: <3CADD785.9CC48F1A@alcatel.fr> Date: Fri, 05 Apr 2002 18:57:41 +0200 Organization: Alcatel X-Mailer: Mozilla 4.78 [fr] (Windows NT 5.0; U) X-Accept-Language: fr MIME-Version: 1.0 To: Roland Bless Cc: Gary Kenward , "'brunner@ccrle.nec.de'" , "Geib, Ruediger" , svenvandenbosch@hotmail.com, nsis@ietf.org Subject: Re: pre-emption (was RE: [NSIS] proposals related to NSIS WG draft) References: <9FBD322B7824D511B36900508BF93C9C01AA49C3@zcard031.ca.nortel.com> <3CADC6CB.1CD86E37@alcatel.fr> <200204051628.g35GSkf05197@i72pc127.tm.uka.de> X-MIMETrack: Itemize by SMTP Server on FRMAIL30/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 04/05/2002 18:57:19, Serialize by Router on FRMAIL30/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 04/05/2002 18:57:21, Serialize complete at 04/05/2002 18:57:21 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA13054 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Roland Bless a écrit : > > Hi Alban, > > the question is: is it really required to signal the priority > of a reservation? I think Gary just said that both priority > and preemption can be determined by the provider policy. > Otherwise end-users can always signal highest priority > for their requests, so the provider has to decide when to preempt > and what to preempt anyway. While a preemption mechanism for > reservations is perfectly reasonable (e.g. for 911 or possibly > for handovers), I currently don't see a real requirement or > benefit to _signal_ reservation priority. This should rather > be a (local) policy issue. Hi Gary and Roland My question is how can the provider know that a particular flow deserve a higher priority when a user requests QoS? Sometimes a user want not to be prempted or really wants its request to be satisfied because he calls his boss, or the police etc... Sometimes, the same user wants a "regular" call or session, which implies that the network may refuse it because there is in competition a call to 911 or a session with a big boss. So only the initiator could signal to the network that a session is really more important than another. It's just a question of a high/medium/normal tag in a request. The network could then accept this priority, or not, depending on policy/user profile... In case of network failure, the QoS controller could also react in order to reestablish the high priority flows before the others. The only other solution i see could be to put this priority information in the service description. But again, this type of solution mixes admission control performed by the QoS controller, and the provisionning of QoS. This lead to difficulties in network provisionning, or/and to a poor design in the QoS controller that will be QSC dependant. Regards > Regards, > Roland > > > > Gary Kenward a écrit : > > > > > > Interesting. Why would this not be a policy decision? > > > > I dont understand the trouble here. We are making signaling, which is > > per se the interface to an admission control function. Admission > > control's role is to reject (hopefully not too much) users who want to > > consume concurrently the same resources (such as an EF). > > The first feature we can add to a "rough" signaling, is priority. For > > example, when I want to call 911, I want the same QoS than a normal > > call, this is normal voice, but I prefer not to be rejected by the > > admission control. > > > > A way to implement priority is preemption. Which means to me to > > interrupt the EF marking of already accepted flows, and notifying this > > "normal" EF users they have no more the EF/voice quality. > > There are other ways. For instance, an admission control can refuse > > normal calls when some treshold is reached, and then only accept > > priority calls. > > > > So I would conclude that preemption is not a requirement for NSIS, but > > priority should be supported by nsis. > > > > > > > > > gary > > > > > > > -----Original Message----- > > > > From: Marcus Brunner [mailto:brunner@ccrle.nec.de] > > > > Sent: April 5, 2002 06:08 > > > > To: Kenward, Gary [WDLN2:AN10:EXCH]; Geib, Ruediger; > > > > svenvandenbosch@hotmail.com > > > > Cc: nsis@ietf.org > > > > Subject: RE: pre-emption (was RE: [NSIS] proposals related to NSIS > > > WG > > > > draf t) > > > > > > > > > > > > We are not talking about priority of data traffic overothers, > > > > but on the > > > > case of the capacity already completly give away and a new > > > > service request > > > > arriving. One can then specify, whether it is possible to preempt > > > > guaranteed reservations. > > > > > > > > I would like see whether this is worth a reqirement. > > > > > > > > Marcus > > > > > > > > --On Thursday, April 04, 2002 12:37 PM -0500 Gary Kenward > > > > wrote: > > > > > > > > > > > > > > I guess my main issue is that this "requirement" seems to embed > > > > > definitions of flow treatment in the definition of the signalling > > > > > protocol. This, to me, is simply the wrong thing to do, unless > > > there > > > > > is not clear reason why the two cannot be kept separate. I haven't > > > > > > > > heard this reason. > > > > > > > > > > BTW: the priority of a flow IS coupled to it's QoS requirements. > > > > > As a counter example, what does an low priority EF flow mean? > > > > > Could you support EF PHB for a flow if it had a "lower > > > > priority" (where > > > > > lower priority implies a higher liklihood of pre-emption of > > > service) > > > > > then an AF or BE flow within a router? The answer is, very > > > > probably not. > > > > > > > > > > Let's not debate QoS definitions in NSIS. I think John has > > > > stated that > > > > > QoS definition is out of scope for NSIS, and declaring a > > > > particular flow > > > > > treatment such as priority as not being QoS doesn't help. > > > > > > > > > > Gary > > > > > > > > > >> -----Original Message----- > > > > >> From: Marcus Brunner [mailto:brunner@ccrle.nec.de] > > > > >> Sent: April 4, 2002 06:40 > > > > >> To: Geib, Ruediger; svenvandenbosch@hotmail.com > > > > >> Cc: nsis@ietf.org > > > > >> Subject: pre-emption (was RE: [NSIS] proposals related to > > > > >> NSIS WG draft) > > > > >> > > > > >> > > > > >> As Ruediger I would like to hear some other opinions as well. > > > > >> I think the > > > > >> whole fault handling is an open issue anyway and preempting > > > > >> flows might > > > > >> play a roll in fault handling as well. > > > > >> > > > > >> Marcus > > > > >> > > > > >> --On Tuesday, April 02, 2002 4:27 PM +0200 "Geib, Ruediger" > > > > >> wrote: > > > > >> > > > > >> > Hi Sven, > > > > >> > > > > > >> > the comment is a bit late, but I've been offline for a while. > > > > >> > Nevertheless: > > > > >> > > > > > >> >> * New requirements > > > > >> >> - in section MUST support priority > > > > >> >> The priority of a flow is essentially decoupled from > > > > >> >> its QoS requirements. Therefore the protocol MUST > > > > >> >> support priority. As a consequence, it MUST support > > > > >> >> preemption of traffic flows in case of congestion or > > > > >> >> failure. A preemption action MAY trigger an attempt > > > > >> >> to resetup the request by means of another instance > > > > >> >> of an NSIS signaling protocol. > > > > >> > > > > > >> > Could you provide some clearer argumentation why > > > > >> > preemption is a requirement? I'd classify preemption > > > > >> > as a "nice to have" feature, no more than a "MAY" > > > > >> > requirement. I'd especially insist on preemption being > > > > >> > completely decoupled from QoS and any other service > > > > >> > related signalling. > > > > >> > I.e. if it is not supported by an opperator, no > > > > >> > parameters or messages related to preemption are > > > > >> > to be transported. > > > > >> > > > > > >> > I'd like to ask other representatives of operators for > > > > >> > their view. > > > > >> > > > > > >> > Regards, Rüdiger > > > > >> > > > > > >> > _______________________________________________ > > > > >> > nsis mailing list > > > > >> > nsis@ietf.org > > > > >> > https://www1.ietf.org/mailman/listinfo/nsis > > > > >> > > > > >> > > > > >> > > > > >> -------------------------------------- > > > > >> Dr. Marcus Brunner > > > > >> Network Laboratories > > > > >> NEC Europe Ltd. > > > > >> > > > > >> E-Mail: brunner@ccrle.nec.de > > > > >> WWW: http://www.ccrle.nec.de/ > > > > >> personal home page: http://www.brubers.org/marcus > > > > >> > > > > >> > > > > >> > > > > >> _______________________________________________ > > > > >> nsis mailing list > > > > >> nsis@ietf.org > > > > >> https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > > > > > > > -------------------------------------- > > > > Dr. Marcus Brunner > > > > Network Laboratories > > > > NEC Europe Ltd. > > > > > > > > E-Mail: brunner@ccrle.nec.de > > > > WWW: http://www.ccrle.nec.de/ > > > > personal home page: http://www.brubers.org/marcus > > > > > > > > > > > > > > > > _______________________________________________ > > > > nsis mailing list > > > > nsis@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > -- > > Alban Couturier > > --------------------------------------------------------------------- > > Alcatel Research and Innovation > > Ets de Marcoussis R&I/ULC > > Route de Nozay mailto:Alban.Couturier@alcatel.fr > > F-91461 Marcoussis CEDEX tel: +33 1 69 63 11 97 > > --------------------------------------------------------------------- > > > > _______________________________________________ > > 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 -- Alban Couturier --------------------------------------------------------------------- Alcatel Research and Innovation Ets de Marcoussis R&I/ULC Route de Nozay mailto:Alban.Couturier@alcatel.fr F-91461 Marcoussis CEDEX tel: +33 1 69 63 11 97 --------------------------------------------------------------------- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Apr 5 12:07:31 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10128 for ; Fri, 5 Apr 2002 12:07:29 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA14840 for nsis-archive@odin.ietf.org; Fri, 5 Apr 2002 12:07:35 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA14350; Fri, 5 Apr 2002 12:01:55 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA14305 for ; Fri, 5 Apr 2002 12:01:52 -0500 (EST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09890; Fri, 5 Apr 2002 12:01:45 -0500 (EST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id JAA07869; Fri, 5 Apr 2002 09:01:18 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g35H1HT16962; Fri, 5 Apr 2002 09:01:17 -0800 X-mProtect: <200204051701> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd7kAR5Z; Fri, 05 Apr 2002 09:01:15 PST Message-ID: <3CADD85C.F8C8D50F@iprg.nokia.com> Date: Fri, 05 Apr 2002 09:01:16 -0800 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Gary Kenward CC: "'Hemant.Chaskar@nokia.com'" , nsis@ietf.org, "'seamoby@ietf.org'" Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. References: <9FBD322B7824D511B36900508BF93C9C01AA49C7@zcard031.ca.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit Hello, well, if the issue is QoS establishment after handover, - CT is applicable for establishing QoS state at the AR - if further signaling is desired beyond the AR, NSIS may consider it. I don't see how _signaling_ for QoS establishment beyond AR is relevant for seamoby. CAR _discovery_ could exchange QoS capability as one of the parameters that might then be fed to a selection algorithm. Any signaling for actually establishing QoS itself beyond the AR should be outside the scope of seamoby.. Regards, -Rajeev Gary Kenward wrote: > > > Hemant: > > Just a point of clarification, but as I understand CARD (and > I don't understand it well), it is not a QoS negotiation > protocol. The main application that you are referring to primarily > arises out of a perceived need to determine at the MN the best link > layer to handover over to when inter-technology handovers are > involved. > It can be applied to intra-technology handovers, but the value in > that situation is highly questionable (e.g. since it is a discovery > protocol, the implication is that the purpose is to determine the > choice of channels available; for intra-technology handovers, there > are many, many reasons why this "choice" may not be available). > > There is a requirement, 5.1.2, which seems to imply NSIS involvement > > during/after a handover. John has stated that this is not the > intention > (please correct me if I have this wrong John), in which case I think > 5.1.2 needs to be clarified. > > Specifically, is NSIS to be used to negotiated new QoS for an > existing flow after a handover, or is it specifically for establishing > > QoS for a new flow? I don't think the answer is boolean: the role > of NSIS in QoS re-negotiation is still open, I believe, and clearly > handover is a dynamic situation that could cause the QoS provided to > change. > > I have been told there is no issue, but here's a frightening > scenario: > > - a handover takes place, and context transfer has been used > to > move the QoS context to the new routers (by the requirements > for > CT this could be intra-, or inter- technology. Some of us > believe > that for "seamless" handovers, the context will be available at > > routers before the first packets need to be forwarded. This > implies > that there is a relationship, probabilistic perhaps, between > the handover process and the target ARs for CT. > > - CARD is used by the MN to influence the handover decision (it > is not clear to me how this happens, but it seems clear that > for a more "seamless" handover, the MN should chose an AR that > has received the appropriate context; if not, then what? > > - NSIS kicks in and starts re-negotiating QoS because of changes > introduced by the handover; > > How do these three protocols interact to produce predictable > outcomes? > Or, perhaps, the question is, how do the functional entities > associated > with the three protocols interact before, during and after a handover? > > If it the interaction is within the functional entities, the > respective > wg's could declare the issue out of scope, but this approach does not > sit well with me, for it seems to defer the problem to the people who > have to implement this "stuff". > > Am I imagining things? > > Cheers, > Gary > > > -----Original Message----- > > From: Hemant.Chaskar@nokia.com [mailto:Hemant.Chaskar@nokia.com] > > Sent: April 4, 2002 22:33 > > To: nsis@ietf.org > > Subject: RE: [NSIS] Establishing QoS after handoff. > > > > > > Hi Sharif: > > > > There is currently a debate going on in Seamoby as to whether > > this QoS negotiation be covered by NSIS or Seamoby (CAR > > discovery protocol). > > > > IMHO it should be covered by CAR discovery and not NSIS. CAR > > discovery is supposed to identify candidate access routers > > for handoff and QoS is an important property for candidacy. > > > > Br, > > Hemant > > > > -----Original Message----- > > From: ext Shahrier, Sharif M. > > [mailto:Sharif.Shahrier@InterDigital.com] > > Sent: Thursday, April 04, 2002 3:35 PM > > To: Shahrier, Sharif M. > > Cc: 'nsis@ietf.org' > > Subject: [NSIS] Establishing QoS after handoff. > > > > > > > > I have a question for clarification. > > > > I think it was stated that NSIS should only be concerned with the > > establishment of QoS after handoff. > > > > This is inconvienent with respect to IP-level QoS > > negotiation, which ideally > > should be done before handoff has taken place. > > > > QoS negotiation is in the current requirements draft. > > > > So, NSIS signaling protocol development should be concerned > > with activity > > before handoff occurs. > > > > Sharif. > > > > > > > > _______________________________________________ > > 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 daemon@optimus.ietf.org Fri Apr 5 12:11:09 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10368 for ; Fri, 5 Apr 2002 12:11:09 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA15150 for nsis-archive@odin.ietf.org; Fri, 5 Apr 2002 12:11:15 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA14810; Fri, 5 Apr 2002 12:06:47 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA14776 for ; Fri, 5 Apr 2002 12:06:44 -0500 (EST) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10093 for ; Fri, 5 Apr 2002 12:06:36 -0500 (EST) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g35H5we00914; Fri, 5 Apr 2002 12:05:58 -0500 (EST) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 5 Apr 2002 12:05:57 -0500 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA49CC@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'James M. Polk'" , nsis@ietf.org Subject: RE: [NSIS] Preemption Date: Fri, 5 Apr 2002 12:05:56 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DCC3.039247BA" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1DCC3.039247BA Content-Type: text/plain; charset="iso-8859-1" The issue is not whether network xyz supports pre-emption or priorities, or EF, or AF, or CBR or ABR, or PDP contexts. The issue is whether the NSIS protocol definition is going to explicitly address every one of the access network specific local QoS solutions through the explicty definition of protocol fields and values, and protocol semantics. This is not only my view, it is the very first requirement in the wg draft: "5.1.1 Applicability for different QoS technologies. The QoS signaling protocol must work with various QoS technologies. The information exchanged over the signaling protocol must be in such detail and quantity that it is useful for various QoS technologies." We can debate the virtues and vices of priority models forever (it's certainly not a new debate). But the actual issue for NSIS is how to support all reasonable QoS solutions in an efficient manner. It is my view that defining NSIS protocol fields for every variation is not the way to proceed. Regards, Gary -----Original Message----- From: James M. Polk [mailto:jmpolk@cisco.com] Sent: April 5, 2002 11:44 To: nsis@ietf.org Subject: [NSIS] Preemption Preemption is real and will continue to be real in the real world for decades and/or longer. Preemption, other than by randomizing mechanisms, is a deterministic action based on local policy *only* when there are in place certain differentiators between packets/flows to appropriately perform this action. Preemption shouldn't be mandatory in all product implementations. However, the ability to perform this action shouldn't be omitted from this WG's output. The ability to preempt should be optional, and if chosen, should have specific definitions to follow coming from NSIS. For examples of preemption in today's networks, merely look at eMLPP in GSM networks which has 15 levels of Priority with 5 of these levels having hierarchical preemption characteristics operational. Look at MLPP in US DOD and NATO networks (5 levels). Verizon and VoiceStream petitioned the US FCC (Nov 01) to each "enable" eMLPP Preemption in their public deployments of Wireless throughout the US (if not North America). Many countries have preemption within their existing PSTN today, many others forbid it (to clarify - the US is *NOT* one of them). If NSIS wants to migrate any of these networks over to IP, or be part of any migration or transition, preemption ought to be defined the WG, albeit as an option - with specifics surrounding that/those options. ************************************* "People generally demand more respect for their own rights than they are willing to allow for others" James M. Polk Consulting Engineer Office of the CTO Cisco Systems 2200 East President George Bush Turnpike Richardson, TX 75082 USA w) 972.813.5208 f) 972.813.5280 www.cisco.com ------_=_NextPart_001_01C1DCC3.039247BA Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [NSIS] Preemption

The issue is not whether network xyz supports = pre-emption or priorities, or EF, or AF, or CBR or ABR,
or PDP contexts. The issue is whether the NSIS = protocol definition is going to explicitly address every
one of the access network specific local QoS = solutions through the explicty definition of protocol fields
and values, and protocol semantics.

This is not only my view, it is the very first = requirement in the wg draft:
 
"5.1.1 Applicability for different QoS = technologies.
 
   The QoS signaling protocol must work = with various QoS technologies.
   The information exchanged over the = signaling protocol must be in
   such detail and quantity that it is = useful for various QoS
   technologies."

We can debate the virtues and vices of priority = models forever (it's certainly not a new debate).
But the actual issue for NSIS is how to support all = reasonable QoS solutions in an efficient manner.
It is my view that defining NSIS protocol fields for = every variation is not the way to proceed.

Regards,
Gary

-----Original Message-----
From: James M. Polk [mailto:jmpolk@cisco.com]
Sent: April 5, 2002 11:44
To: nsis@ietf.org
Subject: [NSIS] Preemption


Preemption is real and will continue to be real in = the real world for decades and/or longer.

Preemption, other than by randomizing mechanisms, is = a deterministic action based on local policy *only* when there are in = place certain differentiators between packets/flows to appropriately = perform this action.

Preemption shouldn't be mandatory in all product = implementations. However, the ability to perform this action shouldn't = be omitted from this WG's output.

The ability to preempt should be optional, and if = chosen, should have specific definitions to follow coming from = NSIS.

For examples of preemption in today's networks, = merely look at eMLPP in GSM networks which has 15 levels of Priority = with 5 of these levels having hierarchical preemption characteristics = operational. Look at MLPP in US DOD and NATO networks (5 levels). = Verizon and VoiceStream petitioned the US FCC (Nov 01) to each = "enable" eMLPP Preemption in their public deployments of = Wireless throughout the US (if not North America). Many countries have = preemption within their existing PSTN today, many others forbid it (to = clarify - the US is *NOT* one of them).

If NSIS wants to migrate any of these networks over = to IP, or be part of any migration or transition, preemption ought to = be defined the WG, albeit as an option - with specifics surrounding = that/those options.



*************************************
"People generally demand more respect for their = own rights than they are willing to allow for others"


James M. Polk
Consulting Engineer
Office of the CTO

Cisco Systems
2200 East President George Bush Turnpike
Richardson, TX  75082 USA
w) 972.813.5208
f)  972.813.5280
www.cisco.com

------_=_NextPart_001_01C1DCC3.039247BA-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Apr 5 12:12:32 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10407 for ; Fri, 5 Apr 2002 12:12:32 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA15204 for nsis-archive@odin.ietf.org; Fri, 5 Apr 2002 12:12:38 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA15060; Fri, 5 Apr 2002 12:10:15 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA14995 for ; Fri, 5 Apr 2002 12:10:10 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10304; Fri, 5 Apr 2002 12:10:03 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g35H94I00267; Fri, 5 Apr 2002 09:09:04 -0800 (PST) Message-ID: <012f01c1dcc4$5cf69850$7e6015ac@T23KEMPF> From: "James Kempf" To: "Rajeev Koodli" , "Gary Kenward" Cc: , , References: <9FBD322B7824D511B36900508BF93C9C01AA49C7@zcard031.ca.nortel.com> <3CADD85C.F8C8D50F@iprg.nokia.com> Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Fri, 5 Apr 2002 09:07:27 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit There is an issue if CT fails. In that case, some kind of negotiation after handover would be required. So, I'd say that some indication of CT failure is needed. As for CAR, I don't see the relevance for QoS negotiation, though it may be useful for finding a new wireless medium. I also see it primarily for intertechnology handover, or, at best, interprovider handover. jak ----- Original Message ----- From: "Rajeev Koodli" To: "Gary Kenward" Cc: ; ; Sent: Friday, April 05, 2002 9:01 AM Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > Hello, > > well, if the issue is QoS establishment after handover, > > - CT is applicable for establishing QoS state at the AR > - if further signaling is desired beyond the AR, NSIS may > consider it. I don't see how _signaling_ for QoS establishment > beyond AR is relevant for seamoby. > > CAR _discovery_ could exchange QoS capability as one of the > parameters that might then be fed to a selection algorithm. Any > signaling for actually establishing QoS itself beyond the AR > should be outside the scope of seamoby.. > > Regards, > > -Rajeev > > > Gary Kenward wrote: > > > > > > > Hemant: > > > > Just a point of clarification, but as I understand CARD (and > > I don't understand it well), it is not a QoS negotiation > > protocol. The main application that you are referring to primarily > > arises out of a perceived need to determine at the MN the best link > > layer to handover over to when inter-technology handovers are > > involved. > > It can be applied to intra-technology handovers, but the value in > > that situation is highly questionable (e.g. since it is a discovery > > protocol, the implication is that the purpose is to determine the > > choice of channels available; for intra-technology handovers, there > > are many, many reasons why this "choice" may not be available). > > > > There is a requirement, 5.1.2, which seems to imply NSIS involvement > > > > during/after a handover. John has stated that this is not the > > intention > > (please correct me if I have this wrong John), in which case I think > > 5.1.2 needs to be clarified. > > > > Specifically, is NSIS to be used to negotiated new QoS for an > > existing flow after a handover, or is it specifically for establishing > > > > QoS for a new flow? I don't think the answer is boolean: the role > > of NSIS in QoS re-negotiation is still open, I believe, and clearly > > handover is a dynamic situation that could cause the QoS provided to > > change. > > > > I have been told there is no issue, but here's a frightening > > scenario: > > > > - a handover takes place, and context transfer has been used > > to > > move the QoS context to the new routers (by the requirements > > for > > CT this could be intra-, or inter- technology. Some of us > > believe > > that for "seamless" handovers, the context will be available at > > > > routers before the first packets need to be forwarded. This > > implies > > that there is a relationship, probabilistic perhaps, between > > the handover process and the target ARs for CT. > > > > - CARD is used by the MN to influence the handover decision (it > > is not clear to me how this happens, but it seems clear that > > for a more "seamless" handover, the MN should chose an AR that > > has received the appropriate context; if not, then what? > > > > - NSIS kicks in and starts re-negotiating QoS because of changes > > introduced by the handover; > > > > How do these three protocols interact to produce predictable > > outcomes? > > Or, perhaps, the question is, how do the functional entities > > associated > > with the three protocols interact before, during and after a handover? > > > > If it the interaction is within the functional entities, the > > respective > > wg's could declare the issue out of scope, but this approach does not > > sit well with me, for it seems to defer the problem to the people who > > have to implement this "stuff". > > > > Am I imagining things? > > > > Cheers, > > Gary > > > > > -----Original Message----- > > > From: Hemant.Chaskar@nokia.com [mailto:Hemant.Chaskar@nokia.com] > > > Sent: April 4, 2002 22:33 > > > To: nsis@ietf.org > > > Subject: RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > Hi Sharif: > > > > > > There is currently a debate going on in Seamoby as to whether > > > this QoS negotiation be covered by NSIS or Seamoby (CAR > > > discovery protocol). > > > > > > IMHO it should be covered by CAR discovery and not NSIS. CAR > > > discovery is supposed to identify candidate access routers > > > for handoff and QoS is an important property for candidacy. > > > > > > Br, > > > Hemant > > > > > > -----Original Message----- > > > From: ext Shahrier, Sharif M. > > > [mailto:Sharif.Shahrier@InterDigital.com] > > > Sent: Thursday, April 04, 2002 3:35 PM > > > To: Shahrier, Sharif M. > > > Cc: 'nsis@ietf.org' > > > Subject: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > I have a question for clarification. > > > > > > I think it was stated that NSIS should only be concerned with the > > > establishment of QoS after handoff. > > > > > > This is inconvienent with respect to IP-level QoS > > > negotiation, which ideally > > > should be done before handoff has taken place. > > > > > > QoS negotiation is in the current requirements draft. > > > > > > So, NSIS signaling protocol development should be concerned > > > with activity > > > before handoff occurs. > > > > > > Sharif. > > > > > > > > > > > > _______________________________________________ > > > 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 > > > > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Apr 5 12:24:35 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10708 for ; Fri, 5 Apr 2002 12:24:34 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA15648 for nsis-archive@odin.ietf.org; Fri, 5 Apr 2002 12:24:41 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA15468; Fri, 5 Apr 2002 12:20:01 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA15399 for ; Fri, 5 Apr 2002 12:19:56 -0500 (EST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10611; Fri, 5 Apr 2002 12:19:49 -0500 (EST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id JAA09381; Fri, 5 Apr 2002 09:19:22 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g35HJLj07698; Fri, 5 Apr 2002 09:19:21 -0800 X-mProtect: <200204051719> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdlaMFPH; Fri, 05 Apr 2002 09:19:19 PST Message-ID: <3CADDC97.70EFE709@iprg.nokia.com> Date: Fri, 05 Apr 2002 09:19:20 -0800 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: James Kempf CC: Gary Kenward , Hemant.Chaskar@nokia.com, nsis@ietf.org, seamoby@ietf.org Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. References: <9FBD322B7824D511B36900508BF93C9C01AA49C7@zcard031.ca.nortel.com> <3CADD85C.F8C8D50F@iprg.nokia.com> <012f01c1dcc4$5cf69850$7e6015ac@T23KEMPF> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit Hello Jim, James Kempf wrote: > There is an issue if CT fails. In that case, some kind of negotiation > after handover would be required. > > So, I'd say that some indication of CT failure is needed. > Yes, but this is between AR and MN. If CT fails, the AR should notify the MN to engage in context re-creation. My point was specific to signaling _beyond_ AR (i.e., upstream signaling) independent of failure/success of CT. Hope this is clearer.. -Rajeev > > As for CAR, I don't see the relevance for QoS negotiation, though it may > be useful for finding a new wireless medium. I also see it primarily for > intertechnology handover, or, at best, interprovider handover. > > jak > ----- Original Message ----- > From: "Rajeev Koodli" > To: "Gary Kenward" > Cc: ; ; > Sent: Friday, April 05, 2002 9:01 AM > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > Hello, > > > > well, if the issue is QoS establishment after handover, > > > > - CT is applicable for establishing QoS state at the AR > > - if further signaling is desired beyond the AR, NSIS may > > consider it. I don't see how _signaling_ for QoS establishment > > beyond AR is relevant for seamoby. > > > > CAR _discovery_ could exchange QoS capability as one of the > > parameters that might then be fed to a selection algorithm. Any > > signaling for actually establishing QoS itself beyond the AR > > should be outside the scope of seamoby.. > > > > Regards, > > > > -Rajeev > > > > > > Gary Kenward wrote: > > > > > > > > > > > Hemant: > > > > > > Just a point of clarification, but as I understand CARD (and > > > I don't understand it well), it is not a QoS negotiation > > > protocol. The main application that you are referring to primarily > > > arises out of a perceived need to determine at the MN the best link > > > layer to handover over to when inter-technology handovers are > > > involved. > > > It can be applied to intra-technology handovers, but the value in > > > that situation is highly questionable (e.g. since it is a discovery > > > protocol, the implication is that the purpose is to determine the > > > choice of channels available; for intra-technology handovers, there > > > are many, many reasons why this "choice" may not be available). > > > > > > There is a requirement, 5.1.2, which seems to imply NSIS > involvement > > > > > > during/after a handover. John has stated that this is not the > > > intention > > > (please correct me if I have this wrong John), in which case I think > > > 5.1.2 needs to be clarified. > > > > > > Specifically, is NSIS to be used to negotiated new QoS for an > > > existing flow after a handover, or is it specifically for > establishing > > > > > > QoS for a new flow? I don't think the answer is boolean: the role > > > of NSIS in QoS re-negotiation is still open, I believe, and clearly > > > handover is a dynamic situation that could cause the QoS provided to > > > change. > > > > > > I have been told there is no issue, but here's a frightening > > > scenario: > > > > > > - a handover takes place, and context transfer has been used > > > to > > > move the QoS context to the new routers (by the requirements > > > for > > > CT this could be intra-, or inter- technology. Some of us > > > believe > > > that for "seamless" handovers, the context will be available > at > > > > > > routers before the first packets need to be forwarded. This > > > implies > > > that there is a relationship, probabilistic perhaps, between > > > the handover process and the target ARs for CT. > > > > > > - CARD is used by the MN to influence the handover decision (it > > > is not clear to me how this happens, but it seems clear that > > > for a more "seamless" handover, the MN should chose an AR > that > > > has received the appropriate context; if not, then what? > > > > > > - NSIS kicks in and starts re-negotiating QoS because of > changes > > > introduced by the handover; > > > > > > How do these three protocols interact to produce predictable > > > outcomes? > > > Or, perhaps, the question is, how do the functional entities > > > associated > > > with the three protocols interact before, during and after a > handover? > > > > > > If it the interaction is within the functional entities, the > > > respective > > > wg's could declare the issue out of scope, but this approach does > not > > > sit well with me, for it seems to defer the problem to the people > who > > > have to implement this "stuff". > > > > > > Am I imagining things? > > > > > > Cheers, > > > Gary > > > > > > > -----Original Message----- > > > > From: Hemant.Chaskar@nokia.com [mailto:Hemant.Chaskar@nokia.com] > > > > Sent: April 4, 2002 22:33 > > > > To: nsis@ietf.org > > > > Subject: RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > Hi Sharif: > > > > > > > > There is currently a debate going on in Seamoby as to whether > > > > this QoS negotiation be covered by NSIS or Seamoby (CAR > > > > discovery protocol). > > > > > > > > IMHO it should be covered by CAR discovery and not NSIS. CAR > > > > discovery is supposed to identify candidate access routers > > > > for handoff and QoS is an important property for candidacy. > > > > > > > > Br, > > > > Hemant > > > > > > > > -----Original Message----- > > > > From: ext Shahrier, Sharif M. > > > > [mailto:Sharif.Shahrier@InterDigital.com] > > > > Sent: Thursday, April 04, 2002 3:35 PM > > > > To: Shahrier, Sharif M. > > > > Cc: 'nsis@ietf.org' > > > > Subject: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > > > > I have a question for clarification. > > > > > > > > I think it was stated that NSIS should only be concerned with the > > > > establishment of QoS after handoff. > > > > > > > > This is inconvienent with respect to IP-level QoS > > > > negotiation, which ideally > > > > should be done before handoff has taken place. > > > > > > > > QoS negotiation is in the current requirements draft. > > > > > > > > So, NSIS signaling protocol development should be concerned > > > > with activity > > > > before handoff occurs. > > > > > > > > Sharif. > > > > > > > > > > > > > > > > _______________________________________________ > > > > 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 > > > > > > > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Apr 5 12:29:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10883 for ; Fri, 5 Apr 2002 12:29:15 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA15916 for nsis-archive@odin.ietf.org; Fri, 5 Apr 2002 12:29:21 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA15747; Fri, 5 Apr 2002 12:25:27 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA15667 for ; Fri, 5 Apr 2002 12:25:19 -0500 (EST) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10768 for ; Fri, 5 Apr 2002 12:25:12 -0500 (EST) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g35HIfe01666; Fri, 5 Apr 2002 12:18:41 -0500 (EST) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 5 Apr 2002 12:18:41 -0500 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA49CD@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Alban.Couturier@alcatel.fr'" , Roland Bless Cc: "'brunner@ccrle.nec.de'" , "Geib, Ruediger" , svenvandenbosch@hotmail.com, nsis@ietf.org Subject: RE: pre-emption (was RE: [NSIS] proposals related to NSIS WG draf t) Date: Fri, 5 Apr 2002 12:18:07 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DCC5.DA45E9CC" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1DCC5.DA45E9CC Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Alban: I agree with most of what you have said, but really, it is not up the end system to determine whether it's traffic should pre-empt flows from other end systems. The decision to pre-empt can only be made by the network (ignoring the trivial case of an end-host = requesting pre-emption of it's own flows). At best, pre-emption is the result of a negotiation between a host = and the network. This does not have to be a dynamic negotiation: the = ability to pre-empt could be part of the agreed upon QoS (first class = passengers get to board and leave the airplane before other passengers). The = dynamic case can be treated as simply part of QoS negotiation.=20 I believe the only important question is whether there are special signalling requirements that can only be addressed by an explicit NSIS protocol semantics, rather then the identified requirement for NSIS to negotiate QoS. In an earlier email, I did ask for some explanation of these special = QoS=20 signalling semantics for pre-emption, and I am interested in hearing the rationale. Cheers, Gary > -----Original Message----- > From: Alban.Couturier@alcatel.fr [mailto:Alban.Couturier@alcatel.fr] > Sent: April 5, 2002 11:58 > To: Roland Bless > Cc: Kenward, Gary [WDLN2:AN10:EXCH]; 'brunner@ccrle.nec.de'; Geib, > Ruediger; svenvandenbosch@hotmail.com; nsis@ietf.org > Subject: Re: pre-emption (was RE: [NSIS] proposals related to NSIS WG > draft) >=20 >=20 >=20 >=20 > Roland Bless a =E9crit : > >=20 > > Hi Alban, > >=20 > > the question is: is it really required to signal the priority > > of a reservation? I think Gary just said that both priority > > and preemption can be determined by the provider policy. > > Otherwise end-users can always signal highest priority > > for their requests, so the provider has to decide when to preempt > > and what to preempt anyway. While a preemption mechanism for > > reservations is perfectly reasonable (e.g. for 911 or possibly > > for handovers), I currently don't see a real requirement or > > benefit to _signal_ reservation priority. This should rather > > be a (local) policy issue. >=20 > Hi Gary and Roland >=20 > My question is how can the provider know that a particular=20 > flow deserve > a higher priority when a user requests QoS?=20 > Sometimes a user want not to be prempted or really wants its=20 > request to > be satisfied because he calls his boss, or the police etc...=20 > Sometimes, > the same user wants a "regular" call or session, which=20 > implies that the > network may refuse it because there is in competition a call=20 > to 911 or a > session with a big boss. > So only the initiator could signal to the network that a session is > really more important than another. It's just a question of a > high/medium/normal tag in a request. The network could then=20 > accept this > priority, or not, depending on policy/user profile... In case=20 > of network > failure, the QoS controller could also react in order to=20 > reestablish the > high priority flows before the others. >=20 > The only other solution i see could be to put this priority=20 > information > in the service description. But again, this type of solution mixes > admission control performed by the QoS controller, and the=20 > provisionning > of QoS. This lead to difficulties in network provisionning,=20 > or/and to a > poor design in the QoS controller that will be QSC dependant. >=20 >=20 > Regards >=20 > > Regards, > > Roland > >=20 > > > > Gary Kenward a =E9crit : > > > > > > > > Interesting. Why would this not be a policy decision? > > > > > > I dont understand the trouble here. We are making=20 > signaling, which is > > > per se the interface to an admission control function. Admission > > > control's role is to reject (hopefully not too much)=20 > users who want to > > > consume concurrently the same resources (such as an EF). > > > The first feature we can add to a "rough" signaling, is=20 > priority. For > > > example, when I want to call 911, I want the same QoS=20 > than a normal > > > call, this is normal voice, but I prefer not to be rejected by = the > > > admission control. > > > > > > A way to implement priority is preemption. Which means to me to > > > interrupt the EF marking of already accepted flows, and=20 > notifying this > > > "normal" EF users they have no more the EF/voice quality. > > > There are other ways. For instance, an admission control=20 > can refuse > > > normal calls when some treshold is reached, and then only accept > > > priority calls. > > > > > > So I would conclude that preemption is not a requirement=20 > for NSIS, but > > > priority should be supported by nsis. > > > > > > > > > > > > > gary > > > > > > > > > -----Original Message----- > > > > > From: Marcus Brunner [mailto:brunner@ccrle.nec.de] > > > > > Sent: April 5, 2002 06:08 > > > > > To: Kenward, Gary [WDLN2:AN10:EXCH]; Geib, Ruediger; > > > > > svenvandenbosch@hotmail.com > > > > > Cc: nsis@ietf.org > > > > > Subject: RE: pre-emption (was RE: [NSIS] proposals=20 > related to NSIS > > > > WG > > > > > draf t) > > > > > > > > > > > > > > > We are not talking about priority of data traffic overothers, > > > > > but on the > > > > > case of the capacity already completly give away and a new > > > > > service request > > > > > arriving. One can then specify, whether it is=20 > possible to preempt > > > > > guaranteed reservations. > > > > > > > > > > I would like see whether this is worth a reqirement. > > > > > > > > > > Marcus > > > > > > > > > > --On Thursday, April 04, 2002 12:37 PM -0500 Gary Kenward > > > > > wrote: > > > > > > > > > > > > > > > > > I guess my main issue is that this "requirement"=20 > seems to embed > > > > > > definitions of flow treatment in the definition of=20 > the signalling > > > > > > protocol. This, to me, is simply the wrong thing to=20 > do, unless > > > > there > > > > > > is not clear reason why the two cannot be kept=20 > separate. I haven't > > > > > > > > > > heard this reason. > > > > > > > > > > > > BTW: the priority of a flow IS coupled to it's QoS=20 > requirements. > > > > > > As a counter example, what does an low priority EF=20 > flow mean? > > > > > > Could you support EF PHB for a flow if it had a "lower > > > > > priority" (where > > > > > > lower priority implies a higher liklihood of pre-emption of > > > > service) > > > > > > then an AF or BE flow within a router? The answer is, very > > > > > probably not. > > > > > > > > > > > > Let's not debate QoS definitions in NSIS. I think John has > > > > > stated that > > > > > > QoS definition is out of scope for NSIS, and declaring a > > > > > particular flow > > > > > > treatment such as priority as not being QoS doesn't help. > > > > > > > > > > > > Gary > > > > > > > > > > > >> -----Original Message----- > > > > > >> From: Marcus Brunner [mailto:brunner@ccrle.nec.de] > > > > > >> Sent: April 4, 2002 06:40 > > > > > >> To: Geib, Ruediger; svenvandenbosch@hotmail.com > > > > > >> Cc: nsis@ietf.org > > > > > >> Subject: pre-emption (was RE: [NSIS] proposals related to > > > > > >> NSIS WG draft) > > > > > >> > > > > > >> > > > > > >> As Ruediger I would like to hear some other=20 > opinions as well. > > > > > >> I think the > > > > > >> whole fault handling is an open issue anyway and = preempting > > > > > >> flows might > > > > > >> play a roll in fault handling as well. > > > > > >> > > > > > >> Marcus > > > > > >> > > > > > >> --On Tuesday, April 02, 2002 4:27 PM +0200 "Geib, = Ruediger" > > > > > >> wrote: > > > > > >> > > > > > >> > Hi Sven, > > > > > >> > > > > > > >> > the comment is a bit late, but I've been offline=20 > for a while. > > > > > >> > Nevertheless: > > > > > >> > > > > > > >> >> * New requirements > > > > > >> >> - in section MUST support priority > > > > > >> >> The priority of a flow is essentially decoupled from > > > > > >> >> its QoS requirements. Therefore the protocol MUST > > > > > >> >> support priority. As a consequence, it MUST support > > > > > >> >> preemption of traffic flows in case of congestion or > > > > > >> >> failure. A preemption action MAY trigger an attempt > > > > > >> >> to resetup the request by means of another instance > > > > > >> >> of an NSIS signaling protocol. > > > > > >> > > > > > > >> > Could you provide some clearer argumentation why > > > > > >> > preemption is a requirement? I'd classify preemption > > > > > >> > as a "nice to have" feature, no more than a "MAY" > > > > > >> > requirement. I'd especially insist on preemption being > > > > > >> > completely decoupled from QoS and any other service > > > > > >> > related signalling. > > > > > >> > I.e. if it is not supported by an opperator, no > > > > > >> > parameters or messages related to preemption are > > > > > >> > to be transported. > > > > > >> > > > > > > >> > I'd like to ask other representatives of operators for > > > > > >> > their view. > > > > > >> > > > > > > >> > Regards, R=FCdiger > > > > > >> > > > > > > >> > _______________________________________________ > > > > > >> > nsis mailing list > > > > > >> > nsis@ietf.org > > > > > >> > https://www1.ietf.org/mailman/listinfo/nsis > > > > > >> > > > > > >> > > > > > >> > > > > > >> -------------------------------------- > > > > > >> Dr. Marcus Brunner > > > > > >> Network Laboratories > > > > > >> NEC Europe Ltd. > > > > > >> > > > > > >> E-Mail: brunner@ccrle.nec.de > > > > > >> WWW: http://www.ccrle.nec.de/ > > > > > >> personal home page: http://www.brubers.org/marcus > > > > > >> > > > > > >> > > > > > >> > > > > > >> _______________________________________________ > > > > > >> nsis mailing list > > > > > >> nsis@ietf.org > > > > > >> https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > > > > > > > > > > > -------------------------------------- > > > > > Dr. Marcus Brunner > > > > > Network Laboratories > > > > > NEC Europe Ltd. > > > > > > > > > > E-Mail: brunner@ccrle.nec.de > > > > > WWW: http://www.ccrle.nec.de/ > > > > > personal home page: http://www.brubers.org/marcus > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > nsis mailing list > > > > > nsis@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > > -- > > > Alban Couturier > > >=20 > --------------------------------------------------------------------- > > > Alcatel Research and Innovation > > > Ets de Marcoussis R&I/ULC > > > Route de Nozay =20 > mailto:Alban.Couturier@alcatel.fr > > > F-91461 Marcoussis CEDEX tel: +33 1=20 > 69 63 11 97 > > >=20 > --------------------------------------------------------------------- > > > > > > _______________________________________________ > > > nsis mailing list > > > nsis@ietf.org > > > https://www1.ietf.org/mailman/listinfo/nsis > >=20 > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis >=20 > --=20 > Alban Couturier > --------------------------------------------------------------------- > Alcatel Research and Innovation > Ets de Marcoussis R&I/ULC > Route de Nozay mailto:Alban.Couturier@alcatel.fr > F-91461 Marcoussis CEDEX tel: +33 1 69 63 11 97 > --------------------------------------------------------------------- >=20 ------_=_NextPart_001_01C1DCC5.DA45E9CC Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: pre-emption (was RE: [NSIS] proposals related to NSIS WG = draft)

Alban:

  I agree with most of what you have said, but = really, it is not up
the end system to determine whether it's traffic = should pre-empt flows
from other end systems. The decision to pre-empt can = only be
made by the network (ignoring the trivial case of an = end-host requesting
pre-emption of it's own flows).

  At best, pre-emption is the result of a = negotiation between a host and
the network. This does not have to be a dynamic = negotiation: the ability
to pre-empt could be part of the agreed upon QoS = (first class passengers
get to board and leave the airplane before other = passengers). The dynamic
case can be treated as simply part of QoS = negotiation.

I believe the only important question is whether = there are special signalling
requirements that can only be addressed by an = explicit NSIS protocol semantics,
rather then the identified requirement for NSIS to = negotiate QoS.

In an earlier email, I did ask for some explanation = of these special QoS
signalling semantics for pre-emption, and I am = interested in hearing
the rationale.

Cheers,
Gary


> -----Original Message-----
> From: Alban.Couturier@alcatel.fr [mailto:Alban.Couturier@alcate= l.fr]
> Sent: April 5, 2002 11:58
> To: Roland Bless
> Cc: Kenward, Gary [WDLN2:AN10:EXCH]; = 'brunner@ccrle.nec.de'; Geib,
> Ruediger; svenvandenbosch@hotmail.com; = nsis@ietf.org
> Subject: Re: pre-emption (was RE: [NSIS] = proposals related to NSIS WG
> draft)
>
>
>
>
> Roland Bless a =E9crit :
> >
> > Hi Alban,
> >
> > the question is: is it really required to = signal the priority
> > of a reservation? I think Gary just said = that both priority
> > and preemption can be determined by the = provider policy.
> > Otherwise end-users can always signal = highest priority
> > for their requests, so the provider has to = decide when to preempt
> > and what to preempt anyway. While a = preemption mechanism for
> > reservations is perfectly reasonable (e.g. = for 911 or possibly
> > for handovers), I currently don't see a = real requirement or
> > benefit to _signal_ reservation  = priority. This should rather
> > be a (local) policy issue.
>
> Hi Gary and Roland
>
> My question is  how can the provider know = that a particular
> flow deserve
> a higher priority when a user requests QoS? =
> Sometimes a user want not to be prempted or = really wants its
> request to
> be satisfied because he calls his boss, or the = police etc...
> Sometimes,
> the same user wants a "regular" call = or session, which
> implies that the
> network may refuse it because there is in = competition a call
> to 911 or a
> session with a big boss.
> So only the initiator could signal to the = network that a session is
> really more important than another. It's just a = question of a
> high/medium/normal tag in a request. The = network could then
> accept this
> priority, or not, depending on policy/user = profile... In case
> of network
> failure, the QoS controller could also react in = order to
> reestablish the
> high priority flows before the others.
>
> The only other solution i see could be to put = this priority
> information
> in the service description. But again, this = type of solution mixes
> admission control performed by the QoS = controller, and the
> provisionning
> of QoS. This lead to difficulties in network = provisionning,
> or/and to a
> poor design in the QoS controller that will be = QSC dependant.
>
>
> Regards
>
> > Regards,
> >  Roland
> >
> > > > Gary Kenward a =E9crit :
> > > >
> > > > Interesting. Why would this not = be a policy decision?
> > >
> > > I dont understand the trouble here. = We are making
> signaling, which is
> > > per se the interface to an admission = control function. Admission
> > > control's role is to reject = (hopefully not too much)
> users who want to
> > > consume concurrently the same = resources (such as an EF).
> > > The first feature we can add to a = "rough" signaling, is
> priority. For
> > > example, when I want to call 911, I = want the same QoS
> than a normal
> > > call, this is normal voice, but I = prefer not to be rejected by the
> > > admission control.
> > >
> > > A way to implement priority is = preemption. Which  means to me to
> > > interrupt the EF marking of already = accepted flows, and
> notifying this
> > > "normal" EF users they have = no more the EF/voice quality.
> > > There are other ways. For instance, = an admission control
> can refuse
> > > normal calls when some treshold is = reached, and then only accept
> > > priority calls.
> > >
> > > So I would conclude that preemption = is not a requirement
> for NSIS, but
> > > priority should be supported by = nsis.
> > >
> > >
> > >
> > > > gary
> > > >
> > > > > -----Original = Message-----
> > > > > From: Marcus Brunner [mailto:brunner@ccrle.nec.de]
> > > > > Sent: April 5, 2002 = 06:08
> > > > > To: Kenward, Gary = [WDLN2:AN10:EXCH]; Geib, Ruediger;
> > > > > = svenvandenbosch@hotmail.com
> > > > > Cc: nsis@ietf.org
> > > > > Subject: RE: pre-emption = (was RE: [NSIS] proposals
> related to NSIS
> > > > WG
> > > > > draf t)
> > > > >
> > > > >
> > > > > We are not talking about = priority of data traffic overothers,
> > > > > but on the
> > > > > case of the capacity = already completly give away and a new
> > > > > service request
> > > > > arriving. One can then = specify, whether it is
> possible to preempt
> > > > > guaranteed = reservations.
> > > > >
> > > > > I would like see whether = this is worth a reqirement.
> > > > >
> > > > > Marcus
> > > > >
> > > > > --On Thursday, April 04, = 2002 12:37 PM -0500 Gary Kenward
> > > > > = <gkenward@nortelnetworks.com> wrote:
> > > > >
> > > > > >
> > > > > > I guess my main issue = is that this "requirement"
> seems to embed
> > > > > > definitions of flow = treatment in the definition of
> the signalling
> > > > > > protocol. This, to me, = is simply the wrong thing to
> do, unless
> > > > there
> > > > > > is not clear reason = why the two cannot be kept
> separate. I haven't
> > > >
> > > > > > heard this = reason.
> > > > > >
> > > > > > BTW: the priority of a = flow IS coupled to it's QoS
> requirements.
> > > > > > As a counter example, = what does an low priority EF
> flow mean?
> > > > > > Could you support EF = PHB for a flow if it had a "lower
> > > > > priority" = (where
> > > > > > lower priority implies = a higher liklihood of pre-emption of
> > > > service)
> > > > > > then an AF or BE flow = within a router? The answer is, very
> > > > > probably not.
> > > > > >
> > > > > > Let's not debate QoS = definitions in NSIS. I think John has
> > > > > stated that
> > > > > > QoS definition is out = of scope for NSIS, and declaring a
> > > > > particular flow
> > > > > > treatment such as = priority as not being QoS doesn't help.
> > > > > >
> > > > > > Gary
> > > > > >
> > > > > >> -----Original = Message-----
> > > > > >> From: Marcus = Brunner [mailto:brunner@ccrle.nec.de]
> > > > > >> Sent: April 4, = 2002 06:40
> > > > > >> To: Geib, = Ruediger; svenvandenbosch@hotmail.com
> > > > > >> Cc: = nsis@ietf.org
> > > > > >> Subject: = pre-emption (was RE: [NSIS] proposals related to
> > > > > >> NSIS WG = draft)
> > > > > >>
> > > > > >>
> > > > > >> As Ruediger I = would like to hear some other
> opinions as well.
> > > > > >> I think the
> > > > > >> whole fault = handling is an open issue anyway and preempting
> > > > > >> flows might
> > > > > >> play a roll in = fault handling as well.
> > > > > >>
> > > > > >> Marcus
> > > > > >>
> > > > > >> --On Tuesday, = April 02, 2002 4:27 PM +0200 "Geib, Ruediger"
> > > > > >> = <Ruediger.Geib@t-systems.com> wrote:
> > > > > >>
> > > > > >> > Hi = Sven,
> > > > > >> >
> > > > > >> > the comment = is a bit late, but I've been offline
> for a while.
> > > > > >> > = Nevertheless:
> > > > > >> >
> > > > > >> >> * New = requirements
> > > > > >> >> - in = section MUST support priority
> > > > > >> = >>   The priority of a flow is essentially decoupled = from
> > > > > >> = >>   its QoS requirements. Therefore the protocol = MUST
> > > > > >> = >>   support priority. As a consequence, it MUST = support
> > > > > >> = >>   preemption of traffic flows in case of congestion = or
> > > > > >> = >>   failure. A preemption action MAY trigger an = attempt
> > > > > >> = >>   to resetup the request by means of another = instance
> > > > > >> = >>   of an NSIS signaling protocol.
> > > > > >> >
> > > > > >> > Could you = provide some clearer argumentation why
> > > > > >> > preemption is = a requirement? I'd classify preemption
> > > > > >> > as a = "nice to have" feature, no more than a "MAY"
> > > > > >> > requirement. = I'd especially insist on preemption being
> > > > > >> > completely = decoupled from QoS and any other service
> > > > > >> > related = signalling.
> > > > > >> > I.e. if it is = not supported by an opperator, no
> > > > > >> > parameters or = messages related to preemption are
> > > > > >> > to be = transported.
> > > > > >> >
> > > > > >> > I'd like to = ask other representatives of operators for
> > > > > >> > their = view.
> > > > > >> >
> > > > > >> > Regards, = R=FCdiger
> > > > > >> >
> > > > > >> > = _______________________________________________
> > > > > >> > nsis mailing = list
> > > > > >> > = nsis@ietf.org
> > > > > >> > https://www1.ietf.org/mailman/listinfo/nsis=
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >> = --------------------------------------
> > > > > >> Dr. Marcus = Brunner
> > > > > >> Network = Laboratories
> > > > > >> NEC Europe = Ltd.
> > > > > >>
> > > > > >> E-Mail: = brunner@ccrle.nec.de
> > > > > >> = WWW:    http://www.ccrle.nec.de/
> > > > > >> personal home = page: http://www.brubers.org/marcus
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >> = _______________________________________________
> > > > > >> nsis mailing = list
> > > > > >> = nsis@ietf.org
> > > > > >> https://www1.ietf.org/mailman/listinfo/nsis=
> > > > >
> > > > >
> > > > >
> > > > > = --------------------------------------
> > > > > Dr. Marcus Brunner
> > > > > Network Laboratories
> > > > > NEC Europe Ltd.
> > > > >
> > > > > E-Mail: = brunner@ccrle.nec.de
> > > > > WWW:    http://www.ccrle.nec.de/
> > > > > personal home page: http://www.brubers.org/marcus
> > > > >
> > > > >
> > > > >
> > > > > = _______________________________________________
> > > > > nsis mailing list
> > > > > nsis@ietf.org
> > > > > https://www1.ietf.org/mailman/listinfo/nsis=
> > > > >
> > >
> > > --
> > > Alban Couturier
> > >
> = ---------------------------------------------------------------------
> > > Alcatel Research and = Innovation
> > > Ets de Marcoussis R&I/ULC
> > > Route de = Nozay           &= nbsp;         
> mailto:Alban.Couturier@alcate= l.fr
> > > F-91461 Marcoussis = CEDEX           &= nbsp;           tel: = +33 1
> 69 63 11 97
> > >
> = ---------------------------------------------------------------------
> > >
> > > = _______________________________________________
> > > 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=
>
> --
> Alban Couturier
> = ---------------------------------------------------------------------
> Alcatel Research and Innovation
> Ets de Marcoussis R&I/ULC
> Route de = Nozay           &= nbsp;          mailto:Alban.Couturier@alcate= l.fr
> F-91461 Marcoussis = CEDEX           &= nbsp;           tel: = +33 1 69 63 11 97
> = ---------------------------------------------------------------------
>

------_=_NextPart_001_01C1DCC5.DA45E9CC-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Apr 5 12:38:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11170 for ; Fri, 5 Apr 2002 12:38:30 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA16821 for nsis-archive@odin.ietf.org; Fri, 5 Apr 2002 12:38:34 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA16164; Fri, 5 Apr 2002 12:30:28 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA16060 for ; Fri, 5 Apr 2002 12:30:20 -0500 (EST) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10907; Fri, 5 Apr 2002 12:30:12 -0500 (EST) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g35HPHe02097; Fri, 5 Apr 2002 12:25:17 -0500 (EST) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 5 Apr 2002 12:25:17 -0500 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA49CE@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'James Kempf'" , Rajeev Koodli Cc: Hemant.Chaskar@nokia.com, nsis@ietf.org, seamoby@ietf.org Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Fri, 5 Apr 2002 12:25:11 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DCC6.D6D9082C" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1DCC6.D6D9082C Content-Type: text/plain; charset="iso-8859-1" Rajeev, James: This is how I see it also. I think that some work is required to identify the conditions under which each protocol is invoked. E.g. NSIS is not invoked with every handover, but is certainly there to be invoked if CT fails, or if there is a QoS disruption for whatever reason. Thanks. Gary > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: April 5, 2002 12:07 > To: Rajeev Koodli; Kenward, Gary [WDLN2:AN10:EXCH] > Cc: Hemant.Chaskar@nokia.com; nsis@ietf.org; seamoby@ietf.org > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > There is an issue if CT fails. In that case, some kind of negotiation > after handover would be required. > > So, I'd say that some indication of CT failure is needed. > > As for CAR, I don't see the relevance for QoS negotiation, > though it may > be useful for finding a new wireless medium. I also see it > primarily for > intertechnology handover, or, at best, interprovider handover. > > jak > ----- Original Message ----- > From: "Rajeev Koodli" > To: "Gary Kenward" > Cc: ; ; > Sent: Friday, April 05, 2002 9:01 AM > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > Hello, > > > > well, if the issue is QoS establishment after handover, > > > > - CT is applicable for establishing QoS state at the AR > > - if further signaling is desired beyond the AR, NSIS may > > consider it. I don't see how _signaling_ for QoS establishment > > beyond AR is relevant for seamoby. > > > > CAR _discovery_ could exchange QoS capability as one of the > > parameters that might then be fed to a selection algorithm. Any > > signaling for actually establishing QoS itself beyond the AR > > should be outside the scope of seamoby.. > > > > Regards, > > > > -Rajeev > > > > > > Gary Kenward wrote: > > > > > > > > > > > Hemant: > > > > > > Just a point of clarification, but as I understand CARD (and > > > I don't understand it well), it is not a QoS negotiation > > > protocol. The main application that you are referring to primarily > > > arises out of a perceived need to determine at the MN the > best link > > > layer to handover over to when inter-technology handovers are > > > involved. > > > It can be applied to intra-technology handovers, but the value in > > > that situation is highly questionable (e.g. since it is a > discovery > > > protocol, the implication is that the purpose is to determine the > > > choice of channels available; for intra-technology > handovers, there > > > are many, many reasons why this "choice" may not be available). > > > > > > There is a requirement, 5.1.2, which seems to imply NSIS > involvement > > > > > > during/after a handover. John has stated that this is not the > > > intention > > > (please correct me if I have this wrong John), in which > case I think > > > 5.1.2 needs to be clarified. > > > > > > Specifically, is NSIS to be used to negotiated new QoS for an > > > existing flow after a handover, or is it specifically for > establishing > > > > > > QoS for a new flow? I don't think the answer is boolean: the role > > > of NSIS in QoS re-negotiation is still open, I believe, > and clearly > > > handover is a dynamic situation that could cause the QoS > provided to > > > change. > > > > > > I have been told there is no issue, but here's a frightening > > > scenario: > > > > > > - a handover takes place, and context transfer > has been used > > > to > > > move the QoS context to the new routers (by the > requirements > > > for > > > CT this could be intra-, or inter- technology. Some of us > > > believe > > > that for "seamless" handovers, the context will be > available > at > > > > > > routers before the first packets need to be forwarded. This > > > implies > > > that there is a relationship, probabilistic > perhaps, between > > > the handover process and the target ARs for CT. > > > > > > - CARD is used by the MN to influence the handover > decision (it > > > is not clear to me how this happens, but it seems > clear that > > > for a more "seamless" handover, the MN should chose an AR > that > > > has received the appropriate context; if not, then what? > > > > > > - NSIS kicks in and starts re-negotiating QoS because of > changes > > > introduced by the handover; > > > > > > How do these three protocols interact to produce predictable > > > outcomes? > > > Or, perhaps, the question is, how do the functional entities > > > associated > > > with the three protocols interact before, during and after a > handover? > > > > > > If it the interaction is within the functional entities, the > > > respective > > > wg's could declare the issue out of scope, but this approach does > not > > > sit well with me, for it seems to defer the problem to the people > who > > > have to implement this "stuff". > > > > > > Am I imagining things? > > > > > > Cheers, > > > Gary > > > > > > > -----Original Message----- > > > > From: Hemant.Chaskar@nokia.com [mailto:Hemant.Chaskar@nokia.com] > > > > Sent: April 4, 2002 22:33 > > > > To: nsis@ietf.org > > > > Subject: RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > Hi Sharif: > > > > > > > > There is currently a debate going on in Seamoby as to whether > > > > this QoS negotiation be covered by NSIS or Seamoby (CAR > > > > discovery protocol). > > > > > > > > IMHO it should be covered by CAR discovery and not NSIS. CAR > > > > discovery is supposed to identify candidate access routers > > > > for handoff and QoS is an important property for candidacy. > > > > > > > > Br, > > > > Hemant > > > > > > > > -----Original Message----- > > > > From: ext Shahrier, Sharif M. > > > > [mailto:Sharif.Shahrier@InterDigital.com] > > > > Sent: Thursday, April 04, 2002 3:35 PM > > > > To: Shahrier, Sharif M. > > > > Cc: 'nsis@ietf.org' > > > > Subject: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > > > > I have a question for clarification. > > > > > > > > I think it was stated that NSIS should only be > concerned with the > > > > establishment of QoS after handoff. > > > > > > > > This is inconvienent with respect to IP-level QoS > > > > negotiation, which ideally > > > > should be done before handoff has taken place. > > > > > > > > QoS negotiation is in the current requirements draft. > > > > > > > > So, NSIS signaling protocol development should be concerned > > > > with activity > > > > before handoff occurs. > > > > > > > > Sharif. > > > > > > > > > > > > > > > > _______________________________________________ > > > > 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 > > > > > > > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > ------_=_NextPart_001_01C1DCC6.D6D9082C Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff.

Rajeev, James:

  This is how I see it also. I think that some work
is required to identify the conditions under which each
protocol is invoked. E.g. NSIS is not invoked with every
handover, but is certainly there to be invoked if CT
fails, or if there is a QoS disruption for whatever reason.

Thanks.
Gary

> -----Original Message-----
> From: James Kempf [mailto:kempf@docomolabs-usa.com]
> Sent: April 5, 2002 12:07
> To: Rajeev Koodli; Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: Hemant.Chaskar@nokia.com; nsis@ietf.org; seamoby@ietf.org
> Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff.
>
>
> There is an issue if CT fails. In that case, some kind of negotiation
> after handover would be required.
>
> So, I'd say that some indication of CT failure is needed.
>
> As for CAR, I don't see the relevance for QoS negotiation,
> though it may
> be useful for finding a new wireless medium. I also see it
> primarily for
> intertechnology handover, or, at best, interprovider handover.
>
>             jak
> ----- Original Message -----
> From: "Rajeev Koodli" <rajeev@iprg.nokia.com>
> To: "Gary Kenward" <gkenward@nortelnetworks.com>
> Cc: <Hemant.Chaskar@nokia.com>; <nsis@ietf.org>; <seamoby@ietf.org>
> Sent: Friday, April 05, 2002 9:01 AM
> Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff.
>
>
> >
> > Hello,
> >
> > well, if the issue is QoS establishment after handover,
> >
> > - CT is applicable for establishing QoS state at the AR
> > - if further signaling is desired beyond the AR, NSIS may
> >     consider it. I don't see how _signaling_ for QoS establishment
> >     beyond AR is relevant for seamoby.
> >
> > CAR _discovery_ could exchange QoS capability as one of the
> > parameters that might then be fed to a selection algorithm. Any
> > signaling for actually establishing QoS itself beyond the AR
> > should be outside the scope of seamoby..
> >
> > Regards,
> >
> > -Rajeev
> >
> >
> > Gary Kenward wrote:
> >
> > >
> > >
> > > Hemant:
> > >
> > >   Just a point of clarification, but as I understand CARD (and
> > > I don't understand it well), it is not a QoS negotiation
> > > protocol. The main application that you are referring to primarily
> > > arises out of a perceived need to determine at the MN the
> best link
> > > layer to handover over to when inter-technology handovers are
> > > involved.
> > > It can be applied to intra-technology handovers, but the value in
> > > that situation is highly questionable (e.g. since it is a
> discovery
> > > protocol, the implication is that the purpose is to determine the
> > > choice of channels available; for intra-technology
> handovers, there
> > > are many, many reasons why this "choice" may not be available).
> > >
> > >   There is a requirement, 5.1.2, which seems to imply NSIS
> involvement
> > >
> > > during/after a handover. John has stated that this is not the
> > > intention
> > > (please correct me if I have this wrong John), in which
> case I think
> > > 5.1.2 needs to be clarified.
> > >
> > >   Specifically, is NSIS to be used to negotiated new QoS for an
> > > existing flow after a handover, or is it specifically for
> establishing
> > >
> > > QoS for a new flow? I don't think the answer is boolean: the role
> > > of NSIS in QoS re-negotiation is still open, I believe,
> and clearly
> > > handover is a dynamic situation that could cause the QoS
> provided to
> > > change.
> > >
> > >   I have been told there is no issue, but here's a frightening
> > > scenario:
> > >
> > >         - a handover takes place, and context transfer
> has been used
> > > to
> > >        move the QoS context to the new routers (by the
> requirements
> > > for
> > >        CT this could be intra-, or inter- technology. Some of us
> > > believe
> > >        that for "seamless" handovers, the context will be
> available
> at
> > >
> > >        routers before the first packets need to be forwarded. This
> > > implies
> > >        that there is a relationship, probabilistic
> perhaps, between
> > >        the handover process and the target ARs for CT.
> > >
> > >      - CARD is used by the MN to influence the handover
> decision (it
> > >        is not clear to me how this happens, but it seems
> clear that
> > >        for a more "seamless" handover, the MN should chose an AR
> that
> > >        has received the appropriate context; if not, then what?
> > >
> > >      - NSIS kicks in and starts re-negotiating QoS because of
> changes
> > >        introduced by the handover;
> > >
> > >   How do these three protocols interact to produce predictable
> > > outcomes?
> > > Or, perhaps, the question is, how do the functional entities
> > > associated
> > > with the three protocols interact before, during and after a
> handover?
> > >
> > > If it the interaction is within the functional entities, the
> > > respective
> > > wg's could declare the issue out of scope, but this approach does
> not
> > > sit well with me, for it seems to defer the problem to the people
> who
> > > have to implement this "stuff".
> > >
> > >   Am I imagining things?
> > >
> > > Cheers,
> > > Gary
> > >
> > > > -----Original Message-----
> > > > From: Hemant.Chaskar@nokia.com [mailto:Hemant.Chaskar@nokia.com]
> > > > Sent: April 4, 2002 22:33
> > > > To: nsis@ietf.org
> > > > Subject: RE: [NSIS] Establishing QoS after handoff.
> > > >
> > > >
> > > > Hi Sharif:
> > > >
> > > > There is currently a debate going on in Seamoby as to whether
> > > > this QoS negotiation be covered by NSIS or Seamoby (CAR
> > > > discovery protocol).
> > > >
> > > > IMHO it should be covered by CAR discovery and not NSIS. CAR
> > > > discovery is supposed to identify candidate access routers
> > > > for handoff and QoS is an important property for candidacy.
> > > >
> > > > Br,
> > > > Hemant
> > > >
> > > > -----Original Message-----
> > > > From: ext Shahrier, Sharif M.
> > > > [mailto:Sharif.Shahrier@InterDigital.com]
> > > > Sent: Thursday, April 04, 2002 3:35 PM
> > > > To: Shahrier, Sharif M.
> > > > Cc: 'nsis@ietf.org'
> > > > Subject: [NSIS] Establishing QoS after handoff.
> > > >
> > > >
> > > >
> > > > I have a question for clarification.
> > > >
> > > > I think it was stated that NSIS should only be
> concerned with the
> > > > establishment of QoS after handoff.
> > > >
> > > > This is inconvienent with respect to IP-level QoS
> > > > negotiation, which ideally
> > > > should be done before handoff has taken place.
> > > >
> > > > QoS negotiation is in the current requirements draft.
> > > >
> > > > So, NSIS signaling protocol development should be concerned
> > > > with activity
> > > > before handoff occurs.
> > > >
> > > > Sharif.
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > 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
> > > >
> >
> >
> > _______________________________________________
> > Seamoby mailing list
> > Seamoby@ietf.org
> > https://www1.ietf.org/mailman/listinfo/seamoby
> >
>
>

------_=_NextPart_001_01C1DCC6.D6D9082C-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Apr 5 12:43:23 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11304 for ; Fri, 5 Apr 2002 12:43:23 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA17087 for nsis-archive@odin.ietf.org; Fri, 5 Apr 2002 12:43:27 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA17016; Fri, 5 Apr 2002 12:41:55 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA16902 for ; Fri, 5 Apr 2002 12:41:47 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11248; Fri, 5 Apr 2002 12:41:42 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g35HenI01102; Fri, 5 Apr 2002 09:40:49 -0800 (PST) Message-ID: <016801c1dcc8$ccdadd30$7e6015ac@T23KEMPF> From: "James Kempf" To: "Rajeev Koodli" Cc: "Gary Kenward" , , , References: <9FBD322B7824D511B36900508BF93C9C01AA49C7@zcard031.ca.nortel.com> <3CADD85C.F8C8D50F@iprg.nokia.com> <012f01c1dcc4$5cf69850$7e6015ac@T23KEMPF> <3CADDC97.70EFE709@iprg.nokia.com> Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Fri, 5 Apr 2002 09:39:12 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit Rajeev, I agree, but there is still an issue of how the AR would notify the MN if CT fails. Is this covered by CT or not? jak ----- Original Message ----- From: "Rajeev Koodli" To: "James Kempf" Cc: "Gary Kenward" ; ; ; Sent: Friday, April 05, 2002 9:19 AM Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > Hello Jim, > > James Kempf wrote: > > > There is an issue if CT fails. In that case, some kind of negotiation > > after handover would be required. > > > > So, I'd say that some indication of CT failure is needed. > > > > Yes, but this is between AR and MN. If CT fails, the AR should > notify the MN to engage in context re-creation. > > My point was specific to signaling _beyond_ AR (i.e., upstream signaling) > independent of failure/success of CT. > > Hope this is clearer.. > > -Rajeev > > > > > > As for CAR, I don't see the relevance for QoS negotiation, though it may > > be useful for finding a new wireless medium. I also see it primarily for > > intertechnology handover, or, at best, interprovider handover. > > > > jak > > ----- Original Message ----- > > From: "Rajeev Koodli" > > To: "Gary Kenward" > > Cc: ; ; > > Sent: Friday, April 05, 2002 9:01 AM > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > > > Hello, > > > > > > well, if the issue is QoS establishment after handover, > > > > > > - CT is applicable for establishing QoS state at the AR > > > - if further signaling is desired beyond the AR, NSIS may > > > consider it. I don't see how _signaling_ for QoS establishment > > > beyond AR is relevant for seamoby. > > > > > > CAR _discovery_ could exchange QoS capability as one of the > > > parameters that might then be fed to a selection algorithm. Any > > > signaling for actually establishing QoS itself beyond the AR > > > should be outside the scope of seamoby.. > > > > > > Regards, > > > > > > -Rajeev > > > > > > > > > Gary Kenward wrote: > > > > > > > > > > > > > > > Hemant: > > > > > > > > Just a point of clarification, but as I understand CARD (and > > > > I don't understand it well), it is not a QoS negotiation > > > > protocol. The main application that you are referring to primarily > > > > arises out of a perceived need to determine at the MN the best link > > > > layer to handover over to when inter-technology handovers are > > > > involved. > > > > It can be applied to intra-technology handovers, but the value in > > > > that situation is highly questionable (e.g. since it is a discovery > > > > protocol, the implication is that the purpose is to determine the > > > > choice of channels available; for intra-technology handovers, there > > > > are many, many reasons why this "choice" may not be available). > > > > > > > > There is a requirement, 5.1.2, which seems to imply NSIS > > involvement > > > > > > > > during/after a handover. John has stated that this is not the > > > > intention > > > > (please correct me if I have this wrong John), in which case I think > > > > 5.1.2 needs to be clarified. > > > > > > > > Specifically, is NSIS to be used to negotiated new QoS for an > > > > existing flow after a handover, or is it specifically for > > establishing > > > > > > > > QoS for a new flow? I don't think the answer is boolean: the role > > > > of NSIS in QoS re-negotiation is still open, I believe, and clearly > > > > handover is a dynamic situation that could cause the QoS provided to > > > > change. > > > > > > > > I have been told there is no issue, but here's a frightening > > > > scenario: > > > > > > > > - a handover takes place, and context transfer has been used > > > > to > > > > move the QoS context to the new routers (by the requirements > > > > for > > > > CT this could be intra-, or inter- technology. Some of us > > > > believe > > > > that for "seamless" handovers, the context will be available > > at > > > > > > > > routers before the first packets need to be forwarded. This > > > > implies > > > > that there is a relationship, probabilistic perhaps, between > > > > the handover process and the target ARs for CT. > > > > > > > > - CARD is used by the MN to influence the handover decision (it > > > > is not clear to me how this happens, but it seems clear that > > > > for a more "seamless" handover, the MN should chose an AR > > that > > > > has received the appropriate context; if not, then what? > > > > > > > > - NSIS kicks in and starts re-negotiating QoS because of > > changes > > > > introduced by the handover; > > > > > > > > How do these three protocols interact to produce predictable > > > > outcomes? > > > > Or, perhaps, the question is, how do the functional entities > > > > associated > > > > with the three protocols interact before, during and after a > > handover? > > > > > > > > If it the interaction is within the functional entities, the > > > > respective > > > > wg's could declare the issue out of scope, but this approach does > > not > > > > sit well with me, for it seems to defer the problem to the people > > who > > > > have to implement this "stuff". > > > > > > > > Am I imagining things? > > > > > > > > Cheers, > > > > Gary > > > > > > > > > -----Original Message----- > > > > > From: Hemant.Chaskar@nokia.com [mailto:Hemant.Chaskar@nokia.com] > > > > > Sent: April 4, 2002 22:33 > > > > > To: nsis@ietf.org > > > > > Subject: RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > > > Hi Sharif: > > > > > > > > > > There is currently a debate going on in Seamoby as to whether > > > > > this QoS negotiation be covered by NSIS or Seamoby (CAR > > > > > discovery protocol). > > > > > > > > > > IMHO it should be covered by CAR discovery and not NSIS. CAR > > > > > discovery is supposed to identify candidate access routers > > > > > for handoff and QoS is an important property for candidacy. > > > > > > > > > > Br, > > > > > Hemant > > > > > > > > > > -----Original Message----- > > > > > From: ext Shahrier, Sharif M. > > > > > [mailto:Sharif.Shahrier@InterDigital.com] > > > > > Sent: Thursday, April 04, 2002 3:35 PM > > > > > To: Shahrier, Sharif M. > > > > > Cc: 'nsis@ietf.org' > > > > > Subject: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > > > > > > > > I have a question for clarification. > > > > > > > > > > I think it was stated that NSIS should only be concerned with the > > > > > establishment of QoS after handoff. > > > > > > > > > > This is inconvienent with respect to IP-level QoS > > > > > negotiation, which ideally > > > > > should be done before handoff has taken place. > > > > > > > > > > QoS negotiation is in the current requirements draft. > > > > > > > > > > So, NSIS signaling protocol development should be concerned > > > > > with activity > > > > > before handoff occurs. > > > > > > > > > > Sharif. > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > 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 > > > > > > > > > > > > > > _______________________________________________ > > > Seamoby mailing list > > > Seamoby@ietf.org > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Apr 5 13:08:48 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11812 for ; Fri, 5 Apr 2002 13:08:48 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA18564 for nsis-archive@odin.ietf.org; Fri, 5 Apr 2002 13:08:50 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA18311; Fri, 5 Apr 2002 13:03:32 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA18275 for ; Fri, 5 Apr 2002 13:03:29 -0500 (EST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11760; Fri, 5 Apr 2002 13:03:26 -0500 (EST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA11513; Fri, 5 Apr 2002 10:02:57 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g35I2t827551; Fri, 5 Apr 2002 10:02:55 -0800 X-mProtect: <200204051802> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdxeowcx; Fri, 05 Apr 2002 10:02:54 PST Message-ID: <3CADE6CE.DD37DEDB@iprg.nokia.com> Date: Fri, 05 Apr 2002 10:02:54 -0800 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: James Kempf CC: Gary Kenward , Hemant.Chaskar@nokia.com, nsis@ietf.org, seamoby@ietf.org Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. References: <9FBD322B7824D511B36900508BF93C9C01AA49C7@zcard031.ca.nortel.com> <3CADD85C.F8C8D50F@iprg.nokia.com> <012f01c1dcc4$5cf69850$7e6015ac@T23KEMPF> <3CADDC97.70EFE709@iprg.nokia.com> <016801c1dcc8$ccdadd30$7e6015ac@T23KEMPF> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit James Kempf wrote: > Rajeev, > > I agree, but there is still an issue of how the AR would notify the MN > if CT fails. Is this covered by CT or not? > This notification should be covered by CT. We should offer seamless handover to NSIS :-) Seriously, this concerns robustness of CT protocol. -Rajeev > > jak > > ----- Original Message ----- > From: "Rajeev Koodli" > To: "James Kempf" > Cc: "Gary Kenward" ; > ; ; > Sent: Friday, April 05, 2002 9:19 AM > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > Hello Jim, > > > > James Kempf wrote: > > > > > There is an issue if CT fails. In that case, some kind of > negotiation > > > after handover would be required. > > > > > > So, I'd say that some indication of CT failure is needed. > > > > > > > Yes, but this is between AR and MN. If CT fails, the AR should > > notify the MN to engage in context re-creation. > > > > My point was specific to signaling _beyond_ AR (i.e., upstream > signaling) > > independent of failure/success of CT. > > > > Hope this is clearer.. > > > > -Rajeev > > > > > > > > > > As for CAR, I don't see the relevance for QoS negotiation, though it > may > > > be useful for finding a new wireless medium. I also see it primarily > for > > > intertechnology handover, or, at best, interprovider handover. > > > > > > jak > > > ----- Original Message ----- > > > From: "Rajeev Koodli" > > > To: "Gary Kenward" > > > Cc: ; ; > > > Sent: Friday, April 05, 2002 9:01 AM > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > Hello, > > > > > > > > well, if the issue is QoS establishment after handover, > > > > > > > > - CT is applicable for establishing QoS state at the AR > > > > - if further signaling is desired beyond the AR, NSIS may > > > > consider it. I don't see how _signaling_ for QoS establishment > > > > beyond AR is relevant for seamoby. > > > > > > > > CAR _discovery_ could exchange QoS capability as one of the > > > > parameters that might then be fed to a selection algorithm. Any > > > > signaling for actually establishing QoS itself beyond the AR > > > > should be outside the scope of seamoby.. > > > > > > > > Regards, > > > > > > > > -Rajeev > > > > > > > > > > > > Gary Kenward wrote: > > > > > > > > > > > > > > > > > > > Hemant: > > > > > > > > > > Just a point of clarification, but as I understand CARD (and > > > > > I don't understand it well), it is not a QoS negotiation > > > > > protocol. The main application that you are referring to > primarily > > > > > arises out of a perceived need to determine at the MN the best > link > > > > > layer to handover over to when inter-technology handovers are > > > > > involved. > > > > > It can be applied to intra-technology handovers, but the value > in > > > > > that situation is highly questionable (e.g. since it is a > discovery > > > > > protocol, the implication is that the purpose is to determine > the > > > > > choice of channels available; for intra-technology handovers, > there > > > > > are many, many reasons why this "choice" may not be available). > > > > > > > > > > There is a requirement, 5.1.2, which seems to imply NSIS > > > involvement > > > > > > > > > > during/after a handover. John has stated that this is not the > > > > > intention > > > > > (please correct me if I have this wrong John), in which case I > think > > > > > 5.1.2 needs to be clarified. > > > > > > > > > > Specifically, is NSIS to be used to negotiated new QoS for an > > > > > existing flow after a handover, or is it specifically for > > > establishing > > > > > > > > > > QoS for a new flow? I don't think the answer is boolean: the > role > > > > > of NSIS in QoS re-negotiation is still open, I believe, and > clearly > > > > > handover is a dynamic situation that could cause the QoS > provided to > > > > > change. > > > > > > > > > > I have been told there is no issue, but here's a frightening > > > > > scenario: > > > > > > > > > > - a handover takes place, and context transfer has been > used > > > > > to > > > > > move the QoS context to the new routers (by the > requirements > > > > > for > > > > > CT this could be intra-, or inter- technology. Some of us > > > > > believe > > > > > that for "seamless" handovers, the context will be > available > > > at > > > > > > > > > > routers before the first packets need to be forwarded. > This > > > > > implies > > > > > that there is a relationship, probabilistic perhaps, > between > > > > > the handover process and the target ARs for CT. > > > > > > > > > > - CARD is used by the MN to influence the handover decision > (it > > > > > is not clear to me how this happens, but it seems clear > that > > > > > for a more "seamless" handover, the MN should chose an AR > > > that > > > > > has received the appropriate context; if not, then what? > > > > > > > > > > - NSIS kicks in and starts re-negotiating QoS because of > > > changes > > > > > introduced by the handover; > > > > > > > > > > How do these three protocols interact to produce predictable > > > > > outcomes? > > > > > Or, perhaps, the question is, how do the functional entities > > > > > associated > > > > > with the three protocols interact before, during and after a > > > handover? > > > > > > > > > > If it the interaction is within the functional entities, the > > > > > respective > > > > > wg's could declare the issue out of scope, but this approach > does > > > not > > > > > sit well with me, for it seems to defer the problem to the > people > > > who > > > > > have to implement this "stuff". > > > > > > > > > > Am I imagining things? > > > > > > > > > > Cheers, > > > > > Gary > > > > > > > > > > > -----Original Message----- > > > > > > From: Hemant.Chaskar@nokia.com > [mailto:Hemant.Chaskar@nokia.com] > > > > > > Sent: April 4, 2002 22:33 > > > > > > To: nsis@ietf.org > > > > > > Subject: RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > > > > > > Hi Sharif: > > > > > > > > > > > > There is currently a debate going on in Seamoby as to whether > > > > > > this QoS negotiation be covered by NSIS or Seamoby (CAR > > > > > > discovery protocol). > > > > > > > > > > > > IMHO it should be covered by CAR discovery and not NSIS. CAR > > > > > > discovery is supposed to identify candidate access routers > > > > > > for handoff and QoS is an important property for candidacy. > > > > > > > > > > > > Br, > > > > > > Hemant > > > > > > > > > > > > -----Original Message----- > > > > > > From: ext Shahrier, Sharif M. > > > > > > [mailto:Sharif.Shahrier@InterDigital.com] > > > > > > Sent: Thursday, April 04, 2002 3:35 PM > > > > > > To: Shahrier, Sharif M. > > > > > > Cc: 'nsis@ietf.org' > > > > > > Subject: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > > > > > > > > > > > > I have a question for clarification. > > > > > > > > > > > > I think it was stated that NSIS should only be concerned with > the > > > > > > establishment of QoS after handoff. > > > > > > > > > > > > This is inconvienent with respect to IP-level QoS > > > > > > negotiation, which ideally > > > > > > should be done before handoff has taken place. > > > > > > > > > > > > QoS negotiation is in the current requirements draft. > > > > > > > > > > > > So, NSIS signaling protocol development should be concerned > > > > > > with activity > > > > > > before handoff occurs. > > > > > > > > > > > > Sharif. > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > 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 > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Seamoby mailing list > > > > Seamoby@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Apr 5 13:14:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11909 for ; Fri, 5 Apr 2002 13:14:01 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA18926 for nsis-archive@odin.ietf.org; Fri, 5 Apr 2002 13:14:04 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA18742; Fri, 5 Apr 2002 13:09:18 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA18580 for ; Fri, 5 Apr 2002 13:09:08 -0500 (EST) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11826; Fri, 5 Apr 2002 13:09:04 -0500 (EST) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g35I8He04951; Fri, 5 Apr 2002 13:08:17 -0500 (EST) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 5 Apr 2002 13:08:16 -0500 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA49D0@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'James Kempf'" , Rajeev Koodli Cc: Hemant.Chaskar@nokia.com, nsis@ietf.org, seamoby@ietf.org Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Fri, 5 Apr 2002 13:08:14 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DCCC.DAFE9AC4" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1DCCC.DAFE9AC4 Content-Type: text/plain; charset="iso-8859-1" Well, as far as I see it, if CT fails it is due to one of three reasons: - the "network" is not aware that a handover to that AR is taking place (and the AR is forced to deal with the situation locally). - the context is not useable by the AR. - the AR cannot admit the flows. CT does not address the first two of these issues. The first is a handover issue; CT allows for the AR to attempt to fetch context (aka "reactive CT"), however, it is possible that the AR may choose to signal the MN rather then attempt to acquire old context). The second issues would seem to be a CARD issue (albeit, a network centric CARD issue). The third reason is, in my view, also a handover issue. The handover algorithm cannot handover flows to ARs that have no free resources. There are issues here resource reservation versus over-booking and timing. Is CARD an admission control protocol? Does it request resource reservation, or is it timely enough to assure that the resource availability does not change before the handover actually occurs? Regards, Gary PS I cross-posted the first email because the issue seemed to be relevant to both groups. If this is untrue, I will endeavour to take the issue to only one of the two lists. > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: April 5, 2002 12:39 > To: Rajeev Koodli > Cc: Kenward, Gary [WDLN2:AN10:EXCH]; Hemant.Chaskar@nokia.com; > nsis@ietf.org; seamoby@ietf.org > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > Rajeev, > > I agree, but there is still an issue of how the AR would notify the MN > if CT fails. Is this covered by CT or not? > > jak > > ----- Original Message ----- > From: "Rajeev Koodli" > To: "James Kempf" > Cc: "Gary Kenward" ; > ; ; > Sent: Friday, April 05, 2002 9:19 AM > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > Hello Jim, > > > > James Kempf wrote: > > > > > There is an issue if CT fails. In that case, some kind of > negotiation > > > after handover would be required. > > > > > > So, I'd say that some indication of CT failure is needed. > > > > > > > Yes, but this is between AR and MN. If CT fails, the AR should > > notify the MN to engage in context re-creation. > > > > My point was specific to signaling _beyond_ AR (i.e., upstream > signaling) > > independent of failure/success of CT. > > > > Hope this is clearer.. > > > > -Rajeev > > > > > > > > > > As for CAR, I don't see the relevance for QoS > negotiation, though it > may > > > be useful for finding a new wireless medium. I also see > it primarily > for > > > intertechnology handover, or, at best, interprovider handover. > > > > > > jak > > > ----- Original Message ----- > > > From: "Rajeev Koodli" > > > To: "Gary Kenward" > > > Cc: ; ; > > > > Sent: Friday, April 05, 2002 9:01 AM > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > Hello, > > > > > > > > well, if the issue is QoS establishment after handover, > > > > > > > > - CT is applicable for establishing QoS state at the AR > > > > - if further signaling is desired beyond the AR, NSIS may > > > > consider it. I don't see how _signaling_ for QoS > establishment > > > > beyond AR is relevant for seamoby. > > > > > > > > CAR _discovery_ could exchange QoS capability as one of the > > > > parameters that might then be fed to a selection algorithm. Any > > > > signaling for actually establishing QoS itself beyond the AR > > > > should be outside the scope of seamoby.. > > > > > > > > Regards, > > > > > > > > -Rajeev > > > > > > > > > > > > Gary Kenward wrote: > > > > > > > > > > > > > > > > > > > Hemant: > > > > > > > > > > Just a point of clarification, but as I understand CARD (and > > > > > I don't understand it well), it is not a QoS negotiation > > > > > protocol. The main application that you are referring to > primarily > > > > > arises out of a perceived need to determine at the MN the best > link > > > > > layer to handover over to when inter-technology handovers are > > > > > involved. > > > > > It can be applied to intra-technology handovers, but the value > in > > > > > that situation is highly questionable (e.g. since it is a > discovery > > > > > protocol, the implication is that the purpose is to determine > the > > > > > choice of channels available; for intra-technology handovers, > there > > > > > are many, many reasons why this "choice" may not be > available). > > > > > > > > > > There is a requirement, 5.1.2, which seems to imply NSIS > > > involvement > > > > > > > > > > during/after a handover. John has stated that this is not the > > > > > intention > > > > > (please correct me if I have this wrong John), in which case I > think > > > > > 5.1.2 needs to be clarified. > > > > > > > > > > Specifically, is NSIS to be used to negotiated new > QoS for an > > > > > existing flow after a handover, or is it specifically for > > > establishing > > > > > > > > > > QoS for a new flow? I don't think the answer is boolean: the > role > > > > > of NSIS in QoS re-negotiation is still open, I believe, and > clearly > > > > > handover is a dynamic situation that could cause the QoS > provided to > > > > > change. > > > > > > > > > > I have been told there is no issue, but here's a frightening > > > > > scenario: > > > > > > > > > > - a handover takes place, and context > transfer has been > used > > > > > to > > > > > move the QoS context to the new routers (by the > requirements > > > > > for > > > > > CT this could be intra-, or inter- technology. > Some of us > > > > > believe > > > > > that for "seamless" handovers, the context will be > available > > > at > > > > > > > > > > routers before the first packets need to be forwarded. > This > > > > > implies > > > > > that there is a relationship, probabilistic perhaps, > between > > > > > the handover process and the target ARs for CT. > > > > > > > > > > - CARD is used by the MN to influence the > handover decision > (it > > > > > is not clear to me how this happens, but it seems clear > that > > > > > for a more "seamless" handover, the MN should > chose an AR > > > that > > > > > has received the appropriate context; if not, > then what? > > > > > > > > > > - NSIS kicks in and starts re-negotiating QoS because of > > > changes > > > > > introduced by the handover; > > > > > > > > > > How do these three protocols interact to produce predictable > > > > > outcomes? > > > > > Or, perhaps, the question is, how do the functional entities > > > > > associated > > > > > with the three protocols interact before, during and after a > > > handover? > > > > > > > > > > If it the interaction is within the functional entities, the > > > > > respective > > > > > wg's could declare the issue out of scope, but this approach > does > > > not > > > > > sit well with me, for it seems to defer the problem to the > people > > > who > > > > > have to implement this "stuff". > > > > > > > > > > Am I imagining things? > > > > > > > > > > Cheers, > > > > > Gary > > > > > > > > > > > -----Original Message----- > > > > > > From: Hemant.Chaskar@nokia.com > [mailto:Hemant.Chaskar@nokia.com] > > > > > > Sent: April 4, 2002 22:33 > > > > > > To: nsis@ietf.org > > > > > > Subject: RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > > > > > > Hi Sharif: > > > > > > > > > > > > There is currently a debate going on in Seamoby as > to whether > > > > > > this QoS negotiation be covered by NSIS or Seamoby (CAR > > > > > > discovery protocol). > > > > > > > > > > > > IMHO it should be covered by CAR discovery and not NSIS. CAR > > > > > > discovery is supposed to identify candidate access routers > > > > > > for handoff and QoS is an important property for candidacy. > > > > > > > > > > > > Br, > > > > > > Hemant > > > > > > > > > > > > -----Original Message----- > > > > > > From: ext Shahrier, Sharif M. > > > > > > [mailto:Sharif.Shahrier@InterDigital.com] > > > > > > Sent: Thursday, April 04, 2002 3:35 PM > > > > > > To: Shahrier, Sharif M. > > > > > > Cc: 'nsis@ietf.org' > > > > > > Subject: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > > > > > > > > > > > > I have a question for clarification. > > > > > > > > > > > > I think it was stated that NSIS should only be > concerned with > the > > > > > > establishment of QoS after handoff. > > > > > > > > > > > > This is inconvienent with respect to IP-level QoS > > > > > > negotiation, which ideally > > > > > > should be done before handoff has taken place. > > > > > > > > > > > > QoS negotiation is in the current requirements draft. > > > > > > > > > > > > So, NSIS signaling protocol development should be concerned > > > > > > with activity > > > > > > before handoff occurs. > > > > > > > > > > > > Sharif. > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > 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 > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Seamoby mailing list > > > > Seamoby@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > > ------_=_NextPart_001_01C1DCCC.DAFE9AC4 Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff.

Well, as far as I see it, if CT fails it is due to one of three reasons:
 
 - the "network" is not aware that a handover to that AR is taking place
   (and the AR is forced to deal with the situation locally).

 - the context is not useable by the AR.

 - the AR cannot admit the flows.

CT does not address the first two of these issues. The first is a handover
issue; CT allows for the AR to attempt to fetch context (aka "reactive CT"),
however, it is possible that the AR may choose to signal the MN rather then
attempt to acquire old context). The second issues would seem to be a CARD
issue (albeit, a network centric CARD issue).

The third reason is, in my view, also a handover issue. The handover algorithm
cannot handover flows to ARs that have no free resources. There are issues
here resource reservation versus over-booking and timing. Is CARD an admission
control protocol? Does it request resource reservation, or is it timely enough
to assure that the resource availability does not change before the handover
actually occurs?

Regards,
Gary

PS I cross-posted the first email because the issue seemed to be relevant to
both groups. If this is untrue, I will endeavour to take the issue to only
one of the two lists.

> -----Original Message-----
> From: James Kempf [mailto:kempf@docomolabs-usa.com]
> Sent: April 5, 2002 12:39
> To: Rajeev Koodli
> Cc: Kenward, Gary [WDLN2:AN10:EXCH]; Hemant.Chaskar@nokia.com;
> nsis@ietf.org; seamoby@ietf.org
> Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff.
>
>
> Rajeev,
>
> I agree, but there is still an issue of how the AR would notify the MN
> if CT fails. Is this covered by CT or not?
>
>             jak
>
> ----- Original Message -----
> From: "Rajeev Koodli" <rajeev@iprg.nokia.com>
> To: "James Kempf" <kempf@docomolabs-usa.com>
> Cc: "Gary Kenward" <gkenward@nortelnetworks.com>;
> <Hemant.Chaskar@nokia.com>; <nsis@ietf.org>; <seamoby@ietf.org>
> Sent: Friday, April 05, 2002 9:19 AM
> Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff.
>
>
> >
> > Hello Jim,
> >
> > James Kempf wrote:
> >
> > > There is an issue if CT fails. In that case, some kind of
> negotiation
> > > after handover would be required.
> > >
> > > So, I'd say that some indication of CT failure is needed.
> > >
> >
> > Yes, but this is between AR and MN. If CT fails, the AR should
> > notify the MN to engage in context re-creation.
> >
> > My point was specific to signaling _beyond_ AR (i.e., upstream
> signaling)
> > independent of failure/success of CT.
> >
> > Hope this is clearer..
> >
> > -Rajeev
> >
> >
> > >
> > > As for CAR, I don't see the relevance for QoS
> negotiation, though it
> may
> > > be useful for finding a new wireless medium. I also see
> it primarily
> for
> > > intertechnology handover, or, at best, interprovider handover.
> > >
> > >             jak
> > > ----- Original Message -----
> > > From: "Rajeev Koodli" <rajeev@iprg.nokia.com>
> > > To: "Gary Kenward" <gkenward@nortelnetworks.com>
> > > Cc: <Hemant.Chaskar@nokia.com>; <nsis@ietf.org>;
> <seamoby@ietf.org>
> > > Sent: Friday, April 05, 2002 9:01 AM
> > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff.
> > >
> > > >
> > > > Hello,
> > > >
> > > > well, if the issue is QoS establishment after handover,
> > > >
> > > > - CT is applicable for establishing QoS state at the AR
> > > > - if further signaling is desired beyond the AR, NSIS may
> > > >     consider it. I don't see how _signaling_ for QoS
> establishment
> > > >     beyond AR is relevant for seamoby.
> > > >
> > > > CAR _discovery_ could exchange QoS capability as one of the
> > > > parameters that might then be fed to a selection algorithm. Any
> > > > signaling for actually establishing QoS itself beyond the AR
> > > > should be outside the scope of seamoby..
> > > >
> > > > Regards,
> > > >
> > > > -Rajeev
> > > >
> > > >
> > > > Gary Kenward wrote:
> > > >
> > > > >
> > > > >
> > > > > Hemant:
> > > > >
> > > > >   Just a point of clarification, but as I understand CARD (and
> > > > > I don't understand it well), it is not a QoS negotiation
> > > > > protocol. The main application that you are referring to
> primarily
> > > > > arises out of a perceived need to determine at the MN the best
> link
> > > > > layer to handover over to when inter-technology handovers are
> > > > > involved.
> > > > > It can be applied to intra-technology handovers, but the value
> in
> > > > > that situation is highly questionable (e.g. since it is a
> discovery
> > > > > protocol, the implication is that the purpose is to determine
> the
> > > > > choice of channels available; for intra-technology handovers,
> there
> > > > > are many, many reasons why this "choice" may not be
> available).
> > > > >
> > > > >   There is a requirement, 5.1.2, which seems to imply NSIS
> > > involvement
> > > > >
> > > > > during/after a handover. John has stated that this is not the
> > > > > intention
> > > > > (please correct me if I have this wrong John), in which case I
> think
> > > > > 5.1.2 needs to be clarified.
> > > > >
> > > > >   Specifically, is NSIS to be used to negotiated new
> QoS for an
> > > > > existing flow after a handover, or is it specifically for
> > > establishing
> > > > >
> > > > > QoS for a new flow? I don't think the answer is boolean: the
> role
> > > > > of NSIS in QoS re-negotiation is still open, I believe, and
> clearly
> > > > > handover is a dynamic situation that could cause the QoS
> provided to
> > > > > change.
> > > > >
> > > > >   I have been told there is no issue, but here's a frightening
> > > > > scenario:
> > > > >
> > > > >         - a handover takes place, and context
> transfer has been
> used
> > > > > to
> > > > >        move the QoS context to the new routers (by the
> requirements
> > > > > for
> > > > >        CT this could be intra-, or inter- technology.
> Some of us
> > > > > believe
> > > > >        that for "seamless" handovers, the context will be
> available
> > > at
> > > > >
> > > > >        routers before the first packets need to be forwarded.
> This
> > > > > implies
> > > > >        that there is a relationship, probabilistic perhaps,
> between
> > > > >        the handover process and the target ARs for CT.
> > > > >
> > > > >      - CARD is used by the MN to influence the
> handover decision
> (it
> > > > >        is not clear to me how this happens, but it seems clear
> that
> > > > >        for a more "seamless" handover, the MN should
> chose an AR
> > > that
> > > > >        has received the appropriate context; if not,
> then what?
> > > > >
> > > > >      - NSIS kicks in and starts re-negotiating QoS because of
> > > changes
> > > > >        introduced by the handover;
> > > > >
> > > > >   How do these three protocols interact to produce predictable
> > > > > outcomes?
> > > > > Or, perhaps, the question is, how do the functional entities
> > > > > associated
> > > > > with the three protocols interact before, during and after a
> > > handover?
> > > > >
> > > > > If it the interaction is within the functional entities, the
> > > > > respective
> > > > > wg's could declare the issue out of scope, but this approach
> does
> > > not
> > > > > sit well with me, for it seems to defer the problem to the
> people
> > > who
> > > > > have to implement this "stuff".
> > > > >
> > > > >   Am I imagining things?
> > > > >
> > > > > Cheers,
> > > > > Gary
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Hemant.Chaskar@nokia.com
> [mailto:Hemant.Chaskar@nokia.com]
> > > > > > Sent: April 4, 2002 22:33
> > > > > > To: nsis@ietf.org
> > > > > > Subject: RE: [NSIS] Establishing QoS after handoff.
> > > > > >
> > > > > >
> > > > > > Hi Sharif:
> > > > > >
> > > > > > There is currently a debate going on in Seamoby as
> to whether
> > > > > > this QoS negotiation be covered by NSIS or Seamoby (CAR
> > > > > > discovery protocol).
> > > > > >
> > > > > > IMHO it should be covered by CAR discovery and not NSIS. CAR
> > > > > > discovery is supposed to identify candidate access routers
> > > > > > for handoff and QoS is an important property for candidacy.
> > > > > >
> > > > > > Br,
> > > > > > Hemant
> > > > > >
> > > > > > -----Original Message-----
> > > > > > From: ext Shahrier, Sharif M.
> > > > > > [mailto:Sharif.Shahrier@InterDigital.com]
> > > > > > Sent: Thursday, April 04, 2002 3:35 PM
> > > > > > To: Shahrier, Sharif M.
> > > > > > Cc: 'nsis@ietf.org'
> > > > > > Subject: [NSIS] Establishing QoS after handoff.
> > > > > >
> > > > > >
> > > > > >
> > > > > > I have a question for clarification.
> > > > > >
> > > > > > I think it was stated that NSIS should only be
> concerned with
> the
> > > > > > establishment of QoS after handoff.
> > > > > >
> > > > > > This is inconvienent with respect to IP-level QoS
> > > > > > negotiation, which ideally
> > > > > > should be done before handoff has taken place.
> > > > > >
> > > > > > QoS negotiation is in the current requirements draft.
> > > > > >
> > > > > > So, NSIS signaling protocol development should be concerned
> > > > > > with activity
> > > > > > before handoff occurs.
> > > > > >
> > > > > > Sharif.
> > > > > >
> > > > > >
> > > > > >
> > > > > > _______________________________________________
> > > > > > 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
> > > > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > Seamoby mailing list
> > > > Seamoby@ietf.org
> > > > https://www1.ietf.org/mailman/listinfo/seamoby
> > > >
> >
> >
> > _______________________________________________
> > Seamoby mailing list
> > Seamoby@ietf.org
> > https://www1.ietf.org/mailman/listinfo/seamoby
> >
>

------_=_NextPart_001_01C1DCCC.DAFE9AC4-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Apr 5 13:30:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12382 for ; Fri, 5 Apr 2002 13:30:28 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA20008 for nsis-archive@odin.ietf.org; Fri, 5 Apr 2002 13:30:29 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA19570; Fri, 5 Apr 2002 13:24:32 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA19510 for ; Fri, 5 Apr 2002 13:24:27 -0500 (EST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12258; Fri, 5 Apr 2002 13:24:22 -0500 (EST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g35INZI02501; Fri, 5 Apr 2002 10:23:35 -0800 (PST) Message-ID: <01a501c1dcce$c6217660$7e6015ac@T23KEMPF> From: "James Kempf" To: "Rajeev Koodli" Cc: "Gary Kenward" , , , References: <9FBD322B7824D511B36900508BF93C9C01AA49C7@zcard031.ca.nortel.com> <3CADD85C.F8C8D50F@iprg.nokia.com> <012f01c1dcc4$5cf69850$7e6015ac@T23KEMPF> <3CADDC97.70EFE709@iprg.nokia.com> <016801c1dcc8$ccdadd30$7e6015ac@T23KEMPF> <3CADE6CE.DD37DEDB@iprg.nokia.com> Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Fri, 5 Apr 2002 10:21:58 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit Agree. But I don't see anything in the CT requirements about handling CT failure. ??? jak ----- Original Message ----- From: "Rajeev Koodli" To: "James Kempf" Cc: "Gary Kenward" ; ; ; Sent: Friday, April 05, 2002 10:02 AM Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > James Kempf wrote: > > > Rajeev, > > > > I agree, but there is still an issue of how the AR would notify the MN > > if CT fails. Is this covered by CT or not? > > > > This notification should be covered by CT. We should offer > seamless handover to NSIS :-) Seriously, this concerns > robustness of CT protocol. > > -Rajeev > > > > > > jak > > > > ----- Original Message ----- > > From: "Rajeev Koodli" > > To: "James Kempf" > > Cc: "Gary Kenward" ; > > ; ; > > Sent: Friday, April 05, 2002 9:19 AM > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > > > Hello Jim, > > > > > > James Kempf wrote: > > > > > > > There is an issue if CT fails. In that case, some kind of > > negotiation > > > > after handover would be required. > > > > > > > > So, I'd say that some indication of CT failure is needed. > > > > > > > > > > Yes, but this is between AR and MN. If CT fails, the AR should > > > notify the MN to engage in context re-creation. > > > > > > My point was specific to signaling _beyond_ AR (i.e., upstream > > signaling) > > > independent of failure/success of CT. > > > > > > Hope this is clearer.. > > > > > > -Rajeev > > > > > > > > > > > > > > As for CAR, I don't see the relevance for QoS negotiation, though it > > may > > > > be useful for finding a new wireless medium. I also see it primarily > > for > > > > intertechnology handover, or, at best, interprovider handover. > > > > > > > > jak > > > > ----- Original Message ----- > > > > From: "Rajeev Koodli" > > > > To: "Gary Kenward" > > > > Cc: ; ; > > > > Sent: Friday, April 05, 2002 9:01 AM > > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > > Hello, > > > > > > > > > > well, if the issue is QoS establishment after handover, > > > > > > > > > > - CT is applicable for establishing QoS state at the AR > > > > > - if further signaling is desired beyond the AR, NSIS may > > > > > consider it. I don't see how _signaling_ for QoS establishment > > > > > beyond AR is relevant for seamoby. > > > > > > > > > > CAR _discovery_ could exchange QoS capability as one of the > > > > > parameters that might then be fed to a selection algorithm. Any > > > > > signaling for actually establishing QoS itself beyond the AR > > > > > should be outside the scope of seamoby.. > > > > > > > > > > Regards, > > > > > > > > > > -Rajeev > > > > > > > > > > > > > > > Gary Kenward wrote: > > > > > > > > > > > > > > > > > > > > > > > Hemant: > > > > > > > > > > > > Just a point of clarification, but as I understand CARD (and > > > > > > I don't understand it well), it is not a QoS negotiation > > > > > > protocol. The main application that you are referring to > > primarily > > > > > > arises out of a perceived need to determine at the MN the best > > link > > > > > > layer to handover over to when inter-technology handovers are > > > > > > involved. > > > > > > It can be applied to intra-technology handovers, but the value > > in > > > > > > that situation is highly questionable (e.g. since it is a > > discovery > > > > > > protocol, the implication is that the purpose is to determine > > the > > > > > > choice of channels available; for intra-technology handovers, > > there > > > > > > are many, many reasons why this "choice" may not be available). > > > > > > > > > > > > There is a requirement, 5.1.2, which seems to imply NSIS > > > > involvement > > > > > > > > > > > > during/after a handover. John has stated that this is not the > > > > > > intention > > > > > > (please correct me if I have this wrong John), in which case I > > think > > > > > > 5.1.2 needs to be clarified. > > > > > > > > > > > > Specifically, is NSIS to be used to negotiated new QoS for an > > > > > > existing flow after a handover, or is it specifically for > > > > establishing > > > > > > > > > > > > QoS for a new flow? I don't think the answer is boolean: the > > role > > > > > > of NSIS in QoS re-negotiation is still open, I believe, and > > clearly > > > > > > handover is a dynamic situation that could cause the QoS > > provided to > > > > > > change. > > > > > > > > > > > > I have been told there is no issue, but here's a frightening > > > > > > scenario: > > > > > > > > > > > > - a handover takes place, and context transfer has been > > used > > > > > > to > > > > > > move the QoS context to the new routers (by the > > requirements > > > > > > for > > > > > > CT this could be intra-, or inter- technology. Some of us > > > > > > believe > > > > > > that for "seamless" handovers, the context will be > > available > > > > at > > > > > > > > > > > > routers before the first packets need to be forwarded. > > This > > > > > > implies > > > > > > that there is a relationship, probabilistic perhaps, > > between > > > > > > the handover process and the target ARs for CT. > > > > > > > > > > > > - CARD is used by the MN to influence the handover decision > > (it > > > > > > is not clear to me how this happens, but it seems clear > > that > > > > > > for a more "seamless" handover, the MN should chose an AR > > > > that > > > > > > has received the appropriate context; if not, then what? > > > > > > > > > > > > - NSIS kicks in and starts re-negotiating QoS because of > > > > changes > > > > > > introduced by the handover; > > > > > > > > > > > > How do these three protocols interact to produce predictable > > > > > > outcomes? > > > > > > Or, perhaps, the question is, how do the functional entities > > > > > > associated > > > > > > with the three protocols interact before, during and after a > > > > handover? > > > > > > > > > > > > If it the interaction is within the functional entities, the > > > > > > respective > > > > > > wg's could declare the issue out of scope, but this approach > > does > > > > not > > > > > > sit well with me, for it seems to defer the problem to the > > people > > > > who > > > > > > have to implement this "stuff". > > > > > > > > > > > > Am I imagining things? > > > > > > > > > > > > Cheers, > > > > > > Gary > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Hemant.Chaskar@nokia.com > > [mailto:Hemant.Chaskar@nokia.com] > > > > > > > Sent: April 4, 2002 22:33 > > > > > > > To: nsis@ietf.org > > > > > > > Subject: RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > > > > > > > > > Hi Sharif: > > > > > > > > > > > > > > There is currently a debate going on in Seamoby as to whether > > > > > > > this QoS negotiation be covered by NSIS or Seamoby (CAR > > > > > > > discovery protocol). > > > > > > > > > > > > > > IMHO it should be covered by CAR discovery and not NSIS. CAR > > > > > > > discovery is supposed to identify candidate access routers > > > > > > > for handoff and QoS is an important property for candidacy. > > > > > > > > > > > > > > Br, > > > > > > > Hemant > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: ext Shahrier, Sharif M. > > > > > > > [mailto:Sharif.Shahrier@InterDigital.com] > > > > > > > Sent: Thursday, April 04, 2002 3:35 PM > > > > > > > To: Shahrier, Sharif M. > > > > > > > Cc: 'nsis@ietf.org' > > > > > > > Subject: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > > > > > > > > > > > > > > > > I have a question for clarification. > > > > > > > > > > > > > > I think it was stated that NSIS should only be concerned with > > the > > > > > > > establishment of QoS after handoff. > > > > > > > > > > > > > > This is inconvienent with respect to IP-level QoS > > > > > > > negotiation, which ideally > > > > > > > should be done before handoff has taken place. > > > > > > > > > > > > > > QoS negotiation is in the current requirements draft. > > > > > > > > > > > > > > So, NSIS signaling protocol development should be concerned > > > > > > > with activity > > > > > > > before handoff occurs. > > > > > > > > > > > > > > Sharif. > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Seamoby mailing list > > > > > Seamoby@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > > > > > > _______________________________________________ > > > Seamoby mailing list > > > Seamoby@ietf.org > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Apr 5 13:45:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12939 for ; Fri, 5 Apr 2002 13:45:40 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA21401 for nsis-archive@odin.ietf.org; Fri, 5 Apr 2002 13:45:43 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA20984; Fri, 5 Apr 2002 13:39:45 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA20919 for ; Fri, 5 Apr 2002 13:39:40 -0500 (EST) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12671; Fri, 5 Apr 2002 13:39:35 -0500 (EST) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g35IZ4e06676; Fri, 5 Apr 2002 13:35:04 -0500 (EST) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 5 Apr 2002 13:35:04 -0500 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA49D3@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'James Kempf'" , Rajeev Koodli Cc: Hemant.Chaskar@nokia.com, nsis@ietf.org, seamoby@ietf.org Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Fri, 5 Apr 2002 13:34:56 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DCCF.3DBA5B2E" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1DCCF.3DBA5B2E Content-Type: text/plain; charset="iso-8859-1" Well yes and no. First, CT is required to do everything it can to get the context across intact, as fast as possible, which, it was decided, meant that there was realistically only one opportunity to attempt to transfer the context. The emphasis was placed on requiring that a given transfer of context would not fail (e.g. the context integrity should be preserved through error control, etc.). Then, if the transfer failed it was because of something other then the transfer process itself. If CT fails, it is more likely then not that handover will not be seamless anyways, and there is nothing that CT can do, per se, to recover. Having said this, CT can be re-invoked by another entity, perhaps the handover control function, for recovery purposes. I'm trying to be brief, so I hope this captures what was a looooong discussion. Gary > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: April 5, 2002 13:22 > To: Rajeev Koodli > Cc: Kenward, Gary [WDLN2:AN10:EXCH]; Hemant.Chaskar@nokia.com; > nsis@ietf.org; seamoby@ietf.org > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > Agree. > > But I don't see anything in the CT requirements about handling CT > failure. > > ??? > > jak > > > > ------_=_NextPart_001_01C1DCCF.3DBA5B2E Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff.

Well yes and no.

First, CT is required to do everything it can to get the
context across intact, as fast as possible, which, it was decided, meant
that there was realistically only one opportunity to attempt to transfer
the context. The emphasis was placed on requiring that a given transfer of
context would not fail (e.g. the context integrity should be preserved through
error control, etc.). Then, if the transfer failed it was because of something
other then the transfer process itself.

If CT fails, it is more likely then not that handover will not be seamless
anyways, and there is nothing that CT can do, per se, to recover.
Having said this, CT can be re-invoked by another entity, perhaps the handover
control function, for recovery purposes.

I'm trying to be brief, so I hope this captures what was a looooong discussion.

Gary

> -----Original Message-----
> From: James Kempf [mailto:kempf@docomolabs-usa.com]
> Sent: April 5, 2002 13:22
> To: Rajeev Koodli
> Cc: Kenward, Gary [WDLN2:AN10:EXCH]; Hemant.Chaskar@nokia.com;
> nsis@ietf.org; seamoby@ietf.org
> Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff.
>
>
> Agree.
>
> But I don't see anything in the CT requirements about handling CT
> failure.
>
> ???
>
>             jak
>
 >
>
>

------_=_NextPart_001_01C1DCCF.3DBA5B2E-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Apr 5 14:21:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14281 for ; Fri, 5 Apr 2002 14:21:45 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA23440 for nsis-archive@odin.ietf.org; Fri, 5 Apr 2002 14:21:48 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA23090; Fri, 5 Apr 2002 14:13:33 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA23039 for ; Fri, 5 Apr 2002 14:13:30 -0500 (EST) Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13848; Fri, 5 Apr 2002 14:13:25 -0500 (EST) From: Govind.Krishnamurthi@nokia.com Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g35JG1H17282; Fri, 5 Apr 2002 13:16:01 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 5 Apr 2002 13:13:27 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Fri, 5 Apr 2002 13:12:48 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DCD5.DF0B4838" Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Fri, 5 Apr 2002 14:12:47 -0500 Message-ID: Thread-Topic: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Thread-Index: AcHc09UCgOCOLnnTT+yWiX7chiBY4wAATuuQ To: , , Cc: , , X-OriginalArrivalTime: 05 Apr 2002 19:12:48.0390 (UTC) FILETIME=[DFCBBA60:01C1DCD5] Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C1DCD5.DF0B4838 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Gary, =20 The third reason is, in my view, also a handover issue. The handover = algorithm=20 cannot handover flows to ARs that have no free resources. There are = issues=20 here resource reservation versus over-booking and timing. Is CARD an = admission=20 control protocol? Does it request resource reservation, or is it timely = enough=20 to assure that the resource availability does not change before the = handover=20 actually occurs? =20 [Govind] IMHO, CARD can help an admission control protocol by giving = some relavant information about the AR.=20 But, I don't think it is an admission control protocol. Atleast I feel = this is true for CARD as it is described now. Best regards, Govind. =20 ------_=_NextPart_001_01C1DCD5.DF0B4838 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff.
Gary,
 

The third reason is, in my view, also a handover = issue. The=20 handover algorithm
cannot handover flows to = ARs that=20 have no free resources. There are issues
here resource=20 reservation versus over-booking and timing. Is CARD an = admission=20
control protocol? Does it request resource = reservation, or is=20 it timely enough
to assure that the resource = availability does not change before the handover
actually occurs?  

[Govind] IMHO, CARD can help an admission control = protocol by=20 giving some relavant information about the=20 AR. 

But,=20 I don't think it is an admission control protocol. Atleast I = feel this=20 is true for CARD as it is described now.

Best=20 regards,

Govind.

 

------_=_NextPart_001_01C1DCD5.DF0B4838-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Apr 5 15:23:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17415 for ; Fri, 5 Apr 2002 15:23:45 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA26988 for nsis-archive@odin.ietf.org; Fri, 5 Apr 2002 15:23:49 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA26794; Fri, 5 Apr 2002 15:17:35 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA26763 for ; Fri, 5 Apr 2002 15:17:33 -0500 (EST) Received: from idcpa4.pa.interdigital.com (idcmail.interdigital.com [12.32.197.142]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17326 for ; Fri, 5 Apr 2002 15:17:28 -0500 (EST) Received: by idcpa4.pa.interdigital.com with Internet Mail Service (5.5.2653.19) id ; Fri, 5 Apr 2002 15:15:56 -0500 Message-ID: From: "Shahrier, Sharif M." To: "'john.loughney@nokia.com'" , nsis@ietf.org Subject: RE: [NSIS] Establishing QoS after handoff. Date: Fri, 5 Apr 2002 15:15:53 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org John, So you are saying that CARD may perform QoS negotiation (if necessary) between ARs when selecting handoff targets? If that decision is made, then all the QoS negotiation/renegotiation requirements should be removed from the current NSIS requirements draft, because it would be obsolete. Sharif. > There is currently a debate going on in Seamoby as to whether > this QoS negotiation be covered by NSIS or Seamoby (CAR > discovery protocol). > > IMHO it should be covered by CAR discovery and not NSIS. CAR > discovery is supposed to identify candidate access routers > for handoff and QoS is an important property for candidacy. CAR discovery may be used to select handoff targets with correct QoS support / capabilities. Context Transfer (CT) can be used with the handoff procedure to ensure proper QoS state gets transfered to the new access router. If there is anyone interested in this work, please let me know. The SeaMoby chairs asked me to see if NSIS can provide them any information about QoS needs. thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Apr 5 16:00:29 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18491 for ; Fri, 5 Apr 2002 16:00:29 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA28588 for nsis-archive@odin.ietf.org; Fri, 5 Apr 2002 16:00:33 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA28205; Fri, 5 Apr 2002 15:55:27 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA28173 for ; Fri, 5 Apr 2002 15:55:24 -0500 (EST) Received: from idcpa4.pa.interdigital.com (idcmail.interdigital.com [12.32.197.142]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18274 for ; Fri, 5 Apr 2002 15:55:20 -0500 (EST) Received: by idcpa4.pa.interdigital.com with Internet Mail Service (5.5.2653.19) id ; Fri, 5 Apr 2002 15:53:48 -0500 Message-ID: From: "Shahrier, Sharif M." To: "Shahrier, Sharif M." , nsis@ietf.org Subject: [NSIS] Co-ordination work between NSIS and IEEE 802.11 TG-E Date: Fri, 5 Apr 2002 15:53:38 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org I wanted to put this out as a topic of discussion, as a possible joint co-ordinated work between NSIS and IEEE 802.11 TG-E. TG-E have been tasked with enhancing the 802.11 MAC to improve and manage QoS. I am not sure what is the current status of this work, perhaps participants to TG-E can provide some information. I believe an important study item is to figure out how QoS signaling protocols from TG-E should interact with NSIS QoS signaling protocols. I am aware that SEAMOBY has presented a case to TG-F where 802.11 ESS infrastructure networks could be connected together with a router(s) in between. How to interwork IAPP with IETF's handover protocol was the topic. I would assume that L2 QoS signaling would terminate at the AP, and further signaling would then be needed to transport QoS parameters across interconnected router(s). This signaling would subsequently terminate at the destination AP, where L2 signaling is again used. The middle part, i.e. transport of QoS parameters across disparate QoS domain is NSIS. Thus, as a study: - need to determine how and which L2 parameters need to be extracted. - How to transform and map them to L3 parameters for sinaling - How the two signaling protocols should interact. I think it is worthwhile to present a case for this to TG-E at the Vancouver Plenary. Any interest and comments would be appreciated. Sharif. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Apr 5 16:53:47 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20000 for ; Fri, 5 Apr 2002 16:53:47 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA00952 for nsis-archive@odin.ietf.org; Fri, 5 Apr 2002 16:53:48 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA00701; Fri, 5 Apr 2002 16:44:11 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA00650 for ; Fri, 5 Apr 2002 16:44:07 -0500 (EST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19751; Fri, 5 Apr 2002 16:44:02 -0500 (EST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id NAA26077; Fri, 5 Apr 2002 13:43:35 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g35LhXi03701; Fri, 5 Apr 2002 13:43:33 -0800 X-mProtect: <200204052143> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdFKd5Lq; Fri, 05 Apr 2002 13:43:32 PST Message-ID: <3CAE1A84.5CFDB01D@iprg.nokia.com> Date: Fri, 05 Apr 2002 13:43:32 -0800 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Gary Kenward CC: "'James Kempf'" , Hemant.Chaskar@nokia.com, nsis@ietf.org, seamoby@ietf.org Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. References: <9FBD322B7824D511B36900508BF93C9C01AA49D3@zcard031.ca.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit Gary, CT is a protocol, and as such would have failure modes. For instance, transferred context is not useful at the target router. You could say that CARD should never let this happen. Does that mean that CT cannot be used where CARD is not available ? I hope not! In any case, I don't know of a protocol that does not have failure modes. We need a notification message in CT to inform when such a thing happens. Regards, -Rajeev Gary Kenward wrote: > > > Well yes and no. > > First, CT is required to do everything it can to get the > context across intact, as fast as possible, which, it was decided, > meant > that there was realistically only one opportunity to attempt to > transfer > the context. The emphasis was placed on requiring that a given > transfer of > context would not fail (e.g. the context integrity should be preserved > through > error control, etc.). Then, if the transfer failed it was because of > something > other then the transfer process itself. > > If CT fails, it is more likely then not that handover will not be > seamless > anyways, and there is nothing that CT can do, per se, to recover. > Having said this, CT can be re-invoked by another entity, perhaps the > handover > control function, for recovery purposes. > > I'm trying to be brief, so I hope this captures what was a looooong > discussion. > > Gary > > > -----Original Message----- > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > Sent: April 5, 2002 13:22 > > To: Rajeev Koodli > > Cc: Kenward, Gary [WDLN2:AN10:EXCH]; Hemant.Chaskar@nokia.com; > > nsis@ietf.org; seamoby@ietf.org > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > Agree. > > > > But I don't see anything in the CT requirements about handling CT > > failure. > > > > ??? > > > > jak > > > > > > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Apr 5 16:59:40 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20271 for ; Fri, 5 Apr 2002 16:59:35 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA01521 for nsis-archive@odin.ietf.org; Fri, 5 Apr 2002 16:59:40 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA01189; Fri, 5 Apr 2002 16:54:29 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA01043 for ; Fri, 5 Apr 2002 16:54:19 -0500 (EST) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20017; Fri, 5 Apr 2002 16:54:13 -0500 (EST) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id OAA16179; Fri, 5 Apr 2002 14:54:12 -0700 (MST)] Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id OAA16869; Fri, 5 Apr 2002 14:54:12 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2654.52) id ; Fri, 5 Apr 2002 15:54:12 -0600 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0465003C@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'Rajeev Koodli'" , Gary Kenward Cc: Hemant.Chaskar@nokia.com, nsis@ietf.org, seamoby@ietf.org Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Fri, 5 Apr 2002 15:54:04 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hello Rajeev, I agreed with everything you say below, except one thing: CT can only transfer whatever QoS state that is usable at the newAR. If the new network is using a different QoS technology with different QoS parameters, then I am not sure if CT by itself can do the job, unless you add your own mapping functionality. BR, Madjid -----Original Message----- From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] Sent: Friday, April 05, 2002 11:01 AM To: Gary Kenward Cc: Hemant.Chaskar@nokia.com; nsis@ietf.org; seamoby@ietf.org Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Hello, well, if the issue is QoS establishment after handover, - CT is applicable for establishing QoS state at the AR - if further signaling is desired beyond the AR, NSIS may consider it. I don't see how _signaling_ for QoS establishment beyond AR is relevant for seamoby. CAR _discovery_ could exchange QoS capability as one of the parameters that might then be fed to a selection algorithm. Any signaling for actually establishing QoS itself beyond the AR should be outside the scope of seamoby.. Regards, -Rajeev Gary Kenward wrote: > > > Hemant: > > Just a point of clarification, but as I understand CARD (and > I don't understand it well), it is not a QoS negotiation > protocol. The main application that you are referring to primarily > arises out of a perceived need to determine at the MN the best link > layer to handover over to when inter-technology handovers are > involved. > It can be applied to intra-technology handovers, but the value in > that situation is highly questionable (e.g. since it is a discovery > protocol, the implication is that the purpose is to determine the > choice of channels available; for intra-technology handovers, there > are many, many reasons why this "choice" may not be available). > > There is a requirement, 5.1.2, which seems to imply NSIS involvement > > during/after a handover. John has stated that this is not the > intention > (please correct me if I have this wrong John), in which case I think > 5.1.2 needs to be clarified. > > Specifically, is NSIS to be used to negotiated new QoS for an > existing flow after a handover, or is it specifically for establishing > > QoS for a new flow? I don't think the answer is boolean: the role > of NSIS in QoS re-negotiation is still open, I believe, and clearly > handover is a dynamic situation that could cause the QoS provided to > change. > > I have been told there is no issue, but here's a frightening > scenario: > > - a handover takes place, and context transfer has been used > to > move the QoS context to the new routers (by the requirements > for > CT this could be intra-, or inter- technology. Some of us > believe > that for "seamless" handovers, the context will be available at > > routers before the first packets need to be forwarded. This > implies > that there is a relationship, probabilistic perhaps, between > the handover process and the target ARs for CT. > > - CARD is used by the MN to influence the handover decision (it > is not clear to me how this happens, but it seems clear that > for a more "seamless" handover, the MN should chose an AR that > has received the appropriate context; if not, then what? > > - NSIS kicks in and starts re-negotiating QoS because of changes > introduced by the handover; > > How do these three protocols interact to produce predictable > outcomes? > Or, perhaps, the question is, how do the functional entities > associated > with the three protocols interact before, during and after a handover? > > If it the interaction is within the functional entities, the > respective > wg's could declare the issue out of scope, but this approach does not > sit well with me, for it seems to defer the problem to the people who > have to implement this "stuff". > > Am I imagining things? > > Cheers, > Gary > > > -----Original Message----- > > From: Hemant.Chaskar@nokia.com [mailto:Hemant.Chaskar@nokia.com] > > Sent: April 4, 2002 22:33 > > To: nsis@ietf.org > > Subject: RE: [NSIS] Establishing QoS after handoff. > > > > > > Hi Sharif: > > > > There is currently a debate going on in Seamoby as to whether > > this QoS negotiation be covered by NSIS or Seamoby (CAR > > discovery protocol). > > > > IMHO it should be covered by CAR discovery and not NSIS. CAR > > discovery is supposed to identify candidate access routers > > for handoff and QoS is an important property for candidacy. > > > > Br, > > Hemant > > > > -----Original Message----- > > From: ext Shahrier, Sharif M. > > [mailto:Sharif.Shahrier@InterDigital.com] > > Sent: Thursday, April 04, 2002 3:35 PM > > To: Shahrier, Sharif M. > > Cc: 'nsis@ietf.org' > > Subject: [NSIS] Establishing QoS after handoff. > > > > > > > > I have a question for clarification. > > > > I think it was stated that NSIS should only be concerned with the > > establishment of QoS after handoff. > > > > This is inconvienent with respect to IP-level QoS > > negotiation, which ideally > > should be done before handoff has taken place. > > > > QoS negotiation is in the current requirements draft. > > > > So, NSIS signaling protocol development should be concerned > > with activity > > before handoff occurs. > > > > Sharif. > > > > > > > > _______________________________________________ > > 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 > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Apr 5 17:04:19 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20475 for ; Fri, 5 Apr 2002 17:04:19 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA02446 for nsis-archive@odin.ietf.org; Fri, 5 Apr 2002 17:04:23 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA01393; Fri, 5 Apr 2002 16:58:13 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA01307 for ; Fri, 5 Apr 2002 16:58:07 -0500 (EST) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20192; Fri, 5 Apr 2002 16:58:02 -0500 (EST) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (motgate 2.1) with ESMTP id OAA26028; Fri, 5 Apr 2002 14:58:06 -0700 (MST)] Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id OAA08156; Fri, 5 Apr 2002 14:58:06 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2654.52) id ; Fri, 5 Apr 2002 15:58:06 -0600 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0465003D@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'Rajeev Koodli'" , James Kempf Cc: Gary Kenward , Hemant.Chaskar@nokia.com, nsis@ietf.org, seamoby@ietf.org Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Fri, 5 Apr 2002 15:57:42 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Agreed. I don't think reliability in signaling, which by the way neither CT requirements, nor nsis requirements are covering, has to do with failure in QoS negotiation. I don't think you can count the case, where the QoS information that CT has given the AR is not applicable, as a CT failure. Madjid -----Original Message----- From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] Sent: Friday, April 05, 2002 12:03 PM To: James Kempf Cc: Gary Kenward; Hemant.Chaskar@nokia.com; nsis@ietf.org; seamoby@ietf.org Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. James Kempf wrote: > Rajeev, > > I agree, but there is still an issue of how the AR would notify the MN > if CT fails. Is this covered by CT or not? > This notification should be covered by CT. We should offer seamless handover to NSIS :-) Seriously, this concerns robustness of CT protocol. -Rajeev > > jak > > ----- Original Message ----- > From: "Rajeev Koodli" > To: "James Kempf" > Cc: "Gary Kenward" ; > ; ; > Sent: Friday, April 05, 2002 9:19 AM > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > Hello Jim, > > > > James Kempf wrote: > > > > > There is an issue if CT fails. In that case, some kind of > negotiation > > > after handover would be required. > > > > > > So, I'd say that some indication of CT failure is needed. > > > > > > > Yes, but this is between AR and MN. If CT fails, the AR should > > notify the MN to engage in context re-creation. > > > > My point was specific to signaling _beyond_ AR (i.e., upstream > signaling) > > independent of failure/success of CT. > > > > Hope this is clearer.. > > > > -Rajeev > > > > > > > > > > As for CAR, I don't see the relevance for QoS negotiation, though it > may > > > be useful for finding a new wireless medium. I also see it primarily > for > > > intertechnology handover, or, at best, interprovider handover. > > > > > > jak > > > ----- Original Message ----- > > > From: "Rajeev Koodli" > > > To: "Gary Kenward" > > > Cc: ; ; > > > Sent: Friday, April 05, 2002 9:01 AM > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > Hello, > > > > > > > > well, if the issue is QoS establishment after handover, > > > > > > > > - CT is applicable for establishing QoS state at the AR > > > > - if further signaling is desired beyond the AR, NSIS may > > > > consider it. I don't see how _signaling_ for QoS establishment > > > > beyond AR is relevant for seamoby. > > > > > > > > CAR _discovery_ could exchange QoS capability as one of the > > > > parameters that might then be fed to a selection algorithm. Any > > > > signaling for actually establishing QoS itself beyond the AR > > > > should be outside the scope of seamoby.. > > > > > > > > Regards, > > > > > > > > -Rajeev > > > > > > > > > > > > Gary Kenward wrote: > > > > > > > > > > > > > > > > > > > Hemant: > > > > > > > > > > Just a point of clarification, but as I understand CARD (and > > > > > I don't understand it well), it is not a QoS negotiation > > > > > protocol. The main application that you are referring to > primarily > > > > > arises out of a perceived need to determine at the MN the best > link > > > > > layer to handover over to when inter-technology handovers are > > > > > involved. > > > > > It can be applied to intra-technology handovers, but the value > in > > > > > that situation is highly questionable (e.g. since it is a > discovery > > > > > protocol, the implication is that the purpose is to determine > the > > > > > choice of channels available; for intra-technology handovers, > there > > > > > are many, many reasons why this "choice" may not be available). > > > > > > > > > > There is a requirement, 5.1.2, which seems to imply NSIS > > > involvement > > > > > > > > > > during/after a handover. John has stated that this is not the > > > > > intention > > > > > (please correct me if I have this wrong John), in which case I > think > > > > > 5.1.2 needs to be clarified. > > > > > > > > > > Specifically, is NSIS to be used to negotiated new QoS for an > > > > > existing flow after a handover, or is it specifically for > > > establishing > > > > > > > > > > QoS for a new flow? I don't think the answer is boolean: the > role > > > > > of NSIS in QoS re-negotiation is still open, I believe, and > clearly > > > > > handover is a dynamic situation that could cause the QoS > provided to > > > > > change. > > > > > > > > > > I have been told there is no issue, but here's a frightening > > > > > scenario: > > > > > > > > > > - a handover takes place, and context transfer has been > used > > > > > to > > > > > move the QoS context to the new routers (by the > requirements > > > > > for > > > > > CT this could be intra-, or inter- technology. Some of us > > > > > believe > > > > > that for "seamless" handovers, the context will be > available > > > at > > > > > > > > > > routers before the first packets need to be forwarded. > This > > > > > implies > > > > > that there is a relationship, probabilistic perhaps, > between > > > > > the handover process and the target ARs for CT. > > > > > > > > > > - CARD is used by the MN to influence the handover decision > (it > > > > > is not clear to me how this happens, but it seems clear > that > > > > > for a more "seamless" handover, the MN should chose an AR > > > that > > > > > has received the appropriate context; if not, then what? > > > > > > > > > > - NSIS kicks in and starts re-negotiating QoS because of > > > changes > > > > > introduced by the handover; > > > > > > > > > > How do these three protocols interact to produce predictable > > > > > outcomes? > > > > > Or, perhaps, the question is, how do the functional entities > > > > > associated > > > > > with the three protocols interact before, during and after a > > > handover? > > > > > > > > > > If it the interaction is within the functional entities, the > > > > > respective > > > > > wg's could declare the issue out of scope, but this approach > does > > > not > > > > > sit well with me, for it seems to defer the problem to the > people > > > who > > > > > have to implement this "stuff". > > > > > > > > > > Am I imagining things? > > > > > > > > > > Cheers, > > > > > Gary > > > > > > > > > > > -----Original Message----- > > > > > > From: Hemant.Chaskar@nokia.com > [mailto:Hemant.Chaskar@nokia.com] > > > > > > Sent: April 4, 2002 22:33 > > > > > > To: nsis@ietf.org > > > > > > Subject: RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > > > > > > Hi Sharif: > > > > > > > > > > > > There is currently a debate going on in Seamoby as to whether > > > > > > this QoS negotiation be covered by NSIS or Seamoby (CAR > > > > > > discovery protocol). > > > > > > > > > > > > IMHO it should be covered by CAR discovery and not NSIS. CAR > > > > > > discovery is supposed to identify candidate access routers > > > > > > for handoff and QoS is an important property for candidacy. > > > > > > > > > > > > Br, > > > > > > Hemant > > > > > > > > > > > > -----Original Message----- > > > > > > From: ext Shahrier, Sharif M. > > > > > > [mailto:Sharif.Shahrier@InterDigital.com] > > > > > > Sent: Thursday, April 04, 2002 3:35 PM > > > > > > To: Shahrier, Sharif M. > > > > > > Cc: 'nsis@ietf.org' > > > > > > Subject: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > > > > > > > > > > > > I have a question for clarification. > > > > > > > > > > > > I think it was stated that NSIS should only be concerned with > the > > > > > > establishment of QoS after handoff. > > > > > > > > > > > > This is inconvienent with respect to IP-level QoS > > > > > > negotiation, which ideally > > > > > > should be done before handoff has taken place. > > > > > > > > > > > > QoS negotiation is in the current requirements draft. > > > > > > > > > > > > So, NSIS signaling protocol development should be concerned > > > > > > with activity > > > > > > before handoff occurs. > > > > > > > > > > > > Sharif. > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > 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 > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Seamoby mailing list > > > > Seamoby@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Apr 5 17:11:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01293 for ; Fri, 5 Apr 2002 17:11:06 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA02490 for nsis-archive@odin.ietf.org; Fri, 5 Apr 2002 17:06:51 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA01936; Fri, 5 Apr 2002 17:00:43 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA01889 for ; Fri, 5 Apr 2002 17:00:39 -0500 (EST) Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20384; Fri, 5 Apr 2002 17:00:33 -0500 (EST) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate3.mot.com (motgate3 2.1) with ESMTP id OAA08119; Fri, 5 Apr 2002 14:49:10 -0700 (MST)] Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id PAA11013; Fri, 5 Apr 2002 15:00:36 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2654.52) id ; Fri, 5 Apr 2002 16:00:36 -0600 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0465003E@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'James Kempf'" , Rajeev Koodli Cc: Gary Kenward , Hemant.Chaskar@nokia.com, nsis@ietf.org, seamoby@ietf.org Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Fri, 5 Apr 2002 16:00:32 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Well, you are opening a can of worm that took seamoby 3 months to close without any results. People could not agree on the reliability needs of CT. We added a reliability mechanism to our CT proposal that covered both retransmission and updates. Madjid -----Original Message----- From: James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Friday, April 05, 2002 12:22 PM To: Rajeev Koodli Cc: Gary Kenward; Hemant.Chaskar@nokia.com; nsis@ietf.org; seamoby@ietf.org Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Agree. But I don't see anything in the CT requirements about handling CT failure. ??? jak ----- Original Message ----- From: "Rajeev Koodli" To: "James Kempf" Cc: "Gary Kenward" ; ; ; Sent: Friday, April 05, 2002 10:02 AM Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > James Kempf wrote: > > > Rajeev, > > > > I agree, but there is still an issue of how the AR would notify the MN > > if CT fails. Is this covered by CT or not? > > > > This notification should be covered by CT. We should offer > seamless handover to NSIS :-) Seriously, this concerns > robustness of CT protocol. > > -Rajeev > > > > > > jak > > > > ----- Original Message ----- > > From: "Rajeev Koodli" > > To: "James Kempf" > > Cc: "Gary Kenward" ; > > ; ; > > Sent: Friday, April 05, 2002 9:19 AM > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > > > Hello Jim, > > > > > > James Kempf wrote: > > > > > > > There is an issue if CT fails. In that case, some kind of > > negotiation > > > > after handover would be required. > > > > > > > > So, I'd say that some indication of CT failure is needed. > > > > > > > > > > Yes, but this is between AR and MN. If CT fails, the AR should > > > notify the MN to engage in context re-creation. > > > > > > My point was specific to signaling _beyond_ AR (i.e., upstream > > signaling) > > > independent of failure/success of CT. > > > > > > Hope this is clearer.. > > > > > > -Rajeev > > > > > > > > > > > > > > As for CAR, I don't see the relevance for QoS negotiation, though it > > may > > > > be useful for finding a new wireless medium. I also see it primarily > > for > > > > intertechnology handover, or, at best, interprovider handover. > > > > > > > > jak > > > > ----- Original Message ----- > > > > From: "Rajeev Koodli" > > > > To: "Gary Kenward" > > > > Cc: ; ; > > > > Sent: Friday, April 05, 2002 9:01 AM > > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > > Hello, > > > > > > > > > > well, if the issue is QoS establishment after handover, > > > > > > > > > > - CT is applicable for establishing QoS state at the AR > > > > > - if further signaling is desired beyond the AR, NSIS may > > > > > consider it. I don't see how _signaling_ for QoS establishment > > > > > beyond AR is relevant for seamoby. > > > > > > > > > > CAR _discovery_ could exchange QoS capability as one of the > > > > > parameters that might then be fed to a selection algorithm. Any > > > > > signaling for actually establishing QoS itself beyond the AR > > > > > should be outside the scope of seamoby.. > > > > > > > > > > Regards, > > > > > > > > > > -Rajeev > > > > > > > > > > > > > > > Gary Kenward wrote: > > > > > > > > > > > > > > > > > > > > > > > Hemant: > > > > > > > > > > > > Just a point of clarification, but as I understand CARD (and > > > > > > I don't understand it well), it is not a QoS negotiation > > > > > > protocol. The main application that you are referring to > > primarily > > > > > > arises out of a perceived need to determine at the MN the best > > link > > > > > > layer to handover over to when inter-technology handovers are > > > > > > involved. > > > > > > It can be applied to intra-technology handovers, but the value > > in > > > > > > that situation is highly questionable (e.g. since it is a > > discovery > > > > > > protocol, the implication is that the purpose is to determine > > the > > > > > > choice of channels available; for intra-technology handovers, > > there > > > > > > are many, many reasons why this "choice" may not be available). > > > > > > > > > > > > There is a requirement, 5.1.2, which seems to imply NSIS > > > > involvement > > > > > > > > > > > > during/after a handover. John has stated that this is not the > > > > > > intention > > > > > > (please correct me if I have this wrong John), in which case I > > think > > > > > > 5.1.2 needs to be clarified. > > > > > > > > > > > > Specifically, is NSIS to be used to negotiated new QoS for an > > > > > > existing flow after a handover, or is it specifically for > > > > establishing > > > > > > > > > > > > QoS for a new flow? I don't think the answer is boolean: the > > role > > > > > > of NSIS in QoS re-negotiation is still open, I believe, and > > clearly > > > > > > handover is a dynamic situation that could cause the QoS > > provided to > > > > > > change. > > > > > > > > > > > > I have been told there is no issue, but here's a frightening > > > > > > scenario: > > > > > > > > > > > > - a handover takes place, and context transfer has been > > used > > > > > > to > > > > > > move the QoS context to the new routers (by the > > requirements > > > > > > for > > > > > > CT this could be intra-, or inter- technology. Some of us > > > > > > believe > > > > > > that for "seamless" handovers, the context will be > > available > > > > at > > > > > > > > > > > > routers before the first packets need to be forwarded. > > This > > > > > > implies > > > > > > that there is a relationship, probabilistic perhaps, > > between > > > > > > the handover process and the target ARs for CT. > > > > > > > > > > > > - CARD is used by the MN to influence the handover decision > > (it > > > > > > is not clear to me how this happens, but it seems clear > > that > > > > > > for a more "seamless" handover, the MN should chose an AR > > > > that > > > > > > has received the appropriate context; if not, then what? > > > > > > > > > > > > - NSIS kicks in and starts re-negotiating QoS because of > > > > changes > > > > > > introduced by the handover; > > > > > > > > > > > > How do these three protocols interact to produce predictable > > > > > > outcomes? > > > > > > Or, perhaps, the question is, how do the functional entities > > > > > > associated > > > > > > with the three protocols interact before, during and after a > > > > handover? > > > > > > > > > > > > If it the interaction is within the functional entities, the > > > > > > respective > > > > > > wg's could declare the issue out of scope, but this approach > > does > > > > not > > > > > > sit well with me, for it seems to defer the problem to the > > people > > > > who > > > > > > have to implement this "stuff". > > > > > > > > > > > > Am I imagining things? > > > > > > > > > > > > Cheers, > > > > > > Gary > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Hemant.Chaskar@nokia.com > > [mailto:Hemant.Chaskar@nokia.com] > > > > > > > Sent: April 4, 2002 22:33 > > > > > > > To: nsis@ietf.org > > > > > > > Subject: RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > > > > > > > > > Hi Sharif: > > > > > > > > > > > > > > There is currently a debate going on in Seamoby as to whether > > > > > > > this QoS negotiation be covered by NSIS or Seamoby (CAR > > > > > > > discovery protocol). > > > > > > > > > > > > > > IMHO it should be covered by CAR discovery and not NSIS. CAR > > > > > > > discovery is supposed to identify candidate access routers > > > > > > > for handoff and QoS is an important property for candidacy. > > > > > > > > > > > > > > Br, > > > > > > > Hemant > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: ext Shahrier, Sharif M. > > > > > > > [mailto:Sharif.Shahrier@InterDigital.com] > > > > > > > Sent: Thursday, April 04, 2002 3:35 PM > > > > > > > To: Shahrier, Sharif M. > > > > > > > Cc: 'nsis@ietf.org' > > > > > > > Subject: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > > > > > > > > > > > > > > > > I have a question for clarification. > > > > > > > > > > > > > > I think it was stated that NSIS should only be concerned with > > the > > > > > > > establishment of QoS after handoff. > > > > > > > > > > > > > > This is inconvienent with respect to IP-level QoS > > > > > > > negotiation, which ideally > > > > > > > should be done before handoff has taken place. > > > > > > > > > > > > > > QoS negotiation is in the current requirements draft. > > > > > > > > > > > > > > So, NSIS signaling protocol development should be concerned > > > > > > > with activity > > > > > > > before handoff occurs. > > > > > > > > > > > > > > Sharif. > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Seamoby mailing list > > > > > Seamoby@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > > > > > > _______________________________________________ > > > Seamoby mailing list > > > Seamoby@ietf.org > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Apr 5 18:17:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06974 for ; Fri, 5 Apr 2002 18:17:28 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA05963 for nsis-archive@odin.ietf.org; Fri, 5 Apr 2002 18:17:33 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA05585; Fri, 5 Apr 2002 18:12:21 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA05501 for ; Fri, 5 Apr 2002 18:12:16 -0500 (EST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06457; Fri, 5 Apr 2002 18:12:10 -0500 (EST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id PAA04485; Fri, 5 Apr 2002 15:11:43 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g35NBgx24333; Fri, 5 Apr 2002 15:11:42 -0800 X-mProtect: <200204052311> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdJlETm4; Fri, 05 Apr 2002 14:45:57 PST Message-ID: <3CAE2925.16FCCD2A@iprg.nokia.com> Date: Fri, 05 Apr 2002 14:45:57 -0800 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Nakhjiri Madjid-MNAKHJI1 CC: Gary Kenward , Hemant.Chaskar@nokia.com, nsis@ietf.org, seamoby@ietf.org Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. References: <35DBB8B7AC89D4118E98009027B1009B0465003C@IL27EXM10.cig.mot.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit Hello Madjid, Nakhjiri Madjid-MNAKHJI1 wrote: > Hello Rajeev, > > I agreed with everything you say below, except one thing: > CT can only transfer whatever QoS state that is usable at the newAR. > If the new network is using a different QoS technology with different > QoS parameters, then I am not sure if CT by itself can do the job, unless > you add your own mapping functionality. > This would be an example where the new AR sends a notification to the MN so that the MN can take appropriate action (for instance, attempt to re-create the context). Regards, -Rajeev > > BR, > Madjid > > -----Original Message----- > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] > Sent: Friday, April 05, 2002 11:01 AM > To: Gary Kenward > Cc: Hemant.Chaskar@nokia.com; nsis@ietf.org; seamoby@ietf.org > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > Hello, > > well, if the issue is QoS establishment after handover, > > - CT is applicable for establishing QoS state at the AR > - if further signaling is desired beyond the AR, NSIS may > consider it. I don't see how _signaling_ for QoS establishment > beyond AR is relevant for seamoby. > > CAR _discovery_ could exchange QoS capability as one of the > parameters that might then be fed to a selection algorithm. Any > signaling for actually establishing QoS itself beyond the AR > should be outside the scope of seamoby.. > > Regards, > > -Rajeev > > Gary Kenward wrote: > > > > > > > Hemant: > > > > Just a point of clarification, but as I understand CARD (and > > I don't understand it well), it is not a QoS negotiation > > protocol. The main application that you are referring to primarily > > arises out of a perceived need to determine at the MN the best link > > layer to handover over to when inter-technology handovers are > > involved. > > It can be applied to intra-technology handovers, but the value in > > that situation is highly questionable (e.g. since it is a discovery > > protocol, the implication is that the purpose is to determine the > > choice of channels available; for intra-technology handovers, there > > are many, many reasons why this "choice" may not be available). > > > > There is a requirement, 5.1.2, which seems to imply NSIS involvement > > > > during/after a handover. John has stated that this is not the > > intention > > (please correct me if I have this wrong John), in which case I think > > 5.1.2 needs to be clarified. > > > > Specifically, is NSIS to be used to negotiated new QoS for an > > existing flow after a handover, or is it specifically for establishing > > > > QoS for a new flow? I don't think the answer is boolean: the role > > of NSIS in QoS re-negotiation is still open, I believe, and clearly > > handover is a dynamic situation that could cause the QoS provided to > > change. > > > > I have been told there is no issue, but here's a frightening > > scenario: > > > > - a handover takes place, and context transfer has been used > > to > > move the QoS context to the new routers (by the requirements > > for > > CT this could be intra-, or inter- technology. Some of us > > believe > > that for "seamless" handovers, the context will be available at > > > > routers before the first packets need to be forwarded. This > > implies > > that there is a relationship, probabilistic perhaps, between > > the handover process and the target ARs for CT. > > > > - CARD is used by the MN to influence the handover decision (it > > is not clear to me how this happens, but it seems clear that > > for a more "seamless" handover, the MN should chose an AR that > > has received the appropriate context; if not, then what? > > > > - NSIS kicks in and starts re-negotiating QoS because of changes > > introduced by the handover; > > > > How do these three protocols interact to produce predictable > > outcomes? > > Or, perhaps, the question is, how do the functional entities > > associated > > with the three protocols interact before, during and after a handover? > > > > If it the interaction is within the functional entities, the > > respective > > wg's could declare the issue out of scope, but this approach does not > > sit well with me, for it seems to defer the problem to the people who > > have to implement this "stuff". > > > > Am I imagining things? > > > > Cheers, > > Gary > > > > > -----Original Message----- > > > From: Hemant.Chaskar@nokia.com [mailto:Hemant.Chaskar@nokia.com] > > > Sent: April 4, 2002 22:33 > > > To: nsis@ietf.org > > > Subject: RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > Hi Sharif: > > > > > > There is currently a debate going on in Seamoby as to whether > > > this QoS negotiation be covered by NSIS or Seamoby (CAR > > > discovery protocol). > > > > > > IMHO it should be covered by CAR discovery and not NSIS. CAR > > > discovery is supposed to identify candidate access routers > > > for handoff and QoS is an important property for candidacy. > > > > > > Br, > > > Hemant > > > > > > -----Original Message----- > > > From: ext Shahrier, Sharif M. > > > [mailto:Sharif.Shahrier@InterDigital.com] > > > Sent: Thursday, April 04, 2002 3:35 PM > > > To: Shahrier, Sharif M. > > > Cc: 'nsis@ietf.org' > > > Subject: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > I have a question for clarification. > > > > > > I think it was stated that NSIS should only be concerned with the > > > establishment of QoS after handoff. > > > > > > This is inconvienent with respect to IP-level QoS > > > negotiation, which ideally > > > should be done before handoff has taken place. > > > > > > QoS negotiation is in the current requirements draft. > > > > > > So, NSIS signaling protocol development should be concerned > > > with activity > > > before handoff occurs. > > > > > > Sharif. > > > > > > > > > > > > _______________________________________________ > > > 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 > > > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Apr 5 21:48:53 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19397 for ; Fri, 5 Apr 2002 21:48:53 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA14420 for nsis-archive@odin.ietf.org; Fri, 5 Apr 2002 21:49:00 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA14254; Fri, 5 Apr 2002 21:44:13 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA14174 for ; Fri, 5 Apr 2002 21:44:07 -0500 (EST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19181 for ; Fri, 5 Apr 2002 21:44:00 -0500 (EST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id SAA16162 for ; Fri, 5 Apr 2002 18:43:34 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g362hVV19364; Fri, 5 Apr 2002 18:43:31 -0800 X-mProtect: <200204060243> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (172.18.5.175, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdnEndtu; Fri, 05 Apr 2002 18:43:27 PST Message-ID: <3CAE60C9.2090809@iprg.nokia.com> Date: Fri, 05 Apr 2002 18:43:22 -0800 From: Cedric Westphal User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: john.loughney@nokia.com CC: Hemant.Chaskar@nokia.com, nsis@ietf.org Subject: Re: [NSIS] Establishing QoS after handoff. References: <0C1353ABB1DEB74DB067ADFF749C4EEFD8E5E5@esebe004.NOE.Nokia.com> Content-Type: multipart/alternative; boundary="------------050703010404060606070901" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org --------------050703010404060606070901 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit John, just one question: john.loughney@nokia.com wrote: >Hi all, > >Just to follow on to Hemant's comment: > >>There is currently a debate going on in Seamoby as to whether >>this QoS negotiation be covered by NSIS or Seamoby (CAR >>discovery protocol). >> >>IMHO it should be covered by CAR discovery and not NSIS. CAR >>discovery is supposed to identify candidate access routers >>for handoff and QoS is an important property for candidacy. >> > >CAR discovery may be used to select handoff targets with >correct QoS support / capabilities. Context Transfer (CT) >can be used with the handoff procedure to ensure proper >QoS state gets transfered to the new access router. > how does the CAR know whether or not it is able to provide the QoS for the flows of the MN. If the question is QoS on the MN-CAR link, then it is easy, but what if the question is on the CAR-CN side? It seems to me that in Seamoby, both CARD and CT could act as triggers to NSIS (QI I guess). CARD to assess whether the CAR-CN is available, using NSIS as a probing mechanism, and CT to make the NAR-CN QoS re-establishment. > > >If there is anyone interested in this work, please let me >know. The SeaMoby chairs asked me to see if NSIS can provide >them any information about QoS needs. > Then both CARD and CT would need NSIS input/interaction... Cheers, Cedric. > > >thanks, >John > >_______________________________________________ >nsis mailing list >nsis@ietf.org >https://www1.ietf.org/mailman/listinfo/nsis > --------------050703010404060606070901 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit John,

just one question:

john.loughney@nokia.com wrote:
Hi all,

Just to follow on to Hemant's comment:

There is currently a debate going on in Seamoby as to whether 
this QoS negotiation be covered by NSIS or Seamoby (CAR 
discovery protocol). 

IMHO it should be covered by CAR discovery and not NSIS. CAR 
discovery is supposed to identify candidate access routers 
for handoff and QoS is an important property for candidacy. 

CAR discovery may be used to select handoff targets with
correct QoS support / capabilities.  Context Transfer (CT)
can be used with the handoff procedure to ensure proper
QoS state gets transfered to the new access router.

how does the CAR know whether or not it is able to provide the QoS
for the flows of the MN. If the question is QoS on the MN-CAR link,
then it is easy, but what if the question is on the CAR-CN side?

It seems to me that in Seamoby, both CARD and CT could act as triggers
to NSIS (QI I guess). CARD to assess whether the CAR-CN is available,
using NSIS as a probing mechanism, and CT to make the NAR-CN QoS
re-establishment.


If there is anyone interested in this work, please let me
know.  The SeaMoby chairs asked me to see if NSIS can provide
them any information about QoS needs.
Then both CARD and CT would need NSIS input/interaction...
Cheers,

Cedric.


thanks,
John

_______________________________________________
nsis mailing list
nsis@ietf.org
https://www1.ietf.org/mailman/listinfo/nsis

--------------050703010404060606070901-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Sun Apr 7 23:32:03 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06264 for ; Sun, 7 Apr 2002 23:32:02 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id XAA23936 for nsis-archive@odin.ietf.org; Sun, 7 Apr 2002 23:32:04 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA23296; Sun, 7 Apr 2002 23:26:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA23238 for ; Sun, 7 Apr 2002 23:26:20 -0400 (EDT) Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05870 for ; Sun, 7 Apr 2002 23:26:15 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g383RGJ02906 for ; Mon, 8 Apr 2002 06:27:16 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 8 Apr 2002 06:26:16 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Mon, 8 Apr 2002 06:26:16 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DEAD.24370A87" Subject: RE: [NSIS] Establishing QoS after handoff. Date: Mon, 8 Apr 2002 06:26:16 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD8E64E@esebe004.NOE.Nokia.com> Thread-Topic: [NSIS] Establishing QoS after handoff. Thread-Index: AcHcwfcmaDvrZeSoSE+QxAr1bxe5YQBoFL4g To: , , X-OriginalArrivalTime: 08 Apr 2002 03:26:16.0561 (UTC) FILETIME=[24779610:01C1DEAD] Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C1DEAD.24370A87 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Gary, =20 Actually, it could be either - I'm suggesting folks write an individual=20 draft on the subject. =20 =20 John -----Original Message----- From: ext Gary Kenward [mailto:gkenward@nortelnetworks.com] Sent: 05 April, 2002 19:08 To: Loughney John (NRC/Helsinki); Chaskar Hemant (NRC/Boston); = nsis@ietf.org Subject: RE: [NSIS] Establishing QoS after handoff. John:=20 Sorry, I may be just thick between the ears, but did you mean=20 "QoS needs" or "QoS signalling needs"????=20 Gary=20 > -----Original Message-----=20 > From: john.loughney@nokia.com [ mailto:john.loughney@nokia.com]=20 > Sent: April 4, 2002 23:28=20 > To: Hemant.Chaskar@nokia.com; nsis@ietf.org=20 > Subject: RE: [NSIS] Establishing QoS after handoff.=20 >=20 >=20 > Hi all,=20 >=20 > Just to follow on to Hemant's comment:=20 >=20 > > There is currently a debate going on in Seamoby as to whether=20 > > this QoS negotiation be covered by NSIS or Seamoby (CAR=20 > > discovery protocol).=20 > >=20 > > IMHO it should be covered by CAR discovery and not NSIS. CAR=20 > > discovery is supposed to identify candidate access routers=20 > > for handoff and QoS is an important property for candidacy.=20 >=20 > CAR discovery may be used to select handoff targets with=20 > correct QoS support / capabilities. Context Transfer (CT)=20 > can be used with the handoff procedure to ensure proper=20 > QoS state gets transfered to the new access router.=20 >=20 > If there is anyone interested in this work, please let me=20 > know. The SeaMoby chairs asked me to see if NSIS can provide=20 > them any information about QoS needs.=20 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^=20 >=20 > thanks,=20 > John=20 >=20 > _______________________________________________=20 > nsis mailing list=20 > nsis@ietf.org=20 > https://www1.ietf.org/mailman/listinfo/nsis=20 >=20 ------_=_NextPart_001_01C1DEAD.24370A87 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [NSIS] Establishing QoS after handoff.
Hi=20 Gary,
 
Actually, it could be either - I'm suggesting folks write an = individual=20
draft=20 on the subject. 
 
John
-----Original Message-----
From: ext Gary Kenward=20 [mailto:gkenward@nortelnetworks.com]
Sent: 05 April, 2002=20 19:08
To: Loughney John (NRC/Helsinki); Chaskar Hemant = (NRC/Boston);=20 nsis@ietf.org
Subject: RE: [NSIS] Establishing QoS after=20 handoff.

John:

  Sorry, I may be just thick between the ears, = but did=20 you mean
"QoS needs" or "QoS signalling=20 needs"????

Gary

> -----Original Message-----
>=20 From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]=20
> Sent: April 4, 2002 23:28
>=20 To: Hemant.Chaskar@nokia.com; nsis@ietf.org
>=20 Subject: RE: [NSIS] Establishing QoS after handoff.
>
>
> Hi=20 all,
>
> = Just to follow=20 on to Hemant's comment:
> =
> > There is currently a debate going on in Seamoby as = to whether=20
> > this QoS negotiation be covered by = NSIS or=20 Seamoby (CAR
> > discovery protocol).=20
> >
> = > IMHO it=20 should be covered by CAR discovery and not NSIS. CAR
> > discovery is supposed to identify candidate access = routers=20
> > for handoff and QoS is an = important property=20 for candidacy.
>
> CAR=20 discovery may be used to select handoff targets with
> correct QoS support / capabilities.  Context = Transfer=20 (CT)
> can be used with the handoff = procedure to=20 ensure proper
> QoS state gets transfered = to the=20 new access router.
>
>=20 If there is anyone interested in this work, please let me =
> know.  The SeaMoby chairs asked me to see if NSIS = can=20 provide
> them any information about QoS=20 needs.
 =20 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>=20
> thanks,
> = John=20
>
>=20 _______________________________________________
>=20 nsis mailing list
> nsis@ietf.org =
> https://www1.ietf.or= g/mailman/listinfo/nsis=20
>

------_=_NextPart_001_01C1DEAD.24370A87-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Sun Apr 7 23:32:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06268 for ; Sun, 7 Apr 2002 23:32:02 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id XAA23942 for nsis-archive@odin.ietf.org; Sun, 7 Apr 2002 23:32:04 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA23232; Sun, 7 Apr 2002 23:26:18 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA23201 for ; Sun, 7 Apr 2002 23:26:14 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05867 for ; Sun, 7 Apr 2002 23:26:11 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g383QS516020 for ; Mon, 8 Apr 2002 06:26:29 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 8 Apr 2002 06:26:13 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Mon, 8 Apr 2002 06:26:13 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] Co-ordination work between NSIS and IEEE 802.11 TG-E Date: Mon, 8 Apr 2002 06:26:12 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD8E64D@esebe004.NOE.Nokia.com> Thread-Topic: [NSIS] Co-ordination work between NSIS and IEEE 802.11 TG-E Thread-Index: AcHc5EN3qVwD41QkRrKdcLMsmU06uQBfbzEw To: , X-OriginalArrivalTime: 08 Apr 2002 03:26:13.0025 (UTC) FILETIME=[225C0910:01C1DEAD] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id XAA23202 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Sharif, Chair hat on, I think it is good to encourage discussion between the IETF & other bodies (like the IEEE). I am not active in the IEEE, but I would encourage those who are to try to open a dialog. John > -----Original Message----- > From: ext Shahrier, Sharif M. > [mailto:Sharif.Shahrier@InterDigital.com] > Sent: 05 April, 2002 23:54 > To: Shahrier, Sharif M.; nsis@ietf.org > Subject: [NSIS] Co-ordination work between NSIS and IEEE 802.11 TG-E > > > > I wanted to put this out as a topic of discussion, as a possible joint > co-ordinated work between NSIS and IEEE 802.11 TG-E. > > TG-E have been tasked with enhancing the 802.11 MAC to > improve and manage > QoS. I am not sure what is the current status of this work, perhaps > participants to TG-E can provide some information. > > I believe an important study item is to figure out how QoS signaling > protocols from TG-E should interact with NSIS QoS signaling protocols. > > I am aware that SEAMOBY has presented a case to TG-F where 802.11 ESS > infrastructure networks could be connected together with a > router(s) in > between. How to interwork IAPP with IETF's handover protocol > was the topic. > > I would assume that L2 QoS signaling would terminate at the > AP, and further > signaling would then be needed to transport QoS parameters across > interconnected router(s). This signaling would subsequently > terminate at the > destination AP, where L2 signaling is again used. The middle > part, i.e. > transport of QoS parameters across disparate QoS domain is NSIS. > > Thus, as a study: > > - need to determine how and which L2 parameters need to be extracted. > - How to transform and map them to L3 parameters for sinaling > - How the two signaling protocols should interact. > > I think it is worthwhile to present a case for this to TG-E > at the Vancouver > Plenary. > > Any interest and comments would be appreciated. > > Sharif. > > _______________________________________________ > 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 daemon@optimus.ietf.org Mon Apr 8 00:18:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06270 for ; Sun, 7 Apr 2002 23:32:03 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id XAA23933 for nsis-archive@odin.ietf.org; Sun, 7 Apr 2002 23:32:04 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA23323; Sun, 7 Apr 2002 23:26:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA23243 for ; Sun, 7 Apr 2002 23:26:20 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05872 for ; Sun, 7 Apr 2002 23:26:17 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g383QZ516057 for ; Mon, 8 Apr 2002 06:26:35 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 8 Apr 2002 06:26:19 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Mon, 8 Apr 2002 06:26:19 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] Establishing QoS after handoff. Date: Mon, 8 Apr 2002 06:26:18 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD8E64F@esebe004.NOE.Nokia.com> Thread-Topic: [NSIS] Establishing QoS after handoff. Thread-Index: AcHdFNjRIvH1hfmnSHGxKGAI6NjMCwBTcERQ To: Cc: , X-OriginalArrivalTime: 08 Apr 2002 03:26:19.0358 (UTC) FILETIME=[26225FE0:01C1DEAD] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id XAA23244 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Cedric > how does the CAR know whether or not it is able to provide the QoS > for the flows of the MN. If the question is QoS on the MN-CAR link, > then it is easy, but what if the question is on the CAR-CN side? I've always considered that CAR would work on the capabilities at the AR. So, in the scenario, the AR could know if it had the capabilities to support an additional 'connection' at the QoS level. That's all I meant. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon Apr 8 02:45:52 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16373 for ; Mon, 8 Apr 2002 02:45:48 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA12891 for nsis-archive@odin.ietf.org; Mon, 8 Apr 2002 02:45:50 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA12609; Mon, 8 Apr 2002 02:41:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA12574 for ; Mon, 8 Apr 2002 02:40:59 -0400 (EDT) Received: from mail1.telekom.de (mail1.telekom.de [62.225.183.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16274 for ; Mon, 8 Apr 2002 02:40:56 -0400 (EDT) Received: from g8pbq.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Mon, 8 Apr 2002 08:39:06 +0200 Received: by G8PBQ.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Mon, 8 Apr 2002 08:40:25 +0200 Message-Id: From: "Geib, Ruediger" To: gkenward@nortelnetworks.com, Alban.Couturier@alcatel.fr, bless@tm.uka.de Cc: nsis@ietf.org Subject: RE: pre-emption (was RE: [NSIS] proposals related to NSIS WG draf t) Date: Mon, 8 Apr 2002 08:40:18 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id CAA12575 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Dear preemption discussion group, if NSIS is ought to provide a universal service establishment protocol and preemption/priority is orthogonal to QoS and a local matter, why then not to separate signaling? The idea is to have one NSIS message set signaling QoS and another one to signal preemption (should signaling be required to support priority/preemption). An example: - a roaming customer may learn by a policy enquiry whether and how QoS and/or priority are supported locally. - in a "set up" message, QoS reservation information may be joined by piggy backed priority information if it is related to the same reservation ID (otherwise the priority information may be sent with it's own set up message, always carrying a reservation ID of the prior service reservation it is related to). - The mechanism would work also across domains not supporting priority if the priority TLV is marked as "discard/ignore if you don't understand" or the local provider discards it at its border. Please take the example only as clarification of the basic idea. I'm not suggesting to follow exactly this solution. Regards, Rüdiger Rüdiger Geib Senior Expert T-Systems Nova GmbH Technologiezentrum Am Kavalleriesand 3, 64295 Darmstadt Germany Fon: +49 6151 832138 Fax: +49 6151 838103 mailto:Ruediger.Geib@t-systems.com http://www.t-nova.de _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon Apr 8 04:23:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17661 for ; Mon, 8 Apr 2002 04:23:41 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA18457 for nsis-archive@odin.ietf.org; Mon, 8 Apr 2002 04:23:44 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA18246; Mon, 8 Apr 2002 04:19:40 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA18211 for ; Mon, 8 Apr 2002 04:19:36 -0400 (EDT) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17622 for ; Mon, 8 Apr 2002 04:19:30 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g388Igu01721 for ; Mon, 8 Apr 2002 11:18:42 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 8 Apr 2002 11:19:32 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Mon, 8 Apr 2002 11:19:32 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] On the definition of QoS flow and aggregate flow. Date: Mon, 8 Apr 2002 11:19:31 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64E01@esebe004.NOE.Nokia.com> Thread-Topic: [NSIS] On the definition of QoS flow and aggregate flow. Thread-Index: AcHcudQi3zDV73YGTCibWUJmJB9g5gCHAZJg To: Cc: X-OriginalArrivalTime: 08 Apr 2002 08:19:32.0353 (UTC) FILETIME=[1C605F10:01C1DED6] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id EAA18212 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Gary, > Perhaps I am missing an important issue here with the semantics of a QoS > control protocol, but given the scope of the requirements, I see NSIS as > being more of a container protocol then an SS7 or UNI protocol. This allows > NSIS to be used in a variety of network implementations. I am on the same page as you are with this. We are not designing a solution for a particular network or sevice. To be successful, we need to work on a general solution. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon Apr 8 04:23:42 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17677 for ; Mon, 8 Apr 2002 04:23:42 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA18471 for nsis-archive@odin.ietf.org; Mon, 8 Apr 2002 04:23:45 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA17996; Mon, 8 Apr 2002 04:17:22 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA17961 for ; Mon, 8 Apr 2002 04:17:19 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17573 for ; Mon, 8 Apr 2002 04:17:15 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g388HW504373 for ; Mon, 8 Apr 2002 11:17:33 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 8 Apr 2002 11:17:17 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Mon, 8 Apr 2002 11:17:16 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Mon, 8 Apr 2002 11:17:16 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64E00@esebe004.NOE.Nokia.com> Thread-Topic: [NSIS] Preemption Thread-Index: AcHcwWpmD4KSewfMRLy0SIyLoOWYJwCFAaLA To: , X-OriginalArrivalTime: 08 Apr 2002 08:17:16.0764 (UTC) FILETIME=[CB8F21C0:01C1DED5] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id EAA17962 Subject: [NSIS] NSIS Scoping (was Preemption) Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi James, Clarification of NSIS's scope: > If NSIS wants to migrate any of these networks over to IP, or be part of > any migration or transition, preemption ought to be defined the WG, albeit > as an option - with specifics surrounding that/those options. NSIS is not working on migrating any networks to IP. What NSIS will (hopefully) do is create a signaling framework/protocol that can be used to signal QoS. This work may be useful for some network designers who want to provide capabilities similar to other networks, but doing this is not NSIS's primary goal. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon Apr 8 04:24:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17694 for ; Mon, 8 Apr 2002 04:24:00 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA18490 for nsis-archive@odin.ietf.org; Mon, 8 Apr 2002 04:24:03 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA18427; Mon, 8 Apr 2002 04:22:52 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA18398 for ; Mon, 8 Apr 2002 04:22:49 -0400 (EDT) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17644 for ; Mon, 8 Apr 2002 04:22:45 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g388Lsu03329 for ; Mon, 8 Apr 2002 11:21:54 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 8 Apr 2002 11:22:39 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Mon, 8 Apr 2002 11:22:39 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] Establishing QoS after handoff. Date: Mon, 8 Apr 2002 11:22:38 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64E04@esebe004.NOE.Nokia.com> Thread-Topic: [NSIS] Establishing QoS after handoff. Thread-Index: AcHc3tqEoSBErGrFQ4GXEwx7hHM0qQB95upQ To: , X-OriginalArrivalTime: 08 Apr 2002 08:22:39.0282 (UTC) FILETIME=[8BCB7920:01C1DED6] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id EAA18399 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Sharif, > So you are saying that CARD may perform QoS negotiation (if > necessary) between ARs when selecting handoff targets? What I think would be useful would be for interested parties to study this & see if one way would be more useful than another. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon Apr 8 04:24:09 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17711 for ; Mon, 8 Apr 2002 04:24:08 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA18506 for nsis-archive@odin.ietf.org; Mon, 8 Apr 2002 04:24:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA18293; Mon, 8 Apr 2002 04:20:33 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA18268 for ; Mon, 8 Apr 2002 04:20:31 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17626 for ; Mon, 8 Apr 2002 04:20:27 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g388Ki507385 for ; Mon, 8 Apr 2002 11:20:44 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 8 Apr 2002 11:20:28 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Mon, 8 Apr 2002 11:20:28 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: pre-emption (was RE: [NSIS] proposals related to NSIS WGdraf t) Date: Mon, 8 Apr 2002 11:20:28 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64E02@esebe004.NOE.Nokia.com> Thread-Topic: pre-emption (was RE: [NSIS] proposals related to NSIS WGdraf t) Thread-Index: AcHckFYuIxGA/8kuSyqbTG7a32VB4gCRdvoQ To: , , , Cc: X-OriginalArrivalTime: 08 Apr 2002 08:20:28.0524 (UTC) FILETIME=[3DDB62C0:01C1DED6] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id EAA18269 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Marcus, > We are not talking about priority of data traffic overothers, > but on the case of the capacity already completly give away and a new > service request arriving. One can then specify, whether it is possible to preempt > guaranteed reservations. > > I would like see whether this is worth a reqirement. I don't support this requirement. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon Apr 8 04:34:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17900 for ; Mon, 8 Apr 2002 04:34:46 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA19510 for nsis-archive@odin.ietf.org; Mon, 8 Apr 2002 04:34:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA18816; Mon, 8 Apr 2002 04:30:19 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA18779 for ; Mon, 8 Apr 2002 04:30:15 -0400 (EDT) Received: from tms002bb.han.telia.se (tms002bb.han.telia.se [131.115.230.133]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17841 for ; Mon, 8 Apr 2002 04:30:11 -0400 (EDT) From: Anders.P.Bergsten@telia.se Received: from TMS041MB.tcad.telia.se ([131.115.230.167]) by tms002bb.han.telia.se with Microsoft SMTPSVC(5.0.2195.2966); Mon, 8 Apr 2002 10:30:04 +0200 content-class: urn:content-classes:message Subject: RE: pre-emption (was RE: [NSIS] proposals related to NSIS WGdraf t) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Mon, 8 Apr 2002 10:30:04 +0200 Message-ID: <1BF8A5964E4EFA41A094B835FCA7129110CC05@TMS041MB.tcad.telia.se> Thread-Topic: pre-emption (was RE: [NSIS] proposals related to NSIS WGdraf t) Thread-Index: AcHckFYuIxGA/8kuSyqbTG7a32VB4gCRdvoQAAAaVRA= To: , , , , Cc: X-OriginalArrivalTime: 08 Apr 2002 08:30:04.0509 (UTC) FILETIME=[952BB8D0:01C1DED7] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id EAA18780 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit John, How do you plan to deal with 112(911)-calls in this case? There are sometimes regulation (if I remember correctly) that require a network to support that a 112-call always gets delivered. My concern regarding preemption is this single instance - if this is solved it is fine by me. Ie I do not see the need for a generic pre-emption mechanism. I think a combination of randomness and planning (for mobile handoffs) gives suitable behaviour. Anders > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: den 8 april 2002 10:20 > To: brunner@ccrle.nec.de; gkenward@nortelnetworks.com; > Ruediger.Geib@t-systems.com; svenvandenbosch@hotmail.com > Cc: nsis@ietf.org > Subject: RE: pre-emption (was RE: [NSIS] proposals related to NSIS > WGdraf t) > > > Hi Marcus, > > > We are not talking about priority of data traffic overothers, > > but on the case of the capacity already completly give away > and a new > > service request arriving. One can then specify, whether it > is possible to preempt > > guaranteed reservations. > > > > I would like see whether this is worth a reqirement. > > I don't support this requirement. > > John > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon Apr 8 04:37:42 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17941 for ; Mon, 8 Apr 2002 04:37:41 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA19687 for nsis-archive@odin.ietf.org; Mon, 8 Apr 2002 04:37:44 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA19245; Mon, 8 Apr 2002 04:31:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA17826 for ; Mon, 8 Apr 2002 04:15:12 -0400 (EDT) Received: from nero.informatik.uni-wuerzburg.de (root@wi3x05.informatik.uni-wuerzburg.de [132.187.106.5]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17568; Mon, 8 Apr 2002 04:14:54 -0400 (EDT) Received: from PROMETHEUS (prometheus.informatik.uni-wuerzburg.de [132.187.106.139]) by nero.informatik.uni-wuerzburg.de (8.11.3/8.11.3/SuSE Linux 8.11.1-0.5) with SMTP id g388EVH27984; Mon, 8 Apr 2002 10:14:31 +0200 Message-ID: <002201c1ded6$4d306770$8b6abb84@PROMETHEUS> From: "Kurt Tutschku" To: "mpls \(ietf\)" , "sigtran \(ietf\)" , "end2end \(irtf\)" , "ITC list" , "nsis \(ietf\)" , "cost 279" , "ppvpn \(ietf\)" , "University of Central Florida" , "ITG Fachtagung Messung, Modellierung und Bewertung" , "ITG 524" , "ITG 523" , "ITG 521" , "ipo \(ietf\)" , "tewg \(ietf\)" , "ippm \(ietf\)" , "mobileip \(ietf\)" , "manet \(ietf\)" , "nmrg \(irtf\)" , "rr \(irtf\)" , "ccamp \(ietf\)" , "ipv6 \(ietf\)" , "disman \(ietf\)" , =?iso-8859-1?Q?Paul_Schl=FCter?= , "Notker Gerlich" , "Hans Schwefel" , "Thomas Reim" , "Stefan Schneeberger" , "Michael Schopp" , "Franz Hartleb" , "Klaus Dolzer" , "Bart Sanders" , =?iso-8859-1?Q?Michael_S=F6llner?= , "Wolfgang Wagner" , "Walter Leonhardt" , "Norbert Rauh" , =?iso-8859-1?Q?Silvia_Sch=E4ffler?= , "Wolfgang Stegmann" , "Andreas Lamsa" , "Karl Heinz Allgeyer" , "Lothar Lux" , =?iso-8859-1?Q?Bernd_Schr=F6der?= , "Albert Weller" , =?iso-8859-1?Q?J=FCrgen_Tenckhoff?= , "Norbert Schultze" , =?iso-8859-1?Q?Norbert_Schl=FCter?= , "Laslo Slawitschka" , "Gabriel Zgunea" , "Bernhard Liesenfeld" , =?iso-8859-1?Q?J=FCrgen_Beyer?= , "Zhongrong Liu" , "Bernd Pfeiffer" , "Hans Barth" , "Wolf Mende" , "Wolfgang Urmoneit" , "Dieter Marger" , "Charles E. Perkins" , "Ake Arvidsson" , =?iso-8859-1?Q?Angelika_M=FCller?= , "Armin Heindl" , "Bo Friis Nielsen" , "Holger Hermanns" , "Jacques Resing" , "Jose Brazio" , "Stephen Hanly" , "Stefanie" , "Matthew Roughan" , "Reinhard German" , "Rudolf Mathar" , "Ulrich Herzog" , "Dieter Baum" , "Lothar Breuer" , "Marie-Ange Remiche" , "Markus Siegle" , "Nikhil Jain" , "Peter Taylor" , "Sem Borst" , "Ute Kohlhaas" Date: Mon, 8 Apr 2002 10:20:35 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001F_01C1DEE7.058B2020" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 x-mimeole: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: [NSIS] Reminder 15th ITC Specialist Seminar on Internet Traffic Engineering and Traffic Management (ITC 2002) Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_001F_01C1DEE7.058B2020 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear colleagues, we kindly remind you of the upcoming Full Paper Submission Deadline on = April 22, 2002 and ask you to help us distributing the Call for Papers = in order to attract as many interested authors and participants as = possible. Thank you for your support Kurt Tutschku (We apologize for multiple copies you might have received.) -------------------------------------------------------------------------= - Call for Papers: 15th ITC Specialist Seminar "Internet Traffic = Engineering and Traffic Management"=20 = -------------------------------------------------------------------------= - Dear colleagues,=20 we'd like to announce proudly an upcoming ITC Specialist Seminar:=20 =20 15th ITC Specialist Seminar: Internet Traffic Engineering and Traffic = Management, July 22-24 2002, Wuerzburg, Germany.=20 The Technical Program Committee of the seminar is chaired by Prof. James = Roberts and Prof. Phuoc Tran-Gia We'd like to invite you to submit original full papers until April 22, = 2002. You will find a detailed Call for Papers at:=20 http://itc.informatik.uni-wuerzburg.de/=20 http://www.itcspecialistseminar.com/=20 Best Regards=20 Phuoc Tran-Gia (Seminar Co-Chair)=20 Jim Roberts (Seminar Co-Chair)=20 Kurt Tutschku (Organizing Committee Chair)=20 ------=_NextPart_000_001F_01C1DEE7.058B2020 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dear colleagues,
 
we kindly remind you of the upcoming = Full Paper=20 Submission Deadline on April 22, 2002 and ask you to help us = distributing the=20 Call for Papers in order to attract as many interested authors=20 and participants as possible.
 
Thank you for your support
Kurt Tutschku
 
(We apologize for multiple copies you = might have=20 received.)
 
----------------------------------------------------------------= ----------
Call=20 for Papers: 15th ITC Specialist Seminar "Internet Traffic Engineering = and=20 Traffic Management"=20
 ---------------------------------------------------------------= -----------
 
Dear colleagues,
 
we'd like to announce proudly an = upcoming ITC=20 Specialist Seminar:
  
15th ITC Specialist Seminar: = Internet=20 Traffic Engineering and Traffic Management, July 22-24 2002, Wuerzburg, = Germany.=20
 
The Technical Program Committee of the = seminar is=20 chaired by Prof. James Roberts and Prof. Phuoc Tran-Gia
 
We'd like to invite you to submit = original full=20 papers until April 22, 2002. You will find a detailed Call for Papers = at:=20
 
http://itc.informatik.un= i-wuerzburg.de/=20
http://www.itcspecialistsem= inar.com/=20
 
Best Regards
Phuoc Tran-Gia = (Seminar Co-Chair)=20
Jim Roberts (Seminar Co-Chair)
Kurt Tutschku (Organizing = Committee=20 Chair)
 
 
------=_NextPart_000_001F_01C1DEE7.058B2020-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon Apr 8 04:37:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17956 for ; Mon, 8 Apr 2002 04:37:57 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA19703 for nsis-archive@odin.ietf.org; Mon, 8 Apr 2002 04:38:01 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA19566; Mon, 8 Apr 2002 04:35:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA19535 for ; Mon, 8 Apr 2002 04:35:07 -0400 (EDT) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17914 for ; Mon, 8 Apr 2002 04:34:49 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g388Y0u09819 for ; Mon, 8 Apr 2002 11:34:01 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 8 Apr 2002 11:34:51 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Mon, 8 Apr 2002 11:34:51 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: pre-emption (was RE: [NSIS] proposals related to NSIS WGdraf t) Date: Mon, 8 Apr 2002 11:34:49 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64E08@esebe004.NOE.Nokia.com> Thread-Topic: pre-emption (was RE: [NSIS] proposals related to NSIS WGdraf t) Thread-Index: AcHckFYuIxGA/8kuSyqbTG7a32VB4gCRdvoQAAAaVRAAAEMrsA== To: Cc: X-OriginalArrivalTime: 08 Apr 2002 08:34:51.0130 (UTC) FILETIME=[40029DA0:01C1DED8] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id EAA19537 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Anders, > How do you plan to deal with 112(911)-calls in this case? > There are sometimes regulation (if I remember correctly) that > require a network to support that a 112-call always gets delivered. I don't see emergency calls listed anywhere in our charter. This is outside of the scope, in my opinion. There is a working group focusing on this issue: http://www.ietf.org/html.charters/ieprep-charter.html In Minneapolis, I chatted with one of ADs about the applicability of NSIS for Internet Emergency Preparedness work, and he felt that NSIS was very applicable. My feeling is that he (as AD) will not let us go down the wrong road, however. Again, however, NSIS is not chartered to work on services, and at the end of the day, emergency calls are a service. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon Apr 8 04:53:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18148 for ; Mon, 8 Apr 2002 04:53:01 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA20201 for nsis-archive@odin.ietf.org; Mon, 8 Apr 2002 04:53:05 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA20054; Mon, 8 Apr 2002 04:49:51 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA19974 for ; Mon, 8 Apr 2002 04:49:46 -0400 (EDT) Received: from tms002bb.han.telia.se (tms002bb.han.telia.se [131.115.230.133]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18126 for ; Mon, 8 Apr 2002 04:49:42 -0400 (EDT) From: Anders.P.Bergsten@telia.se Received: from TMS041MB.tcad.telia.se ([131.115.230.167]) by tms002bb.han.telia.se with Microsoft SMTPSVC(5.0.2195.2966); Mon, 8 Apr 2002 10:49:36 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: pre-emption (was RE: [NSIS] proposals related to NSIS WGdraf t) Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Mon, 8 Apr 2002 10:49:36 +0200 Message-ID: <1BF8A5964E4EFA41A094B835FCA7129110CC06@TMS041MB.tcad.telia.se> Thread-Topic: pre-emption (was RE: [NSIS] proposals related to NSIS WGdraf t) Thread-Index: AcHckFYuIxGA/8kuSyqbTG7a32VB4gCRdvoQAAAaVRAAAEMrsAAAJdIQ To: Cc: X-OriginalArrivalTime: 08 Apr 2002 08:49:36.0743 (UTC) FILETIME=[4FE06F70:01C1DEDA] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id EAA19975 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit John, not sure I understand, requesting resources for something is in charter, I persume. What I stated was: there is one instance where I see a need for pre-emption in signaling and this is related to emergency calls. The impact of this statement is that pre-emption have to be taken into account by NSIS - unless you find another way of solving the problem of making resources available for an "emergency call". I am definitely talking about a resource allocation / signaling problem and not the "emergency call" service. Thus in scope in my opinion. If somebody can invalidate this statement (ie implement this feature by not including information in the signaling message) then I suggest remove this requirement. If you can't then the requirement to support pre-emption has to be in the NSIS req. draft. Anders > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: den 8 april 2002 10:35 > To: Bergsten, Anders P. /Research /0920-754 50, 070-661 44 98 > Cc: nsis@ietf.org > Subject: RE: pre-emption (was RE: [NSIS] proposals related to NSIS > WGdraf t) > > > Hi Anders, > > > How do you plan to deal with 112(911)-calls in this case? > > There are sometimes regulation (if I remember correctly) that > > require a network to support that a 112-call always gets delivered. > > I don't see emergency calls listed anywhere in our charter. > This is outside of the scope, in my opinion. > > There is a working group focusing on this issue: > http://www.ietf.org/html.charters/ieprep-charter.html > > In Minneapolis, I chatted with one of ADs about the applicability > of NSIS for Internet Emergency Preparedness work, and he felt > that NSIS was very applicable. My feeling is that he (as AD) will > not let us go down the wrong road, however. > > Again, however, NSIS is not chartered to work on services, and > at the end of the day, emergency calls are a service. > > John > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon Apr 8 04:54:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18184 for ; Mon, 8 Apr 2002 04:54:58 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA20250 for nsis-archive@odin.ietf.org; Mon, 8 Apr 2002 04:55:01 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA20186; Mon, 8 Apr 2002 04:53:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA20157 for ; Mon, 8 Apr 2002 04:52:59 -0400 (EDT) Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18143 for ; Mon, 8 Apr 2002 04:52:53 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g388rtJ29757 for ; Mon, 8 Apr 2002 11:53:55 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 8 Apr 2002 11:52:54 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Mon, 8 Apr 2002 11:52:55 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: pre-emption (was RE: [NSIS] proposals related to NSIS WGdraf t) Date: Mon, 8 Apr 2002 11:52:54 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64E0A@esebe004.NOE.Nokia.com> Thread-Topic: pre-emption (was RE: [NSIS] proposals related to NSIS WGdraf t) Thread-Index: AcHckFYuIxGA/8kuSyqbTG7a32VB4gCRdvoQAAAaVRAAAEMrsAAAJdIQAACaV2A= To: Cc: X-OriginalArrivalTime: 08 Apr 2002 08:52:55.0215 (UTC) FILETIME=[C62CDBF0:01C1DEDA] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id EAA20158 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Anders, > not sure I understand, requesting resources for something is > in charter, I persume. What I stated was: there is one > instance where I see a need for pre-emption in signaling and > this is related to emergency calls. Should the protocol support pre-emption or should the network? My opinion is that it is network policy to determine how to do pre-emption, not a protocol issue. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon Apr 8 05:20:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18401 for ; Mon, 8 Apr 2002 05:20:42 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA21643 for nsis-archive@odin.ietf.org; Mon, 8 Apr 2002 05:20:45 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA21336; Mon, 8 Apr 2002 05:14:18 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA21306 for ; Mon, 8 Apr 2002 05:14:16 -0400 (EDT) Received: from tms001bb.han.telia.se (tms001bb.han.telia.se [131.115.230.132]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18323 for ; Mon, 8 Apr 2002 05:14:12 -0400 (EDT) From: Anders.P.Bergsten@telia.se Received: from TMS041MB.tcad.telia.se ([131.115.230.167]) by tms001bb.han.telia.se with Microsoft SMTPSVC(5.0.2195.2966); Mon, 8 Apr 2002 11:14:18 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: pre-emption (was RE: [NSIS] proposals related to NSIS WGdraf t) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Mon, 8 Apr 2002 11:14:18 +0200 Message-ID: <1BF8A5964E4EFA41A094B835FCA7129110CC07@TMS041MB.tcad.telia.se> Thread-Topic: pre-emption (was RE: [NSIS] proposals related to NSIS WGdraf t) Thread-Index: AcHckFYuIxGA/8kuSyqbTG7a32VB4gCRdvoQAAAaVRAAAEMrsAAAJdIQAACaV2AAACb74A== To: Cc: X-OriginalArrivalTime: 08 Apr 2002 09:14:18.0707 (UTC) FILETIME=[C3323230:01C1DEDD] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id FAA21307 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit > > Hi Anders, > > > not sure I understand, requesting resources for something is > > in charter, I persume. What I stated was: there is one > > instance where I see a need for pre-emption in signaling and > > this is related to emergency calls. > > Should the protocol support pre-emption or should the network? > > My opinion is that it is network policy to determine how to > do pre-emption, not a protocol issue. Thanks - you are correct, pre-emption is not a protocol issue but a "network" issue (I also read the latest emails on the topic). Thus, I am in favour of not having this as a (signaling) requirement. Anders _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon Apr 8 06:09:14 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19188 for ; Mon, 8 Apr 2002 06:09:12 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA24046 for nsis-archive@odin.ietf.org; Mon, 8 Apr 2002 06:09:16 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA23828; Mon, 8 Apr 2002 06:03:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA23793 for ; Mon, 8 Apr 2002 06:03:46 -0400 (EDT) Received: from iraun2.uka.de (iraun2.uka.de [129.13.10.91]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18913 for ; Mon, 8 Apr 2002 06:03:41 -0400 (EDT) Received: from irams1.ira.uka.de ([129.13.10.5]) by iraun2.uka.de with esmtp (Exim 3.30 #7 (Debian)) id 16uVzv-0006ow-00; Mon, 08 Apr 2002 12:03:39 +0200 Received: from i72pc127.tm.uni-karlsruhe.de ([141.3.70.78] helo=i72pc127.tm.uka.de) by irams1.ira.uka.de with esmtp (Exim 3.30 #7 (Debian)) id 16uVzu-0003uY-00; Mon, 08 Apr 2002 12:03:38 +0200 Received: from tpce10.ipv6.tm.uka.de (localhost [127.0.0.1]) by i72pc127.tm.uka.de (8.11.6/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id g38A3af16774; Mon, 8 Apr 2002 12:03:36 +0200 Message-Id: <200204081003.g38A3af16774@i72pc127.tm.uka.de> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4+dev To: Alban.Couturier@alcatel.fr cc: Gary Kenward , "'brunner@ccrle.nec.de'" , "Geib, Ruediger" , svenvandenbosch@hotmail.com, nsis@ietf.org Subject: Re: pre-emption (was RE: [NSIS] proposals related to NSIS WG draft) In-Reply-To: Message from Alban.Couturier@alcatel.fr of "Fri, 05 Apr 2002 18:57:41 +0200." <3CADD785.9CC48F1A@alcatel.fr> References: <9FBD322B7824D511B36900508BF93C9C01AA49C3@zcard031.ca.nortel.com> <3CADC6CB.1CD86E37@alcatel.fr> <200204051628.g35GSkf05197@i72pc127.tm.uka.de> <3CADD785.9CC48F1A@alcatel.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Date: Mon, 08 Apr 2002 12:03:36 +0200 From: Roland Bless Content-Transfer-Encoding: 8bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Alban, > My question is how can the provider know that a particular flow deserve > a higher priority when a user requests QoS? He should derive this from the service definition. > Sometimes a user want not to be prempted or really wants its request to > be satisfied because he calls his boss, or the police etc... Sometimes, > the same user wants a "regular" call or session, which implies that the > network may refuse it because there is in competition a call to 911 or a > session with a big boss. Agreed, but this refers to application-dependent priority. > So only the initiator could signal to the network that a session is > really more important than another. It's just a question of a I don't see how this may help the network provider, because you cannot assume an objective priority request from users (there are always some users who think they are (always) more important than others). If you only consider user suggested priority, how should the network know to prefer an emergency call before someone else's boss call when both requests had the highest possible signaled priority? Furthermore, how should the network decide that user A's boss is somehow more important (from A's view) than user B's call/boss? How should A set his priority to preempt B's call? > high/medium/normal tag in a request. The network could then accept this > priority, or not, depending on policy/user profile... In case of network > failure, the QoS controller could also react in order to reestablish the > high priority flows before the others. Given the possibility to signal a priority for reservations: how would you prevent (selfish/malicious) users to not always signal the highest possible priority? In this case the network must decide by other means what should be preempted anyway, so I don't see the benefit of a user signaled priority. Surely, the user may know the importance of his own flows, but then he can also tear down less important reservations before starting a new more important "call". > The only other solution i see could be to put this priority information > in the service description. But again, this type of solution mixes > admission control performed by the QoS controller, and the provisionning > of QoS. This lead to difficulties in network provisionning, or/and to a > poor design in the QoS controller that will be QSC dependant. I would suggest that this implied by the service. So one would have a special service for emergency calls, maybe a special service for "more important" (but also more expensive) premium calls and a service for regular calls (all three may even use the same QoS mechanisms, but admission control differs). Regards, Roland -- Roland Bless -- e-Mail: bless@tm.uka.de Institute of Telematics, University of Karlsruhe, Germany Zirkel 2, D-76128 Karlsruhe -- Office: Bld. 20.20, 3rd floor, R 358 Phone: +49 721 608-6413 Fax: +49 721 388097 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Mon Apr 8 11:52:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27753 for ; Mon, 8 Apr 2002 11:52:12 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA16547 for nsis-archive@odin.ietf.org; Mon, 8 Apr 2002 11:52:15 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA16014; Mon, 8 Apr 2002 11:45:35 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA15982 for ; Mon, 8 Apr 2002 11:45:32 -0400 (EDT) Received: from idcpa4.pa.interdigital.com (idcmail.interdigital.com [12.32.197.142]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27497 for ; Mon, 8 Apr 2002 11:45:29 -0400 (EDT) Received: by idcpa4.pa.interdigital.com with Internet Mail Service (5.5.2653.19) id <2PXHYRDT>; Mon, 8 Apr 2002 11:43:48 -0400 Message-ID: From: "Shahrier, Sharif M." To: nsis@ietf.org Subject: [NSIS] Using flow-ids as an alternative to QSC classes. Date: Mon, 8 Apr 2002 11:43:47 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Some people had recently suggested using flow-ids or some other already defined identifiers in place of QSC classes. I assume that there are RFCs that describe these things, and so would be grateful if someone could send me pointers to them. Thanks. Sharif. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Mon Apr 8 12:08:40 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28395 for ; Mon, 8 Apr 2002 12:08:40 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA18873 for nsis-archive@odin.ietf.org; Mon, 8 Apr 2002 12:08:43 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA16877; Mon, 8 Apr 2002 11:57:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA16840 for ; Mon, 8 Apr 2002 11:57:45 -0400 (EDT) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27928; Mon, 8 Apr 2002 11:57:41 -0400 (EDT) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g38FhFI18742; Mon, 8 Apr 2002 08:43:15 -0700 (PDT) Message-ID: <001a01c1df13$dfe0aa20$7e6015ac@T23KEMPF> From: "James Kempf" To: "Nakhjiri Madjid-MNAKHJI1" , "Rajeev Koodli" Cc: "Gary Kenward" , , , References: <35DBB8B7AC89D4118E98009027B1009B0465003E@IL27EXM10.cig.mot.com> Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Mon, 8 Apr 2002 08:41:39 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit Madjid, The issue isn't reliability, it is whether the target AR can interpret the context intelligably. If not, the MN may need to recover by actually re-initializing whatever feature the context was being transfered for. But it cannot do this unless it knows that the CT has failed. For some feature contexts, like header compression, this isn't a problem because it will re-initialize automatically, but for AAA or QoS it clearly will be. jak ----- Original Message ----- From: "Nakhjiri Madjid-MNAKHJI1" To: "'James Kempf'" ; "Rajeev Koodli" Cc: "Gary Kenward" ; ; ; Sent: Friday, April 05, 2002 3:00 PM Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > Well, you are opening a can of worm that took seamoby 3 months > to close without any results. People could not agree on the > reliability needs of CT. We added a reliability mechanism to our > CT proposal that covered both retransmission and updates. > > Madjid > > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: Friday, April 05, 2002 12:22 PM > To: Rajeev Koodli > Cc: Gary Kenward; Hemant.Chaskar@nokia.com; nsis@ietf.org; > seamoby@ietf.org > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > Agree. > > But I don't see anything in the CT requirements about handling CT > failure. > > ??? > > jak > > ----- Original Message ----- > From: "Rajeev Koodli" > To: "James Kempf" > Cc: "Gary Kenward" ; > ; ; > Sent: Friday, April 05, 2002 10:02 AM > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > James Kempf wrote: > > > > > Rajeev, > > > > > > I agree, but there is still an issue of how the AR would notify the > MN > > > if CT fails. Is this covered by CT or not? > > > > > > > This notification should be covered by CT. We should offer > > seamless handover to NSIS :-) Seriously, this concerns > > robustness of CT protocol. > > > > -Rajeev > > > > > > > > > > jak > > > > > > ----- Original Message ----- > > > From: "Rajeev Koodli" > > > To: "James Kempf" > > > Cc: "Gary Kenward" ; > > > ; ; > > > Sent: Friday, April 05, 2002 9:19 AM > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > Hello Jim, > > > > > > > > James Kempf wrote: > > > > > > > > > There is an issue if CT fails. In that case, some kind of > > > negotiation > > > > > after handover would be required. > > > > > > > > > > So, I'd say that some indication of CT failure is needed. > > > > > > > > > > > > > Yes, but this is between AR and MN. If CT fails, the AR should > > > > notify the MN to engage in context re-creation. > > > > > > > > My point was specific to signaling _beyond_ AR (i.e., upstream > > > signaling) > > > > independent of failure/success of CT. > > > > > > > > Hope this is clearer.. > > > > > > > > -Rajeev > > > > > > > > > > > > > > > > > > As for CAR, I don't see the relevance for QoS negotiation, > though it > > > may > > > > > be useful for finding a new wireless medium. I also see it > primarily > > > for > > > > > intertechnology handover, or, at best, interprovider handover. > > > > > > > > > > jak > > > > > ----- Original Message ----- > > > > > From: "Rajeev Koodli" > > > > > To: "Gary Kenward" > > > > > Cc: ; ; > > > > > > Sent: Friday, April 05, 2002 9:01 AM > > > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after > handoff. > > > > > > > > > > > > > > > > > Hello, > > > > > > > > > > > > well, if the issue is QoS establishment after handover, > > > > > > > > > > > > - CT is applicable for establishing QoS state at the AR > > > > > > - if further signaling is desired beyond the AR, NSIS may > > > > > > consider it. I don't see how _signaling_ for QoS > establishment > > > > > > beyond AR is relevant for seamoby. > > > > > > > > > > > > CAR _discovery_ could exchange QoS capability as one of the > > > > > > parameters that might then be fed to a selection algorithm. > Any > > > > > > signaling for actually establishing QoS itself beyond the AR > > > > > > should be outside the scope of seamoby.. > > > > > > > > > > > > Regards, > > > > > > > > > > > > -Rajeev > > > > > > > > > > > > > > > > > > Gary Kenward wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > Hemant: > > > > > > > > > > > > > > Just a point of clarification, but as I understand CARD > (and > > > > > > > I don't understand it well), it is not a QoS negotiation > > > > > > > protocol. The main application that you are referring to > > > primarily > > > > > > > arises out of a perceived need to determine at the MN the > best > > > link > > > > > > > layer to handover over to when inter-technology handovers > are > > > > > > > involved. > > > > > > > It can be applied to intra-technology handovers, but the > value > > > in > > > > > > > that situation is highly questionable (e.g. since it is a > > > discovery > > > > > > > protocol, the implication is that the purpose is to > determine > > > the > > > > > > > choice of channels available; for intra-technology > handovers, > > > there > > > > > > > are many, many reasons why this "choice" may not be > available). > > > > > > > > > > > > > > There is a requirement, 5.1.2, which seems to imply NSIS > > > > > involvement > > > > > > > > > > > > > > during/after a handover. John has stated that this is not > the > > > > > > > intention > > > > > > > (please correct me if I have this wrong John), in which case > I > > > think > > > > > > > 5.1.2 needs to be clarified. > > > > > > > > > > > > > > Specifically, is NSIS to be used to negotiated new QoS for > an > > > > > > > existing flow after a handover, or is it specifically for > > > > > establishing > > > > > > > > > > > > > > QoS for a new flow? I don't think the answer is boolean: the > > > role > > > > > > > of NSIS in QoS re-negotiation is still open, I believe, and > > > clearly > > > > > > > handover is a dynamic situation that could cause the QoS > > > provided to > > > > > > > change. > > > > > > > > > > > > > > I have been told there is no issue, but here's a > frightening > > > > > > > scenario: > > > > > > > > > > > > > > - a handover takes place, and context transfer has > been > > > used > > > > > > > to > > > > > > > move the QoS context to the new routers (by the > > > requirements > > > > > > > for > > > > > > > CT this could be intra-, or inter- technology. Some > of us > > > > > > > believe > > > > > > > that for "seamless" handovers, the context will be > > > available > > > > > at > > > > > > > > > > > > > > routers before the first packets need to be > forwarded. > > > This > > > > > > > implies > > > > > > > that there is a relationship, probabilistic perhaps, > > > between > > > > > > > the handover process and the target ARs for CT. > > > > > > > > > > > > > > - CARD is used by the MN to influence the handover > decision > > > (it > > > > > > > is not clear to me how this happens, but it seems > clear > > > that > > > > > > > for a more "seamless" handover, the MN should chose > an AR > > > > > that > > > > > > > has received the appropriate context; if not, then > what? > > > > > > > > > > > > > > - NSIS kicks in and starts re-negotiating QoS because > of > > > > > changes > > > > > > > introduced by the handover; > > > > > > > > > > > > > > How do these three protocols interact to produce > predictable > > > > > > > outcomes? > > > > > > > Or, perhaps, the question is, how do the functional entities > > > > > > > associated > > > > > > > with the three protocols interact before, during and after a > > > > > handover? > > > > > > > > > > > > > > If it the interaction is within the functional entities, the > > > > > > > respective > > > > > > > wg's could declare the issue out of scope, but this approach > > > does > > > > > not > > > > > > > sit well with me, for it seems to defer the problem to the > > > people > > > > > who > > > > > > > have to implement this "stuff". > > > > > > > > > > > > > > Am I imagining things? > > > > > > > > > > > > > > Cheers, > > > > > > > Gary > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Hemant.Chaskar@nokia.com > > > [mailto:Hemant.Chaskar@nokia.com] > > > > > > > > Sent: April 4, 2002 22:33 > > > > > > > > To: nsis@ietf.org > > > > > > > > Subject: RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > > > > > > > > > > > > Hi Sharif: > > > > > > > > > > > > > > > > There is currently a debate going on in Seamoby as to > whether > > > > > > > > this QoS negotiation be covered by NSIS or Seamoby (CAR > > > > > > > > discovery protocol). > > > > > > > > > > > > > > > > IMHO it should be covered by CAR discovery and not NSIS. > CAR > > > > > > > > discovery is supposed to identify candidate access routers > > > > > > > > for handoff and QoS is an important property for > candidacy. > > > > > > > > > > > > > > > > Br, > > > > > > > > Hemant > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: ext Shahrier, Sharif M. > > > > > > > > [mailto:Sharif.Shahrier@InterDigital.com] > > > > > > > > Sent: Thursday, April 04, 2002 3:35 PM > > > > > > > > To: Shahrier, Sharif M. > > > > > > > > Cc: 'nsis@ietf.org' > > > > > > > > Subject: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I have a question for clarification. > > > > > > > > > > > > > > > > I think it was stated that NSIS should only be concerned > with > > > the > > > > > > > > establishment of QoS after handoff. > > > > > > > > > > > > > > > > This is inconvienent with respect to IP-level QoS > > > > > > > > negotiation, which ideally > > > > > > > > should be done before handoff has taken place. > > > > > > > > > > > > > > > > QoS negotiation is in the current requirements draft. > > > > > > > > > > > > > > > > So, NSIS signaling protocol development should be > concerned > > > > > > > > with activity > > > > > > > > before handoff occurs. > > > > > > > > > > > > > > > > Sharif. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > Seamoby mailing list > > > > > > Seamoby@ietf.org > > > > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Seamoby mailing list > > > > Seamoby@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Mon Apr 8 13:54:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01179 for ; Mon, 8 Apr 2002 13:54:26 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA25024 for nsis-archive@odin.ietf.org; Mon, 8 Apr 2002 13:54:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA24530; Mon, 8 Apr 2002 13:44:29 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA24492 for ; Mon, 8 Apr 2002 13:44:26 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00824; Mon, 8 Apr 2002 13:44:23 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g38HdSt01176; Mon, 8 Apr 2002 13:39:28 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 8 Apr 2002 13:39:28 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA49E5@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Rajeev Koodli'" Cc: "'James Kempf'" , Hemant.Chaskar@nokia.com, nsis@ietf.org, seamoby@ietf.org Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Mon, 8 Apr 2002 13:39:26 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DF23.E02FD9AA" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1DF23.E02FD9AA Content-Type: text/plain; charset="iso-8859-1" Rajeev: This was discussed extensively within the design team, and, I believe, also in the working group. CT is a transfer protocol. If the target AR is able to detect that the transfer has failed (e.g a CRC error, a timeout), then the target AR simply decides if it still wants to transfer context from the source, and, if it does, it issues a new request for context transfer. No special message is required. Gary > -----Original Message----- > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] > Sent: April 5, 2002 16:44 > To: Kenward, Gary [WDLN2:AN10:EXCH] > Cc: 'James Kempf'; Hemant.Chaskar@nokia.com; nsis@ietf.org; > seamoby@ietf.org > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > Gary, > > CT is a protocol, and as such would have failure > modes. For instance, transferred context is not > useful at the target router. You could say that CARD > should never let this happen. Does that mean that > CT cannot be used where CARD is not available ? > I hope not! > > In any case, I don't know of a protocol that does not > have failure modes. We need a notification > message in CT to inform when such a thing happens. > > Regards, > > -Rajeev > > > Gary Kenward wrote: > > > > > > > Well yes and no. > > > > First, CT is required to do everything it can to get the > > context across intact, as fast as possible, which, it was decided, > > meant > > that there was realistically only one opportunity to attempt to > > transfer > > the context. The emphasis was placed on requiring that a given > > transfer of > > context would not fail (e.g. the context integrity should > be preserved > > through > > error control, etc.). Then, if the transfer failed it was because of > > something > > other then the transfer process itself. > > > > If CT fails, it is more likely then not that handover will not be > > seamless > > anyways, and there is nothing that CT can do, per se, to recover. > > Having said this, CT can be re-invoked by another entity, > perhaps the > > handover > > control function, for recovery purposes. > > > > I'm trying to be brief, so I hope this captures what was a looooong > > discussion. > > > > Gary > > > > > -----Original Message----- > > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > > Sent: April 5, 2002 13:22 > > > To: Rajeev Koodli > > > Cc: Kenward, Gary [WDLN2:AN10:EXCH]; Hemant.Chaskar@nokia.com; > > > nsis@ietf.org; seamoby@ietf.org > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > Agree. > > > > > > But I don't see anything in the CT requirements about handling CT > > > failure. > > > > > > ??? > > > > > > jak > > > > > > > > > > > > > > ------_=_NextPart_001_01C1DF23.E02FD9AA Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff.

Rajeev:

This was discussed extensively within the design team, and,
I believe, also in the working group.

CT is a transfer protocol. If the target AR is able to detect
that the transfer has failed (e.g a CRC error, a timeout), then
the target AR simply decides if it still wants to transfer
context from the source, and, if it does, it issues a new request
for context transfer.

No special message is required.

Gary

> -----Original Message-----
> From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com]
> Sent: April 5, 2002 16:44
> To: Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: 'James Kempf'; Hemant.Chaskar@nokia.com; nsis@ietf.org;
> seamoby@ietf.org
> Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff.
>
>
>
> Gary,
>
> CT is a protocol, and as such would have failure
> modes. For instance, transferred context is not
> useful at the target router. You could say that CARD
> should never let this happen. Does that mean that
> CT cannot be used where CARD is not available ?
> I hope not!
>
> In any case, I don't know of a protocol that does not
> have failure modes. We need a notification
> message in CT to inform when such a thing happens.
>
> Regards,
>
> -Rajeev
>
>
> Gary Kenward wrote:
>
> >
> >
> > Well yes and no.
> >
> > First, CT is required to do everything it can to get the
> > context across intact, as fast as possible, which, it was decided,
> > meant
> > that there was realistically only one opportunity to attempt to
> > transfer
> > the context. The emphasis was placed on requiring that a given
> > transfer of
> > context would not fail (e.g. the context integrity should
> be preserved
> > through
> > error control, etc.). Then, if the transfer failed it was because of
> > something
> > other then the transfer process itself.
> >
> > If CT fails, it is more likely then not that handover will not be
> > seamless
> > anyways, and there is nothing that CT can do, per se, to recover.
> > Having said this, CT can be re-invoked by another entity,
> perhaps the
> > handover
> > control function, for recovery purposes.
> >
> > I'm trying to be brief, so I hope this captures what was a looooong
> > discussion.
> >
> > Gary
> >
> > > -----Original Message-----
> > > From: James Kempf [mailto:kempf@docomolabs-usa.com]
> > > Sent: April 5, 2002 13:22
> > > To: Rajeev Koodli
> > > Cc: Kenward, Gary [WDLN2:AN10:EXCH]; Hemant.Chaskar@nokia.com;
> > > nsis@ietf.org; seamoby@ietf.org
> > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff.
> > >
> > >
> > > Agree.
> > >
> > > But I don't see anything in the CT requirements about handling CT
> > > failure.
> > >
> > > ???
> > >
> > >             jak
> > >
> >  >
> > >
> > >
>
>

------_=_NextPart_001_01C1DF23.E02FD9AA-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Mon Apr 8 14:21:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01841 for ; Mon, 8 Apr 2002 14:21:11 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA27269 for nsis-archive@odin.ietf.org; Mon, 8 Apr 2002 14:21:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA25381; Mon, 8 Apr 2002 13:59:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA25253 for ; Mon, 8 Apr 2002 13:58:56 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01294; Mon, 8 Apr 2002 13:58:53 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g38HsMt02099; Mon, 8 Apr 2002 13:54:22 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 8 Apr 2002 13:54:22 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA49E6@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Rajeev Koodli'" , Nakhjiri Madjid-MNAKHJI1 Cc: Hemant.Chaskar@nokia.com, nsis@ietf.org, seamoby@ietf.org Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Mon, 8 Apr 2002 13:54:20 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DF26.68AF79AA" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1DF26.68AF79AA Content-Type: text/plain; charset="iso-8859-1" Rajeev: In order for the MN to "recreate the context", the MN would have to understand the semantics of Context transfer, etc., and, more important, there would have to be a protocol or protocols that would allow the MN to recreate contexts at an AR. I doubt that the latter is going to happen (e.g. authentication). IF and when a CT fails, the easiest way to "recreate" context is for the sessions to be dropped. This may seem drastic, but in reality, what is going to cause CT to fail and how often will this happen? There may be mitigating actions that could be taken to re-establish certain sessions. But these decisions are must be driven by the policy of the network administration (explicit or implicity), and comply with the security, resource management and accounting requirements for the network. Hopefully, none of these mitigating actions requires more over-the-air signalling. Gary > -----Original Message----- > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] > Sent: April 5, 2002 17:46 > To: Nakhjiri Madjid-MNAKHJI1 > Cc: Kenward, Gary [WDLN2:AN10:EXCH]; Hemant.Chaskar@nokia.com; > nsis@ietf.org; seamoby@ietf.org > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > Hello Madjid, > > Nakhjiri Madjid-MNAKHJI1 wrote: > > > Hello Rajeev, > > > > I agreed with everything you say below, except one thing: > > CT can only transfer whatever QoS state that is usable at the newAR. > > If the new network is using a different QoS technology with > different > > QoS parameters, then I am not sure if CT by itself can do > the job, unless > > you add your own mapping functionality. > > > > This would be an example where the new AR sends a > notification to the MN so that the MN can take > appropriate action (for instance, attempt to > re-create the context). > > Regards, > > -Rajeev > > > > > > BR, > > Madjid > > > > -----Original Message----- > > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] > > Sent: Friday, April 05, 2002 11:01 AM > > To: Gary Kenward > > Cc: Hemant.Chaskar@nokia.com; nsis@ietf.org; seamoby@ietf.org > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > Hello, > > > > well, if the issue is QoS establishment after handover, > > > > - CT is applicable for establishing QoS state at the AR > > - if further signaling is desired beyond the AR, NSIS may > > consider it. I don't see how _signaling_ for QoS establishment > > beyond AR is relevant for seamoby. > > > > CAR _discovery_ could exchange QoS capability as one of the > > parameters that might then be fed to a selection algorithm. Any > > signaling for actually establishing QoS itself beyond the AR > > should be outside the scope of seamoby.. > > > > Regards, > > > > -Rajeev > > > > Gary Kenward wrote: > > > > > > > > > > > Hemant: > > > > > > Just a point of clarification, but as I understand CARD (and > > > I don't understand it well), it is not a QoS negotiation > > > protocol. The main application that you are referring to primarily > > > arises out of a perceived need to determine at the MN the > best link > > > layer to handover over to when inter-technology handovers are > > > involved. > > > It can be applied to intra-technology handovers, but the value in > > > that situation is highly questionable (e.g. since it is a > discovery > > > protocol, the implication is that the purpose is to determine the > > > choice of channels available; for intra-technology > handovers, there > > > are many, many reasons why this "choice" may not be available). > > > > > > There is a requirement, 5.1.2, which seems to imply > NSIS involvement > > > > > > during/after a handover. John has stated that this is not the > > > intention > > > (please correct me if I have this wrong John), in which > case I think > > > 5.1.2 needs to be clarified. > > > > > > Specifically, is NSIS to be used to negotiated new QoS for an > > > existing flow after a handover, or is it specifically for > establishing > > > > > > QoS for a new flow? I don't think the answer is boolean: the role > > > of NSIS in QoS re-negotiation is still open, I believe, > and clearly > > > handover is a dynamic situation that could cause the QoS > provided to > > > change. > > > > > > I have been told there is no issue, but here's a frightening > > > scenario: > > > > > > - a handover takes place, and context transfer > has been used > > > to > > > move the QoS context to the new routers (by the > requirements > > > for > > > CT this could be intra-, or inter- technology. Some of us > > > believe > > > that for "seamless" handovers, the context will be > available at > > > > > > routers before the first packets need to be forwarded. This > > > implies > > > that there is a relationship, probabilistic > perhaps, between > > > the handover process and the target ARs for CT. > > > > > > - CARD is used by the MN to influence the handover > decision (it > > > is not clear to me how this happens, but it seems > clear that > > > for a more "seamless" handover, the MN should > chose an AR that > > > has received the appropriate context; if not, then what? > > > > > > - NSIS kicks in and starts re-negotiating QoS > because of changes > > > introduced by the handover; > > > > > > How do these three protocols interact to produce predictable > > > outcomes? > > > Or, perhaps, the question is, how do the functional entities > > > associated > > > with the three protocols interact before, during and > after a handover? > > > > > > If it the interaction is within the functional entities, the > > > respective > > > wg's could declare the issue out of scope, but this > approach does not > > > sit well with me, for it seems to defer the problem to > the people who > > > have to implement this "stuff". > > > > > > Am I imagining things? > > > > > > Cheers, > > > Gary > > > > > > > -----Original Message----- > > > > From: Hemant.Chaskar@nokia.com [mailto:Hemant.Chaskar@nokia.com] > > > > Sent: April 4, 2002 22:33 > > > > To: nsis@ietf.org > > > > Subject: RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > Hi Sharif: > > > > > > > > There is currently a debate going on in Seamoby as to whether > > > > this QoS negotiation be covered by NSIS or Seamoby (CAR > > > > discovery protocol). > > > > > > > > IMHO it should be covered by CAR discovery and not NSIS. CAR > > > > discovery is supposed to identify candidate access routers > > > > for handoff and QoS is an important property for candidacy. > > > > > > > > Br, > > > > Hemant > > > > > > > > -----Original Message----- > > > > From: ext Shahrier, Sharif M. > > > > [mailto:Sharif.Shahrier@InterDigital.com] > > > > Sent: Thursday, April 04, 2002 3:35 PM > > > > To: Shahrier, Sharif M. > > > > Cc: 'nsis@ietf.org' > > > > Subject: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > > > > I have a question for clarification. > > > > > > > > I think it was stated that NSIS should only be > concerned with the > > > > establishment of QoS after handoff. > > > > > > > > This is inconvienent with respect to IP-level QoS > > > > negotiation, which ideally > > > > should be done before handoff has taken place. > > > > > > > > QoS negotiation is in the current requirements draft. > > > > > > > > So, NSIS signaling protocol development should be concerned > > > > with activity > > > > before handoff occurs. > > > > > > > > Sharif. > > > > > > > > > > > > > > > > _______________________________________________ > > > > 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 > > > > > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > ------_=_NextPart_001_01C1DF26.68AF79AA Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff.

Rajeev:

In order for the MN to "recreate the context", the MN would
have to understand the semantics of Context transfer, etc.,
and, more important, there would have to be a protocol or
protocols that would allow the MN to recreate contexts at an AR.
I doubt that the latter is going to happen (e.g. authentication).

IF and when a CT fails, the easiest way to "recreate" context
is for the sessions to be dropped. This may seem drastic,
but in reality, what is going to cause CT to fail and
how often will this happen?

There may be mitigating actions that could be taken to re-establish
certain sessions. But these decisions are must be driven by the policy
of the network administration (explicit or implicity), and comply
with the security, resource management and accounting requirements
for the network. Hopefully, none of these mitigating actions requires
more over-the-air signalling.

Gary

> -----Original Message-----
> From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com]
> Sent: April 5, 2002 17:46
> To: Nakhjiri Madjid-MNAKHJI1
> Cc: Kenward, Gary [WDLN2:AN10:EXCH]; Hemant.Chaskar@nokia.com;
> nsis@ietf.org; seamoby@ietf.org
> Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff.
>
>
>
> Hello Madjid,
>
> Nakhjiri Madjid-MNAKHJI1 wrote:
>
> > Hello Rajeev,
> >
> > I agreed with everything you say below, except one thing:
> > CT can only transfer whatever QoS state that is usable at the newAR.
> > If the new network is using a different QoS technology with
> different
> > QoS parameters, then I am not sure if CT by itself can do
> the job, unless
> > you add your own mapping functionality.
> >
>
> This would be an example where the new AR sends a
> notification to the MN so that the MN can take
> appropriate action (for instance, attempt to
> re-create the context).
>
> Regards,
>
> -Rajeev
>
>
> >
> > BR,
> > Madjid
> >
> > -----Original Message-----
> > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com]
> > Sent: Friday, April 05, 2002 11:01 AM
> > To: Gary Kenward
> > Cc: Hemant.Chaskar@nokia.com; nsis@ietf.org; seamoby@ietf.org
> > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff.
> >
> > Hello,
> >
> > well, if the issue is QoS establishment after handover,
> >
> > - CT is applicable for establishing QoS state at the AR
> > - if further signaling is desired beyond the AR, NSIS may
> >     consider it. I don't see how _signaling_ for QoS establishment
> >     beyond AR is relevant for seamoby.
> >
> > CAR _discovery_ could exchange QoS capability as one of the
> > parameters that might then be fed to a selection algorithm. Any
> > signaling for actually establishing QoS itself beyond the AR
> > should be outside the scope of seamoby..
> >
> > Regards,
> >
> > -Rajeev
> >
> > Gary Kenward wrote:
> >
> > >
> > >
> > > Hemant:
> > >
> > >   Just a point of clarification, but as I understand CARD (and
> > > I don't understand it well), it is not a QoS negotiation
> > > protocol. The main application that you are referring to primarily
> > > arises out of a perceived need to determine at the MN the
> best link
> > > layer to handover over to when inter-technology handovers are
> > > involved.
> > > It can be applied to intra-technology handovers, but the value in
> > > that situation is highly questionable (e.g. since it is a
> discovery
> > > protocol, the implication is that the purpose is to determine the
> > > choice of channels available; for intra-technology
> handovers, there
> > > are many, many reasons why this "choice" may not be available).
> > >
> > >   There is a requirement, 5.1.2, which seems to imply
> NSIS involvement
> > >
> > > during/after a handover. John has stated that this is not the
> > > intention
> > > (please correct me if I have this wrong John), in which
> case I think
> > > 5.1.2 needs to be clarified.
> > >
> > >   Specifically, is NSIS to be used to negotiated new QoS for an
> > > existing flow after a handover, or is it specifically for
> establishing
> > >
> > > QoS for a new flow? I don't think the answer is boolean: the role
> > > of NSIS in QoS re-negotiation is still open, I believe,
> and clearly
> > > handover is a dynamic situation that could cause the QoS
> provided to
> > > change.
> > >
> > >   I have been told there is no issue, but here's a frightening
> > > scenario:
> > >
> > >         - a handover takes place, and context transfer
> has been used
> > > to
> > >        move the QoS context to the new routers (by the
> requirements
> > > for
> > >        CT this could be intra-, or inter- technology. Some of us
> > > believe
> > >        that for "seamless" handovers, the context will be
> available at
> > >
> > >        routers before the first packets need to be forwarded. This
> > > implies
> > >        that there is a relationship, probabilistic
> perhaps, between
> > >        the handover process and the target ARs for CT.
> > >
> > >      - CARD is used by the MN to influence the handover
> decision (it
> > >        is not clear to me how this happens, but it seems
> clear that
> > >        for a more "seamless" handover, the MN should
> chose an AR that
> > >        has received the appropriate context; if not, then what?
> > >
> > >      - NSIS kicks in and starts re-negotiating QoS
> because of changes
> > >        introduced by the handover;
> > >
> > >   How do these three protocols interact to produce predictable
> > > outcomes?
> > > Or, perhaps, the question is, how do the functional entities
> > > associated
> > > with the three protocols interact before, during and
> after a handover?
> > >
> > > If it the interaction is within the functional entities, the
> > > respective
> > > wg's could declare the issue out of scope, but this
> approach does not
> > > sit well with me, for it seems to defer the problem to
> the people who
> > > have to implement this "stuff".
> > >
> > >   Am I imagining things?
> > >
> > > Cheers,
> > > Gary
> > >
> > > > -----Original Message-----
> > > > From: Hemant.Chaskar@nokia.com [mailto:Hemant.Chaskar@nokia.com]
> > > > Sent: April 4, 2002 22:33
> > > > To: nsis@ietf.org
> > > > Subject: RE: [NSIS] Establishing QoS after handoff.
> > > >
> > > >
> > > > Hi Sharif:
> > > >
> > > > There is currently a debate going on in Seamoby as to whether
> > > > this QoS negotiation be covered by NSIS or Seamoby (CAR
> > > > discovery protocol).
> > > >
> > > > IMHO it should be covered by CAR discovery and not NSIS. CAR
> > > > discovery is supposed to identify candidate access routers
> > > > for handoff and QoS is an important property for candidacy.
> > > >
> > > > Br,
> > > > Hemant
> > > >
> > > > -----Original Message-----
> > > > From: ext Shahrier, Sharif M.
> > > > [mailto:Sharif.Shahrier@InterDigital.com]
> > > > Sent: Thursday, April 04, 2002 3:35 PM
> > > > To: Shahrier, Sharif M.
> > > > Cc: 'nsis@ietf.org'
> > > > Subject: [NSIS] Establishing QoS after handoff.
> > > >
> > > >
> > > >
> > > > I have a question for clarification.
> > > >
> > > > I think it was stated that NSIS should only be
> concerned with the
> > > > establishment of QoS after handoff.
> > > >
> > > > This is inconvienent with respect to IP-level QoS
> > > > negotiation, which ideally
> > > > should be done before handoff has taken place.
> > > >
> > > > QoS negotiation is in the current requirements draft.
> > > >
> > > > So, NSIS signaling protocol development should be concerned
> > > > with activity
> > > > before handoff occurs.
> > > >
> > > > Sharif.
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > 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
> > > >
> >
> > _______________________________________________
> > Seamoby mailing list
> > Seamoby@ietf.org
> > https://www1.ietf.org/mailman/listinfo/seamoby
> >
> > _______________________________________________
> > Seamoby mailing list
> > Seamoby@ietf.org
> > https://www1.ietf.org/mailman/listinfo/seamoby
>
>

------_=_NextPart_001_01C1DF26.68AF79AA-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Mon Apr 8 14:58:54 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02810 for ; Mon, 8 Apr 2002 14:58:54 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA29948 for nsis-archive@odin.ietf.org; Mon, 8 Apr 2002 14:58:56 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA28606; Mon, 8 Apr 2002 14:36:04 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA28555 for ; Mon, 8 Apr 2002 14:36:01 -0400 (EDT) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02158; Mon, 8 Apr 2002 14:35:55 -0400 (EDT) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g38IRLI24985; Mon, 8 Apr 2002 11:27:21 -0700 (PDT) Message-ID: <02a201c1df2a$cc4810e0$7e6015ac@T23KEMPF> From: "James Kempf" To: "Gary Kenward" , "'Rajeev Koodli'" , "Nakhjiri Madjid-MNAKHJI1" Cc: , , References: <9FBD322B7824D511B36900508BF93C9C01AA49E6@zcard031.ca.nortel.com> Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Mon, 8 Apr 2002 11:25:45 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit Gary, I don't think the issue is having the MN re-create the context. Is is allowing the MN to recover by re-running the actions that were necessary to create the context in the first place, in the event the AR was unable to interpret it. Thus, for example, suppose that QoS context is transferred from old to new AR, but new AR for some reason can't interpret it, perhaps there is no bandwidth left or perhaps the new AR uses a different representation for QoS context. The MN would need to be informed somehow so that it could re-do its QoS signaling. jak ----- Original Message ----- From: "Gary Kenward" To: "'Rajeev Koodli'" ; "Nakhjiri Madjid-MNAKHJI1" Cc: ; ; Sent: Monday, April 08, 2002 10:54 AM Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > Rajeev: > > In order for the MN to "recreate the context", the MN would > have to understand the semantics of Context transfer, etc., > and, more important, there would have to be a protocol or > protocols that would allow the MN to recreate contexts at an AR. > I doubt that the latter is going to happen (e.g. authentication). > > IF and when a CT fails, the easiest way to "recreate" context > is for the sessions to be dropped. This may seem drastic, > but in reality, what is going to cause CT to fail and > how often will this happen? > > There may be mitigating actions that could be taken to re-establish > certain sessions. But these decisions are must be driven by the policy > of the network administration (explicit or implicity), and comply > with the security, resource management and accounting requirements > for the network. Hopefully, none of these mitigating actions requires > more over-the-air signalling. > > Gary > > > -----Original Message----- > > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] > > Sent: April 5, 2002 17:46 > > To: Nakhjiri Madjid-MNAKHJI1 > > Cc: Kenward, Gary [WDLN2:AN10:EXCH]; Hemant.Chaskar@nokia.com; > > nsis@ietf.org; seamoby@ietf.org > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > > > Hello Madjid, > > > > Nakhjiri Madjid-MNAKHJI1 wrote: > > > > > Hello Rajeev, > > > > > > I agreed with everything you say below, except one thing: > > > CT can only transfer whatever QoS state that is usable at the newAR. > > > If the new network is using a different QoS technology with > > different > > > QoS parameters, then I am not sure if CT by itself can do > > the job, unless > > > you add your own mapping functionality. > > > > > > > This would be an example where the new AR sends a > > notification to the MN so that the MN can take > > appropriate action (for instance, attempt to > > re-create the context). > > > > Regards, > > > > -Rajeev > > > > > > > > > > BR, > > > Madjid > > > > > > -----Original Message----- > > > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] > > > Sent: Friday, April 05, 2002 11:01 AM > > > To: Gary Kenward > > > Cc: Hemant.Chaskar@nokia.com; nsis@ietf.org; seamoby@ietf.org > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > Hello, > > > > > > well, if the issue is QoS establishment after handover, > > > > > > - CT is applicable for establishing QoS state at the AR > > > - if further signaling is desired beyond the AR, NSIS may > > > consider it. I don't see how _signaling_ for QoS establishment > > > beyond AR is relevant for seamoby. > > > > > > CAR _discovery_ could exchange QoS capability as one of the > > > parameters that might then be fed to a selection algorithm. Any > > > signaling for actually establishing QoS itself beyond the AR > > > should be outside the scope of seamoby.. > > > > > > Regards, > > > > > > -Rajeev > > > > > > Gary Kenward wrote: > > > > > > > > > > > > > > > Hemant: > > > > > > > > Just a point of clarification, but as I understand CARD (and > > > > I don't understand it well), it is not a QoS negotiation > > > > protocol. The main application that you are referring to primarily > > > > arises out of a perceived need to determine at the MN the > > best link > > > > layer to handover over to when inter-technology handovers are > > > > involved. > > > > It can be applied to intra-technology handovers, but the value in > > > > that situation is highly questionable (e.g. since it is a > > discovery > > > > protocol, the implication is that the purpose is to determine the > > > > choice of channels available; for intra-technology > > handovers, there > > > > are many, many reasons why this "choice" may not be available). > > > > > > > > There is a requirement, 5.1.2, which seems to imply > > NSIS involvement > > > > > > > > during/after a handover. John has stated that this is not the > > > > intention > > > > (please correct me if I have this wrong John), in which > > case I think > > > > 5.1.2 needs to be clarified. > > > > > > > > Specifically, is NSIS to be used to negotiated new QoS for an > > > > existing flow after a handover, or is it specifically for > > establishing > > > > > > > > QoS for a new flow? I don't think the answer is boolean: the role > > > > of NSIS in QoS re-negotiation is still open, I believe, > > and clearly > > > > handover is a dynamic situation that could cause the QoS > > provided to > > > > change. > > > > > > > > I have been told there is no issue, but here's a frightening > > > > scenario: > > > > > > > > - a handover takes place, and context transfer > > has been used > > > > to > > > > move the QoS context to the new routers (by the > > requirements > > > > for > > > > CT this could be intra-, or inter- technology. Some of us > > > > believe > > > > that for "seamless" handovers, the context will be > > available at > > > > > > > > routers before the first packets need to be forwarded. This > > > > implies > > > > that there is a relationship, probabilistic > > perhaps, between > > > > the handover process and the target ARs for CT. > > > > > > > > - CARD is used by the MN to influence the handover > > decision (it > > > > is not clear to me how this happens, but it seems > > clear that > > > > for a more "seamless" handover, the MN should > > chose an AR that > > > > has received the appropriate context; if not, then what? > > > > > > > > - NSIS kicks in and starts re-negotiating QoS > > because of changes > > > > introduced by the handover; > > > > > > > > How do these three protocols interact to produce predictable > > > > outcomes? > > > > Or, perhaps, the question is, how do the functional entities > > > > associated > > > > with the three protocols interact before, during and > > after a handover? > > > > > > > > If it the interaction is within the functional entities, the > > > > respective > > > > wg's could declare the issue out of scope, but this > > approach does not > > > > sit well with me, for it seems to defer the problem to > > the people who > > > > have to implement this "stuff". > > > > > > > > Am I imagining things? > > > > > > > > Cheers, > > > > Gary > > > > > > > > > -----Original Message----- > > > > > From: Hemant.Chaskar@nokia.com [mailto:Hemant.Chaskar@nokia.com] > > > > > Sent: April 4, 2002 22:33 > > > > > To: nsis@ietf.org > > > > > Subject: RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > > > Hi Sharif: > > > > > > > > > > There is currently a debate going on in Seamoby as to whether > > > > > this QoS negotiation be covered by NSIS or Seamoby (CAR > > > > > discovery protocol). > > > > > > > > > > IMHO it should be covered by CAR discovery and not NSIS. CAR > > > > > discovery is supposed to identify candidate access routers > > > > > for handoff and QoS is an important property for candidacy. > > > > > > > > > > Br, > > > > > Hemant > > > > > > > > > > -----Original Message----- > > > > > From: ext Shahrier, Sharif M. > > > > > [mailto:Sharif.Shahrier@InterDigital.com] > > > > > Sent: Thursday, April 04, 2002 3:35 PM > > > > > To: Shahrier, Sharif M. > > > > > Cc: 'nsis@ietf.org' > > > > > Subject: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > > > > > > > > I have a question for clarification. > > > > > > > > > > I think it was stated that NSIS should only be > > concerned with the > > > > > establishment of QoS after handoff. > > > > > > > > > > This is inconvienent with respect to IP-level QoS > > > > > negotiation, which ideally > > > > > should be done before handoff has taken place. > > > > > > > > > > QoS negotiation is in the current requirements draft. > > > > > > > > > > So, NSIS signaling protocol development should be concerned > > > > > with activity > > > > > before handoff occurs. > > > > > > > > > > Sharif. > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > 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 > > > > > > > > > > > _______________________________________________ > > > Seamoby mailing list > > > Seamoby@ietf.org > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > _______________________________________________ > > > Seamoby mailing list > > > Seamoby@ietf.org > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Mon Apr 8 15:13:53 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03335 for ; Mon, 8 Apr 2002 15:13:53 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA01146 for nsis-archive@odin.ietf.org; Mon, 8 Apr 2002 15:13:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA27103; Mon, 8 Apr 2002 14:18:36 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA27072 for ; Mon, 8 Apr 2002 14:18:33 -0400 (EDT) Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01813 for ; Mon, 8 Apr 2002 14:18:30 -0400 (EDT) Received: from JMPOLK-W2K (ssh-sjc-1.cisco.com [171.68.225.134]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id LAA27078; Mon, 8 Apr 2002 11:17:59 -0700 (PDT) Message-Id: <4.1.20020408130525.028dba78@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Mon, 08 Apr 2002 13:17:58 -0500 To: john.loughney@nokia.com, From: "James M. Polk" In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEFC64E00@esebe004.NOE.Nokia. com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_3021504==_.ALT" Subject: [NSIS] Re: NSIS Scoping (was Preemption) Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org --=====================_3021504==_.ALT Content-Type: text/plain; charset="us-ascii" At 11:17 AM 4/8/2002 +0300, john.loughney@nokia.com wrote: >Hi James, > >Clarification of NSIS's scope: > >> If NSIS wants to migrate any of these networks over to IP, or be part of >> any migration or transition, preemption ought to be defined the WG, albeit >> as an option - with specifics surrounding that/those options. > >NSIS is not working on migrating any networks to IP. What NSIS will >(hopefully) do is create a signaling framework/protocol that can be >used to signal QoS. This work may be useful for some network designers >who want to provide capabilities similar to other networks, but doing >this is not NSIS's primary goal. John, while I agree that is shouldn't be its primary goal, making sure that certain realistic capabilities are *able* to be migrated a phase-in approach towards IP networking should be included. If the goal of this WG is to more or less operate in a vacuum, that's fine. I was just offering a suggestion, especially now that Diffserv is being shut down (with those Chairs now stating NSIS is the place to go within the IETF for QOS), to open your area up to this capability as an option. I recommend including this option verses having to retrofit it into your work down the road when this capability requirement from SPs and semi-private networks will look for mechanisms to be utilized and find that NSIS isn't one of them. I seriously don't mean that as any sort of threat, I just am in touch with many network administrators that wish to have this capability and want the IETF to continue to include the possibility of it in Standards Track efforts. All the while knowing that enabling this capability is a matter of local policy... > >John ************************************* "People generally demand more respect for their own rights than they are willing to allow for others" James M. Polk Consulting Engineer Office of the CTO Cisco Systems 2200 East President George Bush Turnpike Richardson, TX 75082 USA w) 972.813.5208 f) 972.813.5280 www.cisco.com --=====================_3021504==_.ALT Content-Type: text/html; charset="us-ascii"
At 11:17 AM 4/8/2002 +0300, john.loughney@nokia.com wrote:
>Hi James,
>
>Clarification of NSIS's scope:
>
>> If NSIS wants to migrate any of these networks over to IP, or be part of
>> any migration or transition, preemption ought to be defined the WG, albeit
>> as an option - with specifics surrounding that/those options.
>
>NSIS is not working on migrating any networks to IP.  What NSIS will
>(hopefully) do is create a signaling framework/protocol that can be
>used to signal QoS.  This work may be useful for some network designers
>who want to provide capabilities similar to other networks, but doing
>this is not NSIS's primary goal.

John, while I agree that is shouldn't be its primary goal, making sure that certain realistic capabilities are *able* to be migrated a phase-in approach towards IP networking should be included. If the goal of this WG is to more or less operate in a vacuum, that's fine. I was just offering a suggestion, especially now that Diffserv is being shut down (with those Chairs now stating NSIS is the place to go within the IETF for QOS), to open your area up to this capability as an option. I recommend including this option verses having to retrofit it into your work down the road when this capability requirement from SPs and semi-private networks will look for mechanisms to be utilized and find that NSIS isn't one of them. I seriously don't mean that as any sort of threat, I just am in touch with many network administrators that wish to have this capability and want the IETF to continue to include the possibility of it in Standards Track efforts.

All the while knowing that enabling this capability is a matter of local policy...

>
>John

*************************************
"People generally demand more respect for their own rights than they are willing to allow for others"

James M. Polk
Consulting Engineer
Office of the CTO

Cisco Systems
2200 East President George Bush Turnpike
Richardson, TX  75082 USA
w) 972.813.5208
f)  972.813.5280
www.cisco.com --=====================_3021504==_.ALT-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Mon Apr 8 15:29:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03710 for ; Mon, 8 Apr 2002 15:29:46 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA01951 for nsis-archive@odin.ietf.org; Mon, 8 Apr 2002 15:29:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA29544; Mon, 8 Apr 2002 14:50:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA29434 for ; Mon, 8 Apr 2002 14:50:50 -0400 (EDT) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02539; Mon, 8 Apr 2002 14:50:45 -0400 (EDT) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g38IXiI25249; Mon, 8 Apr 2002 11:33:44 -0700 (PDT) Message-ID: <02ab01c1df2b$b0512420$7e6015ac@T23KEMPF> From: "James Kempf" To: "Gary Kenward" , "Nakhjiri Madjid-MNAKHJI1" , "Rajeev Koodli" Cc: , , References: <9FBD322B7824D511B36900508BF93C9C01AA49E8@zcard031.ca.nortel.com> Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Mon, 8 Apr 2002 11:32:07 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit Gary, I agree about session establishment, but the fact remains that if failure of a context transfer for some reason leaves the MN without any indication that it should proceed to re-establish the feature, then the MN can't know when it should redo signaling to set up its new state. We faced this issue with BETH/FMIPv6 and the solution we found there was to have routers on the border of a fast handover coverage area inform the MN what handover algorithm was supported by routers in the other coverage area. While I think this could be done for the cases involving router configuration, such as where the next access router can't interpret the context, I am not so sure about failure due to dynamic conditions, such as that the router currently has all its Gold Class service bandwidth allocated (a QoS failure). In any event, I think there is need for some kind of signaling to indicate to the MN that context transfer has failed and that the MN needs to redo signaling to re-establish feature contexts. jak ----- Original Message ----- From: "Gary Kenward" To: "'James Kempf'" ; "Nakhjiri Madjid-MNAKHJI1" ; "Rajeev Koodli" Cc: ; ; Sent: Monday, April 08, 2002 11:08 AM Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > James: > > My main problem with the theme in this discussion is that > CT is a context transfer protocol, not a session management protocol. > In particular, when there are feature context specific issues, it is > best to handle session re-establishment/re-negotiation/maintenance using > the protocol(s) that were designed to set up the services in the first > place. CT should not be stretched into being a general signalling protocol. > > In addition, there is the perhaps greater argument that the most > effective method of correcting handover issues is not through over > the air signalling exchanges. Given the nature of the wireless link, > it will almost always be faster and always be more cost effective, to > correct any problems with signalling within the infrastructure (if it is > needed). > > Gary > > > -----Original Message----- > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > Sent: April 8, 2002 11:42 > > To: Nakhjiri Madjid-MNAKHJI1; Rajeev Koodli > > Cc: Kenward, Gary [WDLN2:AN10:EXCH]; Hemant.Chaskar@nokia.com; > > nsis@ietf.org; seamoby@ietf.org > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > Madjid, > > > > The issue isn't reliability, it is whether the target AR can interpret > > the context intelligably. If not, the MN may need to recover > > by actually > > re-initializing whatever feature the context was being transfered for. > > But it cannot do this unless it knows that the CT has failed. > > > > For some feature contexts, like header compression, this > > isn't a problem > > because it will re-initialize automatically, but for AAA or QoS it > > clearly will be. > > > > jak > > > > ----- Original Message ----- > > From: "Nakhjiri Madjid-MNAKHJI1" > > To: "'James Kempf'" ; "Rajeev Koodli" > > > > Cc: "Gary Kenward" ; > > ; ; > > Sent: Friday, April 05, 2002 3:00 PM > > Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > > Well, you are opening a can of worm that took seamoby 3 months > > > to close without any results. People could not agree on the > > > reliability needs of CT. We added a reliability mechanism to our > > > CT proposal that covered both retransmission and updates. > > > > > > Madjid > > > > > > -----Original Message----- > > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > > Sent: Friday, April 05, 2002 12:22 PM > > > To: Rajeev Koodli > > > Cc: Gary Kenward; Hemant.Chaskar@nokia.com; nsis@ietf.org; > > > seamoby@ietf.org > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > Agree. > > > > > > But I don't see anything in the CT requirements about handling CT > > > failure. > > > > > > ??? > > > > > > jak > > > > > > ----- Original Message ----- > > > From: "Rajeev Koodli" > > > To: "James Kempf" > > > Cc: "Gary Kenward" ; > > > ; ; > > > Sent: Friday, April 05, 2002 10:02 AM > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > > James Kempf wrote: > > > > > > > > > Rajeev, > > > > > > > > > > I agree, but there is still an issue of how the AR would notify > > the > > > MN > > > > > if CT fails. Is this covered by CT or not? > > > > > > > > > > > > > This notification should be covered by CT. We should offer > > > > seamless handover to NSIS :-) Seriously, this concerns > > > > robustness of CT protocol. > > > > > > > > -Rajeev > > > > > > > > > > > > > > > > > > jak > > > > > > > > > > ----- Original Message ----- > > > > > From: "Rajeev Koodli" > > > > > To: "James Kempf" > > > > > Cc: "Gary Kenward" ; > > > > > ; ; > > > > > Sent: Friday, April 05, 2002 9:19 AM > > > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS > > after handoff. > > > > > > > > > > > > > > > > > Hello Jim, > > > > > > > > > > > > James Kempf wrote: > > > > > > > > > > > > > There is an issue if CT fails. In that case, some kind of > > > > > negotiation > > > > > > > after handover would be required. > > > > > > > > > > > > > > So, I'd say that some indication of CT failure is needed. > > > > > > > > > > > > > > > > > > > Yes, but this is between AR and MN. If CT fails, the AR should > > > > > > notify the MN to engage in context re-creation. > > > > > > > > > > > > My point was specific to signaling _beyond_ AR (i.e., upstream > > > > > signaling) > > > > > > independent of failure/success of CT. > > > > > > > > > > > > Hope this is clearer.. > > > > > > > > > > > > -Rajeev > > > > > > > > > > > > > > > > > > > > > > > > > > As for CAR, I don't see the relevance for QoS negotiation, > > > though it > > > > > may > > > > > > > be useful for finding a new wireless medium. I also see it > > > primarily > > > > > for > > > > > > > intertechnology handover, or, at best, > > interprovider handover. > > > > > > > > > > > > > > jak > > > > > > > ----- Original Message ----- > > > > > > > From: "Rajeev Koodli" > > > > > > > To: "Gary Kenward" > > > > > > > Cc: ; ; > > > > > > > > > > Sent: Friday, April 05, 2002 9:01 AM > > > > > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after > > > handoff. > > > > > > > > > > > > > > > > > > > > > > > Hello, > > > > > > > > > > > > > > > > well, if the issue is QoS establishment after handover, > > > > > > > > > > > > > > > > - CT is applicable for establishing QoS state at the AR > > > > > > > > - if further signaling is desired beyond the AR, NSIS may > > > > > > > > consider it. I don't see how _signaling_ for QoS > > > establishment > > > > > > > > beyond AR is relevant for seamoby. > > > > > > > > > > > > > > > > CAR _discovery_ could exchange QoS capability as > > one of the > > > > > > > > parameters that might then be fed to a selection > > algorithm. > > > Any > > > > > > > > signaling for actually establishing QoS itself > > beyond the AR > > > > > > > > should be outside the scope of seamoby.. > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > > > -Rajeev > > > > > > > > > > > > > > > > > > > > > > > > Gary Kenward wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hemant: > > > > > > > > > > > > > > > > > > Just a point of clarification, but as I > > understand CARD > > > (and > > > > > > > > > I don't understand it well), it is not a QoS negotiation > > > > > > > > > protocol. The main application that you are referring to > > > > > primarily > > > > > > > > > arises out of a perceived need to determine at > > the MN the > > > best > > > > > link > > > > > > > > > layer to handover over to when inter-technology > > handovers > > > are > > > > > > > > > involved. > > > > > > > > > It can be applied to intra-technology handovers, but the > > > value > > > > > in > > > > > > > > > that situation is highly questionable (e.g. > > since it is a > > > > > discovery > > > > > > > > > protocol, the implication is that the purpose is to > > > determine > > > > > the > > > > > > > > > choice of channels available; for intra-technology > > > handovers, > > > > > there > > > > > > > > > are many, many reasons why this "choice" may not be > > > available). > > > > > > > > > > > > > > > > > > There is a requirement, 5.1.2, which seems to > > imply NSIS > > > > > > > involvement > > > > > > > > > > > > > > > > > > during/after a handover. John has stated that > > this is not > > > the > > > > > > > > > intention > > > > > > > > > (please correct me if I have this wrong John), in which > > case > > > I > > > > > think > > > > > > > > > 5.1.2 needs to be clarified. > > > > > > > > > > > > > > > > > > Specifically, is NSIS to be used to negotiated new QoS > > for > > > an > > > > > > > > > existing flow after a handover, or is it > > specifically for > > > > > > > establishing > > > > > > > > > > > > > > > > > > QoS for a new flow? I don't think the answer is boolean: > > the > > > > > role > > > > > > > > > of NSIS in QoS re-negotiation is still open, I believe, > > and > > > > > clearly > > > > > > > > > handover is a dynamic situation that could cause the QoS > > > > > provided to > > > > > > > > > change. > > > > > > > > > > > > > > > > > > I have been told there is no issue, but here's a > > > frightening > > > > > > > > > scenario: > > > > > > > > > > > > > > > > > > - a handover takes place, and context > > transfer has > > > been > > > > > used > > > > > > > > > to > > > > > > > > > move the QoS context to the new routers (by the > > > > > requirements > > > > > > > > > for > > > > > > > > > CT this could be intra-, or inter- > > technology. Some > > > of us > > > > > > > > > believe > > > > > > > > > that for "seamless" handovers, the > > context will be > > > > > available > > > > > > > at > > > > > > > > > > > > > > > > > > routers before the first packets need to be > > > forwarded. > > > > > This > > > > > > > > > implies > > > > > > > > > that there is a relationship, probabilistic > > perhaps, > > > > > between > > > > > > > > > the handover process and the target ARs for CT. > > > > > > > > > > > > > > > > > > - CARD is used by the MN to influence the handover > > > decision > > > > > (it > > > > > > > > > is not clear to me how this happens, but it seems > > > clear > > > > > that > > > > > > > > > for a more "seamless" handover, the MN > > should chose > > > an AR > > > > > > > that > > > > > > > > > has received the appropriate context; if > > not, then > > > what? > > > > > > > > > > > > > > > > > > - NSIS kicks in and starts re-negotiating > > QoS because > > > of > > > > > > > changes > > > > > > > > > introduced by the handover; > > > > > > > > > > > > > > > > > > How do these three protocols interact to produce > > > predictable > > > > > > > > > outcomes? > > > > > > > > > Or, perhaps, the question is, how do the functional > > entities > > > > > > > > > associated > > > > > > > > > with the three protocols interact before, > > during and after > > a > > > > > > > handover? > > > > > > > > > > > > > > > > > > If it the interaction is within the functional entities, > > the > > > > > > > > > respective > > > > > > > > > wg's could declare the issue out of scope, but this > > approach > > > > > does > > > > > > > not > > > > > > > > > sit well with me, for it seems to defer the > > problem to the > > > > > people > > > > > > > who > > > > > > > > > have to implement this "stuff". > > > > > > > > > > > > > > > > > > Am I imagining things? > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > Gary > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: Hemant.Chaskar@nokia.com > > > > > [mailto:Hemant.Chaskar@nokia.com] > > > > > > > > > > Sent: April 4, 2002 22:33 > > > > > > > > > > To: nsis@ietf.org > > > > > > > > > > Subject: RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Sharif: > > > > > > > > > > > > > > > > > > > > There is currently a debate going on in Seamoby as to > > > whether > > > > > > > > > > this QoS negotiation be covered by NSIS or > > Seamoby (CAR > > > > > > > > > > discovery protocol). > > > > > > > > > > > > > > > > > > > > IMHO it should be covered by CAR discovery > > and not NSIS. > > > CAR > > > > > > > > > > discovery is supposed to identify candidate access > > routers > > > > > > > > > > for handoff and QoS is an important property for > > > candidacy. > > > > > > > > > > > > > > > > > > > > Br, > > > > > > > > > > Hemant > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: ext Shahrier, Sharif M. > > > > > > > > > > [mailto:Sharif.Shahrier@InterDigital.com] > > > > > > > > > > Sent: Thursday, April 04, 2002 3:35 PM > > > > > > > > > > To: Shahrier, Sharif M. > > > > > > > > > > Cc: 'nsis@ietf.org' > > > > > > > > > > Subject: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I have a question for clarification. > > > > > > > > > > > > > > > > > > > > I think it was stated that NSIS should only > > be concerned > > > with > > > > > the > > > > > > > > > > establishment of QoS after handoff. > > > > > > > > > > > > > > > > > > > > This is inconvienent with respect to IP-level QoS > > > > > > > > > > negotiation, which ideally > > > > > > > > > > should be done before handoff has taken place. > > > > > > > > > > > > > > > > > > > > QoS negotiation is in the current requirements draft. > > > > > > > > > > > > > > > > > > > > So, NSIS signaling protocol development should be > > > concerned > > > > > > > > > > with activity > > > > > > > > > > before handoff occurs. > > > > > > > > > > > > > > > > > > > > Sharif. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > Seamoby mailing list > > > > > > > > Seamoby@ietf.org > > > > > > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > Seamoby mailing list > > > > > > Seamoby@ietf.org > > > > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Seamoby mailing list > > > > Seamoby@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > > > > > _______________________________________________ > > > Seamoby mailing list > > > Seamoby@ietf.org > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > _______________________________________________ > > > Seamoby mailing list > > > Seamoby@ietf.org > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Mon Apr 8 15:32:51 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03800 for ; Mon, 8 Apr 2002 15:32:51 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA02544 for nsis-archive@odin.ietf.org; Mon, 8 Apr 2002 15:32:53 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA29061; Mon, 8 Apr 2002 14:43:28 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA28973 for ; Mon, 8 Apr 2002 14:43:22 -0400 (EDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02298; Mon, 8 Apr 2002 14:42:48 -0400 (EDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA26810; Mon, 8 Apr 2002 11:42:18 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g38IgHD04032; Mon, 8 Apr 2002 11:42:17 -0700 X-mProtect: <200204081842> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdZ3sGfB; Mon, 08 Apr 2002 11:42:15 PDT Message-ID: <3CB1E487.5D2B7B37@iprg.nokia.com> Date: Mon, 08 Apr 2002 11:42:16 -0700 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Gary Kenward CC: Nakhjiri Madjid-MNAKHJI1 , Hemant.Chaskar@nokia.com, nsis@ietf.org, seamoby@ietf.org Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. References: <9FBD322B7824D511B36900508BF93C9C01AA49E6@zcard031.ca.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit Gary Kenward wrote: > > > Rajeev: > > In order for the MN to "recreate the context", the MN would > have to understand the semantics of Context transfer, etc., The MN does not have to know the CT semantics. It only needs to understand a notification message that provides the error condition related to its context. > > and, more important, there would have to be a protocol or > protocols that would allow the MN to recreate contexts at an AR. > I doubt that the latter is going to happen (e.g. authentication). > Well, the MN should use whatever protocol was used that established the context in the first place, including for authentication. > > IF and when a CT fails, the easiest way to "recreate" context > is for the sessions to be dropped. This may seem drastic, > but in reality, what is going to cause CT to fail and > how often will this happen? > This is a drastic idea! I think we can do better. For one thing, you still have connectivity which you could use to notify the MN so that the MN can resort to re-establishing contexts (or not). Besides, CT is a protocol, and like any other protocol has error cases and failure modes. There must be a notification message that provides protocol robustness. An example that has been brought up is where the transferred context is not useful, either partially or entirely. You would like to notify the MN when this happens. > > There may be mitigating actions that could be taken to re-establish > certain sessions. But these decisions are must be driven by the policy > > of the network administration (explicit or implicity), and comply > with the security, resource management and accounting requirements > for the network. Hopefully, none of these mitigating actions requires > more over-the-air signalling. > And, why are these any better when CT fails compared to notifying a MN ? Seems to me that a notification message would not encumber any of the above overheads. You leave it up to the MN. -Rajeev > > Gary > > > -----Original Message----- > > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] > > Sent: April 5, 2002 17:46 > > To: Nakhjiri Madjid-MNAKHJI1 > > Cc: Kenward, Gary [WDLN2:AN10:EXCH]; Hemant.Chaskar@nokia.com; > > nsis@ietf.org; seamoby@ietf.org > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > > > Hello Madjid, > > > > Nakhjiri Madjid-MNAKHJI1 wrote: > > > > > Hello Rajeev, > > > > > > I agreed with everything you say below, except one thing: > > > CT can only transfer whatever QoS state that is usable at the > newAR. > > > If the new network is using a different QoS technology with > > different > > > QoS parameters, then I am not sure if CT by itself can do > > the job, unless > > > you add your own mapping functionality. > > > > > > > This would be an example where the new AR sends a > > notification to the MN so that the MN can take > > appropriate action (for instance, attempt to > > re-create the context). > > > > Regards, > > > > -Rajeev > > > > > > > > > > BR, > > > Madjid > > > > > > -----Original Message----- > > > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] > > > Sent: Friday, April 05, 2002 11:01 AM > > > To: Gary Kenward > > > Cc: Hemant.Chaskar@nokia.com; nsis@ietf.org; seamoby@ietf.org > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > Hello, > > > > > > well, if the issue is QoS establishment after handover, > > > > > > - CT is applicable for establishing QoS state at the AR > > > - if further signaling is desired beyond the AR, NSIS may > > > consider it. I don't see how _signaling_ for QoS establishment > > > > beyond AR is relevant for seamoby. > > > > > > CAR _discovery_ could exchange QoS capability as one of the > > > parameters that might then be fed to a selection algorithm. Any > > > signaling for actually establishing QoS itself beyond the AR > > > should be outside the scope of seamoby.. > > > > > > Regards, > > > > > > -Rajeev > > > > > > Gary Kenward wrote: > > > > > > > > > > > > > > > Hemant: > > > > > > > > Just a point of clarification, but as I understand CARD (and > > > > I don't understand it well), it is not a QoS negotiation > > > > protocol. The main application that you are referring to > primarily > > > > arises out of a perceived need to determine at the MN the > > best link > > > > layer to handover over to when inter-technology handovers are > > > > involved. > > > > It can be applied to intra-technology handovers, but the value > in > > > > that situation is highly questionable (e.g. since it is a > > discovery > > > > protocol, the implication is that the purpose is to determine > the > > > > choice of channels available; for intra-technology > > handovers, there > > > > are many, many reasons why this "choice" may not be available). > > > > > > > > There is a requirement, 5.1.2, which seems to imply > > NSIS involvement > > > > > > > > during/after a handover. John has stated that this is not the > > > > intention > > > > (please correct me if I have this wrong John), in which > > case I think > > > > 5.1.2 needs to be clarified. > > > > > > > > Specifically, is NSIS to be used to negotiated new QoS for an > > > > existing flow after a handover, or is it specifically for > > establishing > > > > > > > > QoS for a new flow? I don't think the answer is boolean: the > role > > > > of NSIS in QoS re-negotiation is still open, I believe, > > and clearly > > > > handover is a dynamic situation that could cause the QoS > > provided to > > > > change. > > > > > > > > I have been told there is no issue, but here's a frightening > > > > scenario: > > > > > > > > - a handover takes place, and context transfer > > has been used > > > > to > > > > move the QoS context to the new routers (by the > > requirements > > > > for > > > > CT this could be intra-, or inter- technology. Some of us > > > > > believe > > > > that for "seamless" handovers, the context will be > > available at > > > > > > > > routers before the first packets need to be forwarded. > This > > > > implies > > > > that there is a relationship, probabilistic > > perhaps, between > > > > the handover process and the target ARs for CT. > > > > > > > > - CARD is used by the MN to influence the handover > > decision (it > > > > is not clear to me how this happens, but it seems > > clear that > > > > for a more "seamless" handover, the MN should > > chose an AR that > > > > has received the appropriate context; if not, then what? > > > > > > > > - NSIS kicks in and starts re-negotiating QoS > > because of changes > > > > introduced by the handover; > > > > > > > > How do these three protocols interact to produce predictable > > > > outcomes? > > > > Or, perhaps, the question is, how do the functional entities > > > > associated > > > > with the three protocols interact before, during and > > after a handover? > > > > > > > > If it the interaction is within the functional entities, the > > > > respective > > > > wg's could declare the issue out of scope, but this > > approach does not > > > > sit well with me, for it seems to defer the problem to > > the people who > > > > have to implement this "stuff". > > > > > > > > Am I imagining things? > > > > > > > > Cheers, > > > > Gary > > > > > > > > > -----Original Message----- > > > > > From: Hemant.Chaskar@nokia.com > [mailto:Hemant.Chaskar@nokia.com] > > > > > Sent: April 4, 2002 22:33 > > > > > To: nsis@ietf.org > > > > > Subject: RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > > > Hi Sharif: > > > > > > > > > > There is currently a debate going on in Seamoby as to whether > > > > > this QoS negotiation be covered by NSIS or Seamoby (CAR > > > > > discovery protocol). > > > > > > > > > > IMHO it should be covered by CAR discovery and not NSIS. CAR > > > > > discovery is supposed to identify candidate access routers > > > > > for handoff and QoS is an important property for candidacy. > > > > > > > > > > Br, > > > > > Hemant > > > > > > > > > > -----Original Message----- > > > > > From: ext Shahrier, Sharif M. > > > > > [mailto:Sharif.Shahrier@InterDigital.com] > > > > > Sent: Thursday, April 04, 2002 3:35 PM > > > > > To: Shahrier, Sharif M. > > > > > Cc: 'nsis@ietf.org' > > > > > Subject: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > > > > > > > > I have a question for clarification. > > > > > > > > > > I think it was stated that NSIS should only be > > concerned with the > > > > > establishment of QoS after handoff. > > > > > > > > > > This is inconvienent with respect to IP-level QoS > > > > > negotiation, which ideally > > > > > should be done before handoff has taken place. > > > > > > > > > > QoS negotiation is in the current requirements draft. > > > > > > > > > > So, NSIS signaling protocol development should be concerned > > > > > with activity > > > > > before handoff occurs. > > > > > > > > > > Sharif. > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > 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 > > > > > > > > > > > _______________________________________________ > > > Seamoby mailing list > > > Seamoby@ietf.org > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > _______________________________________________ > > > Seamoby mailing list > > > Seamoby@ietf.org > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Mon Apr 8 15:59:42 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04562 for ; Mon, 8 Apr 2002 15:59:42 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA05377 for nsis-archive@odin.ietf.org; Mon, 8 Apr 2002 15:59:45 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA00956; Mon, 8 Apr 2002 15:08:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA00930 for ; Mon, 8 Apr 2002 15:08:07 -0400 (EDT) Received: from idcpa4.pa.interdigital.com (idcmail.interdigital.com [12.32.197.142]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03168 for ; Mon, 8 Apr 2002 15:08:03 -0400 (EDT) Received: by idcpa4.pa.interdigital.com with Internet Mail Service (5.5.2653.19) id <2PXHYR7F>; Mon, 8 Apr 2002 15:06:20 -0400 Message-ID: From: "Shahrier, Sharif M." To: "'john.loughney@nokia.com'" , gkenward@nortelnetworks.com Cc: nsis@ietf.org Subject: RE: [NSIS] On the definition of QoS flow and aggregate flow. Date: Mon, 8 Apr 2002 15:06:19 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org I don't see how finding a "general solution" would not permit classifying different QoS types. There had been some discussions that flow-ids and other types of indentifiers were available for these purposes. However, I am not able to find any RFCs that describes this. Sharif. -----Original Message----- From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] Sent: Monday, April 08, 2002 4:20 AM To: gkenward@nortelnetworks.com Cc: nsis@ietf.org Subject: RE: [NSIS] On the definition of QoS flow and aggregate flow. Hi Gary, > Perhaps I am missing an important issue here with the semantics of a QoS > control protocol, but given the scope of the requirements, I see NSIS as > being more of a container protocol then an SS7 or UNI protocol. This allows > NSIS to be used in a variety of network implementations. I am on the same page as you are with this. We are not designing a solution for a particular network or sevice. To be successful, we need to work on a general solution. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Mon Apr 8 16:14:14 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04949 for ; Mon, 8 Apr 2002 16:14:14 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA07084 for nsis-archive@odin.ietf.org; Mon, 8 Apr 2002 16:14:17 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA04810; Mon, 8 Apr 2002 15:54:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA04661 for ; Mon, 8 Apr 2002 15:53:55 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04360; Mon, 8 Apr 2002 15:53:48 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g38JnGt15942; Mon, 8 Apr 2002 15:49:16 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 8 Apr 2002 15:49:16 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA49ED@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'James Kempf'" , "'Rajeev Koodli'" , Nakhjiri Madjid-MNAKHJI1 Cc: Hemant.Chaskar@nokia.com, nsis@ietf.org, seamoby@ietf.org Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Mon, 8 Apr 2002 15:49:16 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DF36.311DDED6" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1DF36.311DDED6 Content-Type: text/plain; charset="iso-8859-1" "Re-create" was Rajeev's term, not mine. I think that it is an appropriate term if one considers other mechanisms besides session setup signalling. Either way, it is not a CT function. As I outlined in one of my other posts, why would you perform CT to an AR that did not have the necessary capabilities. Is this actually about CAR failure?? Gary > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: April 8, 2002 14:26 > To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Rajeev Koodli'; Nakhjiri > Madjid-MNAKHJI1 > Cc: Hemant.Chaskar@nokia.com; nsis@ietf.org; seamoby@ietf.org > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > Gary, > > I don't think the issue is having the MN re-create the context. Is is > allowing the MN to recover by re-running the actions that > were necessary > to create the context in the first place, in the event the AR > was unable > to interpret it. > Thus, for example, suppose that QoS context is transferred from old to > new AR, but new AR for some reason can't interpret it, > perhaps there is > no bandwidth left or perhaps the new AR uses a different > representation > for QoS context. The MN would need to be informed somehow so that it > could re-do its QoS signaling. > > jak > > ----- Original Message ----- > From: "Gary Kenward" > To: "'Rajeev Koodli'" ; "Nakhjiri > Madjid-MNAKHJI1" > Cc: ; ; > Sent: Monday, April 08, 2002 10:54 AM > Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > Rajeev: > > > > In order for the MN to "recreate the context", the MN would > > have to understand the semantics of Context transfer, etc., > > and, more important, there would have to be a protocol or > > protocols that would allow the MN to recreate contexts at an AR. > > I doubt that the latter is going to happen (e.g. authentication). > > > > IF and when a CT fails, the easiest way to "recreate" context > > is for the sessions to be dropped. This may seem drastic, > > but in reality, what is going to cause CT to fail and > > how often will this happen? > > > > There may be mitigating actions that could be taken to re-establish > > certain sessions. But these decisions are must be driven by > the policy > > of the network administration (explicit or implicity), and comply > > with the security, resource management and accounting requirements > > for the network. Hopefully, none of these mitigating > actions requires > > more over-the-air signalling. > > > > Gary > > > > > -----Original Message----- > > > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] > > > Sent: April 5, 2002 17:46 > > > To: Nakhjiri Madjid-MNAKHJI1 > > > Cc: Kenward, Gary [WDLN2:AN10:EXCH]; Hemant.Chaskar@nokia.com; > > > nsis@ietf.org; seamoby@ietf.org > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > Hello Madjid, > > > > > > Nakhjiri Madjid-MNAKHJI1 wrote: > > > > > > > Hello Rajeev, > > > > > > > > I agreed with everything you say below, except one thing: > > > > CT can only transfer whatever QoS state that is usable at the > newAR. > > > > If the new network is using a different QoS technology with > > > different > > > > QoS parameters, then I am not sure if CT by itself can do > > > the job, unless > > > > you add your own mapping functionality. > > > > > > > > > > This would be an example where the new AR sends a > > > notification to the MN so that the MN can take > > > appropriate action (for instance, attempt to > > > re-create the context). > > > > > > Regards, > > > > > > -Rajeev > > > > > > > > > > > > > > BR, > > > > Madjid > > > > > > > > -----Original Message----- > > > > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] > > > > Sent: Friday, April 05, 2002 11:01 AM > > > > To: Gary Kenward > > > > Cc: Hemant.Chaskar@nokia.com; nsis@ietf.org; seamoby@ietf.org > > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS > after handoff. > > > > > > > > Hello, > > > > > > > > well, if the issue is QoS establishment after handover, > > > > > > > > - CT is applicable for establishing QoS state at the AR > > > > - if further signaling is desired beyond the AR, NSIS may > > > > consider it. I don't see how _signaling_ for QoS > establishment > > > > beyond AR is relevant for seamoby. > > > > > > > > CAR _discovery_ could exchange QoS capability as one of the > > > > parameters that might then be fed to a selection algorithm. Any > > > > signaling for actually establishing QoS itself beyond the AR > > > > should be outside the scope of seamoby.. > > > > > > > > Regards, > > > > > > > > -Rajeev > > > > > > > > Gary Kenward wrote: > > > > > > > > > > > > > > > > > > > Hemant: > > > > > > > > > > Just a point of clarification, but as I understand CARD (and > > > > > I don't understand it well), it is not a QoS negotiation > > > > > protocol. The main application that you are referring to > primarily > > > > > arises out of a perceived need to determine at the MN the > > > best link > > > > > layer to handover over to when inter-technology handovers are > > > > > involved. > > > > > It can be applied to intra-technology handovers, but the value > in > > > > > that situation is highly questionable (e.g. since it is a > > > discovery > > > > > protocol, the implication is that the purpose is to determine > the > > > > > choice of channels available; for intra-technology > > > handovers, there > > > > > are many, many reasons why this "choice" may not be > available). > > > > > > > > > > There is a requirement, 5.1.2, which seems to imply > > > NSIS involvement > > > > > > > > > > during/after a handover. John has stated that this is not the > > > > > intention > > > > > (please correct me if I have this wrong John), in which > > > case I think > > > > > 5.1.2 needs to be clarified. > > > > > > > > > > Specifically, is NSIS to be used to negotiated new > QoS for an > > > > > existing flow after a handover, or is it specifically for > > > establishing > > > > > > > > > > QoS for a new flow? I don't think the answer is boolean: the > role > > > > > of NSIS in QoS re-negotiation is still open, I believe, > > > and clearly > > > > > handover is a dynamic situation that could cause the QoS > > > provided to > > > > > change. > > > > > > > > > > I have been told there is no issue, but here's a frightening > > > > > scenario: > > > > > > > > > > - a handover takes place, and context transfer > > > has been used > > > > > to > > > > > move the QoS context to the new routers (by the > > > requirements > > > > > for > > > > > CT this could be intra-, or inter- technology. > Some of us > > > > > believe > > > > > that for "seamless" handovers, the context will be > > > available at > > > > > > > > > > routers before the first packets need to be forwarded. > This > > > > > implies > > > > > that there is a relationship, probabilistic > > > perhaps, between > > > > > the handover process and the target ARs for CT. > > > > > > > > > > - CARD is used by the MN to influence the handover > > > decision (it > > > > > is not clear to me how this happens, but it seems > > > clear that > > > > > for a more "seamless" handover, the MN should > > > chose an AR that > > > > > has received the appropriate context; if not, > then what? > > > > > > > > > > - NSIS kicks in and starts re-negotiating QoS > > > because of changes > > > > > introduced by the handover; > > > > > > > > > > How do these three protocols interact to produce predictable > > > > > outcomes? > > > > > Or, perhaps, the question is, how do the functional entities > > > > > associated > > > > > with the three protocols interact before, during and > > > after a handover? > > > > > > > > > > If it the interaction is within the functional entities, the > > > > > respective > > > > > wg's could declare the issue out of scope, but this > > > approach does not > > > > > sit well with me, for it seems to defer the problem to > > > the people who > > > > > have to implement this "stuff". > > > > > > > > > > Am I imagining things? > > > > > > > > > > Cheers, > > > > > Gary > > > > > > > > > > > -----Original Message----- > > > > > > From: Hemant.Chaskar@nokia.com > [mailto:Hemant.Chaskar@nokia.com] > > > > > > Sent: April 4, 2002 22:33 > > > > > > To: nsis@ietf.org > > > > > > Subject: RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > > > > > > Hi Sharif: > > > > > > > > > > > > There is currently a debate going on in Seamoby as > to whether > > > > > > this QoS negotiation be covered by NSIS or Seamoby (CAR > > > > > > discovery protocol). > > > > > > > > > > > > IMHO it should be covered by CAR discovery and not NSIS. CAR > > > > > > discovery is supposed to identify candidate access routers > > > > > > for handoff and QoS is an important property for candidacy. > > > > > > > > > > > > Br, > > > > > > Hemant > > > > > > > > > > > > -----Original Message----- > > > > > > From: ext Shahrier, Sharif M. > > > > > > [mailto:Sharif.Shahrier@InterDigital.com] > > > > > > Sent: Thursday, April 04, 2002 3:35 PM > > > > > > To: Shahrier, Sharif M. > > > > > > Cc: 'nsis@ietf.org' > > > > > > Subject: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > > > > > > > > > > > > I have a question for clarification. > > > > > > > > > > > > I think it was stated that NSIS should only be > > > concerned with the > > > > > > establishment of QoS after handoff. > > > > > > > > > > > > This is inconvienent with respect to IP-level QoS > > > > > > negotiation, which ideally > > > > > > should be done before handoff has taken place. > > > > > > > > > > > > QoS negotiation is in the current requirements draft. > > > > > > > > > > > > So, NSIS signaling protocol development should be concerned > > > > > > with activity > > > > > > before handoff occurs. > > > > > > > > > > > > Sharif. > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > 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 > > > > > > > > > > > > > > _______________________________________________ > > > > Seamoby mailing list > > > > Seamoby@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > _______________________________________________ > > > > Seamoby mailing list > > > > Seamoby@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > > ------_=_NextPart_001_01C1DF36.311DDED6 Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff.

"Re-create" was Rajeev's term, not mine. I think that it is an appropriate
term if one considers other mechanisms besides session setup signalling.
Either way, it is not a CT function.

As I outlined in one of my other posts, why would you perform CT to an
AR that did not have the necessary capabilities. Is this actually about
CAR failure??

Gary

> -----Original Message-----
> From: James Kempf [mailto:kempf@docomolabs-usa.com]
> Sent: April 8, 2002 14:26
> To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Rajeev Koodli'; Nakhjiri
> Madjid-MNAKHJI1
> Cc: Hemant.Chaskar@nokia.com; nsis@ietf.org; seamoby@ietf.org
> Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff.
>
>
> Gary,
>
> I don't think the issue is having the MN re-create the context. Is is
> allowing the MN to recover by re-running the actions that
> were necessary
> to create the context in the first place, in the event the AR
> was unable
> to interpret it.
> Thus, for example, suppose that QoS context is transferred from old to
> new AR, but new AR for some reason can't interpret it,
> perhaps there is
> no bandwidth left or perhaps the new AR uses a different
> representation
> for QoS context. The MN would need to be informed somehow so that it
> could re-do its QoS signaling.
>
>             jak
>
> ----- Original Message -----
> From: "Gary Kenward" <gkenward@nortelnetworks.com>
> To: "'Rajeev Koodli'" <rajeev@iprg.nokia.com>; "Nakhjiri
> Madjid-MNAKHJI1" <Madjid.Nakhjiri@motorola.com>
> Cc: <Hemant.Chaskar@nokia.com>; <nsis@ietf.org>; <seamoby@ietf.org>
> Sent: Monday, April 08, 2002 10:54 AM
> Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff.
>
>
> > Rajeev:
> >
> > In order for the MN to "recreate the context", the MN would
> > have to understand the semantics of Context transfer, etc.,
> > and, more important, there would have to be a protocol or
> > protocols that would allow the MN to recreate contexts at an AR.
> > I doubt that the latter is going to happen (e.g. authentication).
> >
> > IF and when a CT fails, the easiest way to "recreate" context
> > is for the sessions to be dropped. This may seem drastic,
> > but in reality, what is going to cause CT to fail and
> > how often will this happen?
> >
> > There may be mitigating actions that could be taken to re-establish
> > certain sessions. But these decisions are must be driven by
> the policy
> > of the network administration (explicit or implicity), and comply
> > with the security, resource management and accounting requirements
> > for the network. Hopefully, none of these mitigating
> actions requires
> > more over-the-air signalling.
> >
> > Gary
> >
> > > -----Original Message-----
> > > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com]
> > > Sent: April 5, 2002 17:46
> > > To: Nakhjiri Madjid-MNAKHJI1
> > > Cc: Kenward, Gary [WDLN2:AN10:EXCH]; Hemant.Chaskar@nokia.com;
> > > nsis@ietf.org; seamoby@ietf.org
> > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff.
> > >
> > >
> > >
> > > Hello Madjid,
> > >
> > > Nakhjiri Madjid-MNAKHJI1 wrote:
> > >
> > > > Hello Rajeev,
> > > >
> > > > I agreed with everything you say below, except one thing:
> > > > CT can only transfer whatever QoS state that is usable at the
> newAR.
> > > > If the new network is using a different QoS technology with
> > > different
> > > > QoS parameters, then I am not sure if CT by itself can do
> > > the job, unless
> > > > you add your own mapping functionality.
> > > >
> > >
> > > This would be an example where the new AR sends a
> > > notification to the MN so that the MN can take
> > > appropriate action (for instance, attempt to
> > > re-create the context).
> > >
> > > Regards,
> > >
> > > -Rajeev
> > >
> > >
> > > >
> > > > BR,
> > > > Madjid
> > > >
> > > > -----Original Message-----
> > > > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com]
> > > > Sent: Friday, April 05, 2002 11:01 AM
> > > > To: Gary Kenward
> > > > Cc: Hemant.Chaskar@nokia.com; nsis@ietf.org; seamoby@ietf.org
> > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS
> after handoff.
> > > >
> > > > Hello,
> > > >
> > > > well, if the issue is QoS establishment after handover,
> > > >
> > > > - CT is applicable for establishing QoS state at the AR
> > > > - if further signaling is desired beyond the AR, NSIS may
> > > >     consider it. I don't see how _signaling_ for QoS
> establishment
> > > >     beyond AR is relevant for seamoby.
> > > >
> > > > CAR _discovery_ could exchange QoS capability as one of the
> > > > parameters that might then be fed to a selection algorithm. Any
> > > > signaling for actually establishing QoS itself beyond the AR
> > > > should be outside the scope of seamoby..
> > > >
> > > > Regards,
> > > >
> > > > -Rajeev
> > > >
> > > > Gary Kenward wrote:
> > > >
> > > > >
> > > > >
> > > > > Hemant:
> > > > >
> > > > >   Just a point of clarification, but as I understand CARD (and
> > > > > I don't understand it well), it is not a QoS negotiation
> > > > > protocol. The main application that you are referring to
> primarily
> > > > > arises out of a perceived need to determine at the MN the
> > > best link
> > > > > layer to handover over to when inter-technology handovers are
> > > > > involved.
> > > > > It can be applied to intra-technology handovers, but the value
> in
> > > > > that situation is highly questionable (e.g. since it is a
> > > discovery
> > > > > protocol, the implication is that the purpose is to determine
> the
> > > > > choice of channels available; for intra-technology
> > > handovers, there
> > > > > are many, many reasons why this "choice" may not be
> available).
> > > > >
> > > > >   There is a requirement, 5.1.2, which seems to imply
> > > NSIS involvement
> > > > >
> > > > > during/after a handover. John has stated that this is not the
> > > > > intention
> > > > > (please correct me if I have this wrong John), in which
> > > case I think
> > > > > 5.1.2 needs to be clarified.
> > > > >
> > > > >   Specifically, is NSIS to be used to negotiated new
> QoS for an
> > > > > existing flow after a handover, or is it specifically for
> > > establishing
> > > > >
> > > > > QoS for a new flow? I don't think the answer is boolean: the
> role
> > > > > of NSIS in QoS re-negotiation is still open, I believe,
> > > and clearly
> > > > > handover is a dynamic situation that could cause the QoS
> > > provided to
> > > > > change.
> > > > >
> > > > >   I have been told there is no issue, but here's a frightening
> > > > > scenario:
> > > > >
> > > > >         - a handover takes place, and context transfer
> > > has been used
> > > > > to
> > > > >        move the QoS context to the new routers (by the
> > > requirements
> > > > > for
> > > > >        CT this could be intra-, or inter- technology.
> Some of us
> > > > > believe
> > > > >        that for "seamless" handovers, the context will be
> > > available at
> > > > >
> > > > >        routers before the first packets need to be forwarded.
> This
> > > > > implies
> > > > >        that there is a relationship, probabilistic
> > > perhaps, between
> > > > >        the handover process and the target ARs for CT.
> > > > >
> > > > >      - CARD is used by the MN to influence the handover
> > > decision (it
> > > > >        is not clear to me how this happens, but it seems
> > > clear that
> > > > >        for a more "seamless" handover, the MN should
> > > chose an AR that
> > > > >        has received the appropriate context; if not,
> then what?
> > > > >
> > > > >      - NSIS kicks in and starts re-negotiating QoS
> > > because of changes
> > > > >        introduced by the handover;
> > > > >
> > > > >   How do these three protocols interact to produce predictable
> > > > > outcomes?
> > > > > Or, perhaps, the question is, how do the functional entities
> > > > > associated
> > > > > with the three protocols interact before, during and
> > > after a handover?
> > > > >
> > > > > If it the interaction is within the functional entities, the
> > > > > respective
> > > > > wg's could declare the issue out of scope, but this
> > > approach does not
> > > > > sit well with me, for it seems to defer the problem to
> > > the people who
> > > > > have to implement this "stuff".
> > > > >
> > > > >   Am I imagining things?
> > > > >
> > > > > Cheers,
> > > > > Gary
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Hemant.Chaskar@nokia.com
> [mailto:Hemant.Chaskar@nokia.com]
> > > > > > Sent: April 4, 2002 22:33
> > > > > > To: nsis@ietf.org
> > > > > > Subject: RE: [NSIS] Establishing QoS after handoff.
> > > > > >
> > > > > >
> > > > > > Hi Sharif:
> > > > > >
> > > > > > There is currently a debate going on in Seamoby as
> to whether
> > > > > > this QoS negotiation be covered by NSIS or Seamoby (CAR
> > > > > > discovery protocol).
> > > > > >
> > > > > > IMHO it should be covered by CAR discovery and not NSIS. CAR
> > > > > > discovery is supposed to identify candidate access routers
> > > > > > for handoff and QoS is an important property for candidacy.
> > > > > >
> > > > > > Br,
> > > > > > Hemant
> > > > > >
> > > > > > -----Original Message-----
> > > > > > From: ext Shahrier, Sharif M.
> > > > > > [mailto:Sharif.Shahrier@InterDigital.com]
> > > > > > Sent: Thursday, April 04, 2002 3:35 PM
> > > > > > To: Shahrier, Sharif M.
> > > > > > Cc: 'nsis@ietf.org'
> > > > > > Subject: [NSIS] Establishing QoS after handoff.
> > > > > >
> > > > > >
> > > > > >
> > > > > > I have a question for clarification.
> > > > > >
> > > > > > I think it was stated that NSIS should only be
> > > concerned with the
> > > > > > establishment of QoS after handoff.
> > > > > >
> > > > > > This is inconvienent with respect to IP-level QoS
> > > > > > negotiation, which ideally
> > > > > > should be done before handoff has taken place.
> > > > > >
> > > > > > QoS negotiation is in the current requirements draft.
> > > > > >
> > > > > > So, NSIS signaling protocol development should be concerned
> > > > > > with activity
> > > > > > before handoff occurs.
> > > > > >
> > > > > > Sharif.
> > > > > >
> > > > > >
> > > > > >
> > > > > > _______________________________________________
> > > > > > 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
> > > > > >
> > > >
> > > > _______________________________________________
> > > > Seamoby mailing list
> > > > Seamoby@ietf.org
> > > > https://www1.ietf.org/mailman/listinfo/seamoby
> > > >
> > > > _______________________________________________
> > > > Seamoby mailing list
> > > > Seamoby@ietf.org
> > > > https://www1.ietf.org/mailman/listinfo/seamoby
> > >
> > >
> >
>
>

------_=_NextPart_001_01C1DF36.311DDED6-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Mon Apr 8 16:26:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05281 for ; Mon, 8 Apr 2002 16:26:16 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA08007 for nsis-archive@odin.ietf.org; Mon, 8 Apr 2002 16:26:19 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA05788; Mon, 8 Apr 2002 16:01:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA05734 for ; Mon, 8 Apr 2002 16:01:15 -0400 (EDT) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04595; Mon, 8 Apr 2002 16:01:11 -0400 (EDT) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g38JufI28657; Mon, 8 Apr 2002 12:56:41 -0700 (PDT) Message-ID: <036801c1df37$46aa3640$7e6015ac@T23KEMPF> From: "James Kempf" To: "Gary Kenward" , "'Rajeev Koodli'" , "Nakhjiri Madjid-MNAKHJI1" Cc: , , References: <9FBD322B7824D511B36900508BF93C9C01AA49ED@zcard031.ca.nortel.com> Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Mon, 8 Apr 2002 12:55:04 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit > As I outlined in one of my other posts, why would you perform CT to an > AR that did not have the necessary capabilities. Is this actually about > CAR failure?? > Yes and no. Suppose the MN is expecting CT to be performed and it is not because the new AR can't interpret the context. The old AR may discover this via CAR, but if there is no way to communicate it to the MN, then the MN can't know to perform the signaling from scratch on the new AR. One could either inform the MN beforehand to do the signaling, as is done with FMIPv6/BETH, or signal the MN on the new AR. For dynamic failures, such as when the AR runs out of Gold Class service, the signaling could only be done afterwards. jak _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Mon Apr 8 16:35:20 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05599 for ; Mon, 8 Apr 2002 16:35:16 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA09187 for nsis-archive@odin.ietf.org; Mon, 8 Apr 2002 16:35:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA07047; Mon, 8 Apr 2002 16:13:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA06900 for ; Mon, 8 Apr 2002 16:13:38 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04941; Mon, 8 Apr 2002 16:13:34 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g38K8ji09475; Mon, 8 Apr 2002 16:08:46 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 8 Apr 2002 16:08:45 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA49EF@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Rajeev Koodli'" Cc: Nakhjiri Madjid-MNAKHJI1 , Hemant.Chaskar@nokia.com, nsis@ietf.org, seamoby@ietf.org Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Mon, 8 Apr 2002 16:08:42 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DF39.2E13BD20" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1DF39.2E13BD20 Content-Type: text/plain; charset="iso-8859-1" Rajeev: A user starts up an application that requests a "gold service". The protocol stack (perhaps an NSIS protocol stack) sends in a request from MN to AN for gold service". A handover occurs, and (according to your scenario), the QoS context transfer fails (for some inexplicable reason). Some entity (the CT protocol stack according to your proposal) sends an indication to the MN that the QoS context transfer has failed (according to your proposal). How does the MN know what to do with this notice? The MN has to understand: - what a handover is at the IP level - what an IP context transfer is - that QoS context is (sometimes) transferred separately from other context - what the nature of the failure was, and thus, what action to take. - how and with what entity to initiate QoS re-negotiation. The knowledge for all of the above is either explicitly or implicitly built into the MN. If the intent were for the MN to receive back a message that indicating "Gold service not available" then this is simply a session disconnect. If the intent is for the MN to be told that "the QoS associated with Gold service" has failed, then the MN has to know that Gold service is actually a combination of features (AAA, security, HC), and to initiate negotiation, it has to be able to talk to the individual network entities - entities which may not even exist within a given network (e.g. a provision model). So, how is the MN ignorant of CT? Service models? Keep in mind, according to the CT requirements, CT does not know what is contained in the data chunks it transports. Thus, at best, it can only forward to the MN that data chunk or another, opaque data chunk. Even this capability is a major modification to what should be a simple state machine for the CT protocol. Gary > -----Original Message----- > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] > Sent: April 8, 2002 14:42 > To: Kenward, Gary [WDLN2:AN10:EXCH] > Cc: Nakhjiri Madjid-MNAKHJI1; Hemant.Chaskar@nokia.com; nsis@ietf.org; > seamoby@ietf.org > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > Gary Kenward wrote: > > > > > > > Rajeev: > > > > In order for the MN to "recreate the context", the MN would > > have to understand the semantics of Context transfer, etc., > > The MN does not have to know the CT semantics. > It only needs to understand a notification message > that provides the error condition related to its > context. > > > > > and, more important, there would have to be a protocol or > > protocols that would allow the MN to recreate contexts at an AR. > > I doubt that the latter is going to happen (e.g. authentication). > > > > Well, the MN should use whatever protocol was > used that established the context in the first place, > including for authentication. > > > > > IF and when a CT fails, the easiest way to "recreate" context > > is for the sessions to be dropped. This may seem drastic, > > but in reality, what is going to cause CT to fail and > > how often will this happen? > > > > This is a drastic idea! I think we can do better. > For one thing, you still have connectivity which > you could use to notify the MN so that the MN > can resort to re-establishing contexts (or not). Besides, > CT is a protocol, and like any other protocol has > error cases and failure modes. There must be a > notification message that provides protocol > robustness. > An example that has been brought up is where > the transferred context is not useful, either > partially or entirely. You would like to notify > the MN when this happens. > > > > > > There may be mitigating actions that could be taken to re-establish > > certain sessions. But these decisions are must be driven by > the policy > > > > of the network administration (explicit or implicity), and comply > > with the security, resource management and accounting requirements > > for the network. Hopefully, none of these mitigating > actions requires > > more over-the-air signalling. > > > > And, why are these any better when CT fails compared > to notifying a MN ? Seems to me that a notification message > would not encumber any of the above overheads. You > leave it up to the MN. > > -Rajeev > > > > > > Gary > > > > > -----Original Message----- > > > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] > > > Sent: April 5, 2002 17:46 > > > To: Nakhjiri Madjid-MNAKHJI1 > > > Cc: Kenward, Gary [WDLN2:AN10:EXCH]; Hemant.Chaskar@nokia.com; > > > nsis@ietf.org; seamoby@ietf.org > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > Hello Madjid, > > > > > > Nakhjiri Madjid-MNAKHJI1 wrote: > > > > > > > Hello Rajeev, > > > > > > > > I agreed with everything you say below, except one thing: > > > > CT can only transfer whatever QoS state that is usable at the > > newAR. > > > > If the new network is using a different QoS technology with > > > different > > > > QoS parameters, then I am not sure if CT by itself can do > > > the job, unless > > > > you add your own mapping functionality. > > > > > > > > > > This would be an example where the new AR sends a > > > notification to the MN so that the MN can take > > > appropriate action (for instance, attempt to > > > re-create the context). > > > > > > Regards, > > > > > > -Rajeev > > > > > > > > > > > > > > BR, > > > > Madjid > > > > > > > > -----Original Message----- > > > > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] > > > > Sent: Friday, April 05, 2002 11:01 AM > > > > To: Gary Kenward > > > > Cc: Hemant.Chaskar@nokia.com; nsis@ietf.org; seamoby@ietf.org > > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS > after handoff. > > > > > > > > Hello, > > > > > > > > well, if the issue is QoS establishment after handover, > > > > > > > > - CT is applicable for establishing QoS state at the AR > > > > - if further signaling is desired beyond the AR, NSIS may > > > > consider it. I don't see how _signaling_ for QoS > establishment > > > > > > beyond AR is relevant for seamoby. > > > > > > > > CAR _discovery_ could exchange QoS capability as one of the > > > > parameters that might then be fed to a selection algorithm. Any > > > > signaling for actually establishing QoS itself beyond the AR > > > > should be outside the scope of seamoby.. > > > > > > > > Regards, > > > > > > > > -Rajeev > > > > > > > > Gary Kenward wrote: > > > > > > > > > > > > > > > > > > > Hemant: > > > > > > > > > > Just a point of clarification, but as I understand CARD (and > > > > > I don't understand it well), it is not a QoS negotiation > > > > > protocol. The main application that you are referring to > > primarily > > > > > arises out of a perceived need to determine at the MN the > > > best link > > > > > layer to handover over to when inter-technology handovers are > > > > > involved. > > > > > It can be applied to intra-technology handovers, but the value > > in > > > > > that situation is highly questionable (e.g. since it is a > > > discovery > > > > > protocol, the implication is that the purpose is to determine > > the > > > > > choice of channels available; for intra-technology > > > handovers, there > > > > > are many, many reasons why this "choice" may not be > available). > > > > > > > > > > There is a requirement, 5.1.2, which seems to imply > > > NSIS involvement > > > > > > > > > > during/after a handover. John has stated that this is not the > > > > > intention > > > > > (please correct me if I have this wrong John), in which > > > case I think > > > > > 5.1.2 needs to be clarified. > > > > > > > > > > Specifically, is NSIS to be used to negotiated new > QoS for an > > > > > existing flow after a handover, or is it specifically for > > > establishing > > > > > > > > > > QoS for a new flow? I don't think the answer is boolean: the > > role > > > > > of NSIS in QoS re-negotiation is still open, I believe, > > > and clearly > > > > > handover is a dynamic situation that could cause the QoS > > > provided to > > > > > change. > > > > > > > > > > I have been told there is no issue, but here's a frightening > > > > > scenario: > > > > > > > > > > - a handover takes place, and context transfer > > > has been used > > > > > to > > > > > move the QoS context to the new routers (by the > > > requirements > > > > > for > > > > > CT this could be intra-, or inter- technology. > Some of us > > > > > > > believe > > > > > that for "seamless" handovers, the context will be > > > available at > > > > > > > > > > routers before the first packets need to be forwarded. > > This > > > > > implies > > > > > that there is a relationship, probabilistic > > > perhaps, between > > > > > the handover process and the target ARs for CT. > > > > > > > > > > - CARD is used by the MN to influence the handover > > > decision (it > > > > > is not clear to me how this happens, but it seems > > > clear that > > > > > for a more "seamless" handover, the MN should > > > chose an AR that > > > > > has received the appropriate context; if not, > then what? > > > > > > > > > > - NSIS kicks in and starts re-negotiating QoS > > > because of changes > > > > > introduced by the handover; > > > > > > > > > > How do these three protocols interact to produce predictable > > > > > outcomes? > > > > > Or, perhaps, the question is, how do the functional entities > > > > > associated > > > > > with the three protocols interact before, during and > > > after a handover? > > > > > > > > > > If it the interaction is within the functional entities, the > > > > > respective > > > > > wg's could declare the issue out of scope, but this > > > approach does not > > > > > sit well with me, for it seems to defer the problem to > > > the people who > > > > > have to implement this "stuff". > > > > > > > > > > Am I imagining things? > > > > > > > > > > Cheers, > > > > > Gary > > > > > > > > > > > -----Original Message----- > > > > > > From: Hemant.Chaskar@nokia.com > > [mailto:Hemant.Chaskar@nokia.com] > > > > > > Sent: April 4, 2002 22:33 > > > > > > To: nsis@ietf.org > > > > > > Subject: RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > > > > > > Hi Sharif: > > > > > > > > > > > > There is currently a debate going on in Seamoby as > to whether > > > > > > this QoS negotiation be covered by NSIS or Seamoby (CAR > > > > > > discovery protocol). > > > > > > > > > > > > IMHO it should be covered by CAR discovery and not NSIS. CAR > > > > > > discovery is supposed to identify candidate access routers > > > > > > for handoff and QoS is an important property for candidacy. > > > > > > > > > > > > Br, > > > > > > Hemant > > > > > > > > > > > > -----Original Message----- > > > > > > From: ext Shahrier, Sharif M. > > > > > > [mailto:Sharif.Shahrier@InterDigital.com] > > > > > > Sent: Thursday, April 04, 2002 3:35 PM > > > > > > To: Shahrier, Sharif M. > > > > > > Cc: 'nsis@ietf.org' > > > > > > Subject: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > > > > > > > > > > > > I have a question for clarification. > > > > > > > > > > > > I think it was stated that NSIS should only be > > > concerned with the > > > > > > establishment of QoS after handoff. > > > > > > > > > > > > This is inconvienent with respect to IP-level QoS > > > > > > negotiation, which ideally > > > > > > should be done before handoff has taken place. > > > > > > > > > > > > QoS negotiation is in the current requirements draft. > > > > > > > > > > > > So, NSIS signaling protocol development should be concerned > > > > > > with activity > > > > > > before handoff occurs. > > > > > > > > > > > > Sharif. > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > 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 > > > > > > > > > > > > > > _______________________________________________ > > > > Seamoby mailing list > > > > Seamoby@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > _______________________________________________ > > > > Seamoby mailing list > > > > Seamoby@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > ------_=_NextPart_001_01C1DF39.2E13BD20 Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff.

Rajeev:

  A user starts up an application that requests a "gold service".
The protocol stack (perhaps an NSIS protocol stack) sends in a
request from MN to AN for gold service". A handover occurs, and
(according to your scenario), the QoS context transfer fails (for some
inexplicable reason). Some entity (the CT protocol stack according to
your proposal) sends an indication to the MN that the QoS context transfer
has failed (according to your proposal). How does the MN know what to do
with this notice? The MN has to understand:
   
   - what a handover is at the IP level
   - what an IP context transfer is
   - that QoS context is (sometimes) transferred separately from other
     context
   - what the nature of the failure was, and thus, what action to take.
   - how and with what entity to initiate QoS re-negotiation.

  The knowledge for all of the above is either explicitly or implicitly
built into the MN. If the intent were for the MN to receive back a message
that indicating "Gold service not available" then this is simply a session
disconnect. If the intent is for the MN to be told that "the QoS associated
with Gold service" has failed, then the MN has to know that Gold service
is actually a combination of features (AAA, security, HC), and to initiate
negotiation, it has to be able to talk to the individual network entities
- entities which may not even exist within a given network (e.g. a provision
model).

 So, how is the MN ignorant of CT? Service models?

 Keep in mind, according to the CT requirements, CT does not know what
is contained in the data chunks it transports. Thus, at best, it can
only forward to the MN that data chunk or another, opaque data chunk.
Even this capability is a major modification to what should be
a simple state machine for the CT protocol.

Gary


> -----Original Message-----
> From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com]
> Sent: April 8, 2002 14:42
> To: Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: Nakhjiri Madjid-MNAKHJI1; Hemant.Chaskar@nokia.com; nsis@ietf.org;
> seamoby@ietf.org
> Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff.
>
>
> Gary Kenward wrote:
>
> >
> >
> > Rajeev:
> >
> > In order for the MN to "recreate the context", the MN would
> > have to understand the semantics of Context transfer, etc.,
>
> The MN does not have to know the CT semantics.
> It only needs to understand a notification message
> that provides the error condition related to its
> context.
>
> >
> > and, more important, there would have to be a protocol or
> > protocols that would allow the MN to recreate contexts at an AR.
> > I doubt that the latter is going to happen (e.g. authentication).
> >
>
> Well, the MN should use whatever protocol was
> used that established the context in the first place,
> including for authentication.
>
> >
> > IF and when a CT fails, the easiest way to "recreate" context
> > is for the sessions to be dropped. This may seem drastic,
> > but in reality, what is going to cause CT to fail and
> > how often will this happen?
> >
>
> This is a drastic idea! I think we can do better.
> For one thing, you still have connectivity which
> you could use to notify the MN so that the MN
> can resort to re-establishing contexts (or not). Besides,
> CT is a protocol, and like any other protocol has
> error cases and failure modes. There must be a
> notification message that provides protocol
> robustness.
> An example that has been brought up is where
> the transferred context is not useful, either
> partially or entirely. You would like to notify
> the MN when this happens.
>
>
> >
> > There may be mitigating actions that could be taken to re-establish
> > certain sessions. But these decisions are must be driven by
> the policy
> >
> > of the network administration (explicit or implicity), and comply
> > with the security, resource management and accounting requirements
> > for the network. Hopefully, none of these mitigating
> actions requires
> > more over-the-air signalling.
> >
>
> And, why are these any better when CT fails compared
> to notifying a MN ? Seems to me that a notification message
> would not encumber any of the above overheads. You
> leave it up to the MN.
>
> -Rajeev
>
>
> >
> > Gary
> >
> > > -----Original Message-----
> > > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com]
> > > Sent: April 5, 2002 17:46
> > > To: Nakhjiri Madjid-MNAKHJI1
> > > Cc: Kenward, Gary [WDLN2:AN10:EXCH]; Hemant.Chaskar@nokia.com;
> > > nsis@ietf.org; seamoby@ietf.org
> > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff.
> > >
> > >
> > >
> > > Hello Madjid,
> > >
> > > Nakhjiri Madjid-MNAKHJI1 wrote:
> > >
> > > > Hello Rajeev,
> > > >
> > > > I agreed with everything you say below, except one thing:
> > > > CT can only transfer whatever QoS state that is usable at the
> > newAR.
> > > > If the new network is using a different QoS technology with
> > > different
> > > > QoS parameters, then I am not sure if CT by itself can do
> > > the job, unless
> > > > you add your own mapping functionality.
> > > >
> > >
> > > This would be an example where the new AR sends a
> > > notification to the MN so that the MN can take
> > > appropriate action (for instance, attempt to
> > > re-create the context).
> > >
> > > Regards,
> > >
> > > -Rajeev
> > >
> > >
> > > >
> > > > BR,
> > > > Madjid
> > > >
> > > > -----Original Message-----
> > > > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com]
> > > > Sent: Friday, April 05, 2002 11:01 AM
> > > > To: Gary Kenward
> > > > Cc: Hemant.Chaskar@nokia.com; nsis@ietf.org; seamoby@ietf.org
> > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS
> after handoff.
> > > >
> > > > Hello,
> > > >
> > > > well, if the issue is QoS establishment after handover,
> > > >
> > > > - CT is applicable for establishing QoS state at the AR
> > > > - if further signaling is desired beyond the AR, NSIS may
> > > >     consider it. I don't see how _signaling_ for QoS
> establishment
> >
> > > >     beyond AR is relevant for seamoby.
> > > >
> > > > CAR _discovery_ could exchange QoS capability as one of the
> > > > parameters that might then be fed to a selection algorithm. Any
> > > > signaling for actually establishing QoS itself beyond the AR
> > > > should be outside the scope of seamoby..
> > > >
> > > > Regards,
> > > >
> > > > -Rajeev
> > > >
> > > > Gary Kenward wrote:
> > > >
> > > > >
> > > > >
> > > > > Hemant:
> > > > >
> > > > >   Just a point of clarification, but as I understand CARD (and
> > > > > I don't understand it well), it is not a QoS negotiation
> > > > > protocol. The main application that you are referring to
> > primarily
> > > > > arises out of a perceived need to determine at the MN the
> > > best link
> > > > > layer to handover over to when inter-technology handovers are
> > > > > involved.
> > > > > It can be applied to intra-technology handovers, but the value
> > in
> > > > > that situation is highly questionable (e.g. since it is a
> > > discovery
> > > > > protocol, the implication is that the purpose is to determine
> > the
> > > > > choice of channels available; for intra-technology
> > > handovers, there
> > > > > are many, many reasons why this "choice" may not be
> available).
> > > > >
> > > > >   There is a requirement, 5.1.2, which seems to imply
> > > NSIS involvement
> > > > >
> > > > > during/after a handover. John has stated that this is not the
> > > > > intention
> > > > > (please correct me if I have this wrong John), in which
> > > case I think
> > > > > 5.1.2 needs to be clarified.
> > > > >
> > > > >   Specifically, is NSIS to be used to negotiated new
> QoS for an
> > > > > existing flow after a handover, or is it specifically for
> > > establishing
> > > > >
> > > > > QoS for a new flow? I don't think the answer is boolean: the
> > role
> > > > > of NSIS in QoS re-negotiation is still open, I believe,
> > > and clearly
> > > > > handover is a dynamic situation that could cause the QoS
> > > provided to
> > > > > change.
> > > > >
> > > > >   I have been told there is no issue, but here's a frightening
> > > > > scenario:
> > > > >
> > > > >         - a handover takes place, and context transfer
> > > has been used
> > > > > to
> > > > >        move the QoS context to the new routers (by the
> > > requirements
> > > > > for
> > > > >        CT this could be intra-, or inter- technology.
> Some of us
> >
> > > > > believe
> > > > >        that for "seamless" handovers, the context will be
> > > available at
> > > > >
> > > > >        routers before the first packets need to be forwarded.
> > This
> > > > > implies
> > > > >        that there is a relationship, probabilistic
> > > perhaps, between
> > > > >        the handover process and the target ARs for CT.
> > > > >
> > > > >      - CARD is used by the MN to influence the handover
> > > decision (it
> > > > >        is not clear to me how this happens, but it seems
> > > clear that
> > > > >        for a more "seamless" handover, the MN should
> > > chose an AR that
> > > > >        has received the appropriate context; if not,
> then what?
> > > > >
> > > > >      - NSIS kicks in and starts re-negotiating QoS
> > > because of changes
> > > > >        introduced by the handover;
> > > > >
> > > > >   How do these three protocols interact to produce predictable
> > > > > outcomes?
> > > > > Or, perhaps, the question is, how do the functional entities
> > > > > associated
> > > > > with the three protocols interact before, during and
> > > after a handover?
> > > > >
> > > > > If it the interaction is within the functional entities, the
> > > > > respective
> > > > > wg's could declare the issue out of scope, but this
> > > approach does not
> > > > > sit well with me, for it seems to defer the problem to
> > > the people who
> > > > > have to implement this "stuff".
> > > > >
> > > > >   Am I imagining things?
> > > > >
> > > > > Cheers,
> > > > > Gary
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Hemant.Chaskar@nokia.com
> > [mailto:Hemant.Chaskar@nokia.com]
> > > > > > Sent: April 4, 2002 22:33
> > > > > > To: nsis@ietf.org
> > > > > > Subject: RE: [NSIS] Establishing QoS after handoff.
> > > > > >
> > > > > >
> > > > > > Hi Sharif:
> > > > > >
> > > > > > There is currently a debate going on in Seamoby as
> to whether
> > > > > > this QoS negotiation be covered by NSIS or Seamoby (CAR
> > > > > > discovery protocol).
> > > > > >
> > > > > > IMHO it should be covered by CAR discovery and not NSIS. CAR
> > > > > > discovery is supposed to identify candidate access routers
> > > > > > for handoff and QoS is an important property for candidacy.
> > > > > >
> > > > > > Br,
> > > > > > Hemant
> > > > > >
> > > > > > -----Original Message-----
> > > > > > From: ext Shahrier, Sharif M.
> > > > > > [mailto:Sharif.Shahrier@InterDigital.com]
> > > > > > Sent: Thursday, April 04, 2002 3:35 PM
> > > > > > To: Shahrier, Sharif M.
> > > > > > Cc: 'nsis@ietf.org'
> > > > > > Subject: [NSIS] Establishing QoS after handoff.
> > > > > >
> > > > > >
> > > > > >
> > > > > > I have a question for clarification.
> > > > > >
> > > > > > I think it was stated that NSIS should only be
> > > concerned with the
> > > > > > establishment of QoS after handoff.
> > > > > >
> > > > > > This is inconvienent with respect to IP-level QoS
> > > > > > negotiation, which ideally
> > > > > > should be done before handoff has taken place.
> > > > > >
> > > > > > QoS negotiation is in the current requirements draft.
> > > > > >
> > > > > > So, NSIS signaling protocol development should be concerned
> > > > > > with activity
> > > > > > before handoff occurs.
> > > > > >
> > > > > > Sharif.
> > > > > >
> > > > > >
> > > > > >
> > > > > > _______________________________________________
> > > > > > 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
> > > > > >
> > > >
> > > > _______________________________________________
> > > > Seamoby mailing list
> > > > Seamoby@ietf.org
> > > > https://www1.ietf.org/mailman/listinfo/seamoby
> > > >
> > > > _______________________________________________
> > > > Seamoby mailing list
> > > > Seamoby@ietf.org
> > > > https://www1.ietf.org/mailman/listinfo/seamoby
> > >
> > >
>
>
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis
>

------_=_NextPart_001_01C1DF39.2E13BD20-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Mon Apr 8 16:38:09 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05658 for ; Mon, 8 Apr 2002 16:38:08 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA09385 for nsis-archive@odin.ietf.org; Mon, 8 Apr 2002 16:38:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA07990; Mon, 8 Apr 2002 16:26:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA07908 for ; Mon, 8 Apr 2002 16:26:01 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05274; Mon, 8 Apr 2002 16:25:57 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g38KLQi10282; Mon, 8 Apr 2002 16:21:26 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 8 Apr 2002 16:21:26 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA49F0@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'James Kempf'" , "'Rajeev Koodli'" , Nakhjiri Madjid-MNAKHJI1 Cc: Hemant.Chaskar@nokia.com, nsis@ietf.org, seamoby@ietf.org Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Mon, 8 Apr 2002 16:21:26 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DF3A.F5479672" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1DF3A.F5479672 Content-Type: text/plain; charset="iso-8859-1" James: > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: April 8, 2002 15:55 > To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Rajeev Koodli'; Nakhjiri > Madjid-MNAKHJI1 > Cc: Hemant.Chaskar@nokia.com; nsis@ietf.org; seamoby@ietf.org > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > As I outlined in one of my other posts, why would you > perform CT to an > > AR that did not have the necessary capabilities. Is this actually > about > > CAR failure?? > > > > Yes and no. > > Suppose the MN is expecting CT to be performed and it is not > because the A nit, but the MN does not expect CT. The MN expects continuous service (i.e. seamless service), and knows nothing about how it is supported (it could be provisioned). > new AR can't interpret the context. > The old AR may discover this via CAR, but if there is no way to > communicate it to the MN, then the MN can't know to perform the > signaling from scratch on the new AR. One could either inform the MN > beforehand to do the signaling, as is done with FMIPv6/BETH, or signal > the MN on the new AR. > > For dynamic failures, such as when the AR runs out of Gold Class > service, the signaling could only be done afterwards. I understand these scenarios, but I do not understand what they have to do with CT. CT has never intended to be an MN signalling protocol. Let me try a counter example: the service authorization fails. Would a CT message saying the AA context transfer failed be of much use to the MN? No, because the problem wasn't with the context, it was with a disconnect between the service request and authorization profile for that MN. There is a need for a "handover failure" indication message to the MN (indicating full or partial handover failure), but this message should be part of a different protocol from CT. Gary > > jak > ------_=_NextPart_001_01C1DF3A.F5479672 Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff.

James:

> -----Original Message-----
> From: James Kempf [mailto:kempf@docomolabs-usa.com]
> Sent: April 8, 2002 15:55
> To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Rajeev Koodli'; Nakhjiri
> Madjid-MNAKHJI1
> Cc: Hemant.Chaskar@nokia.com; nsis@ietf.org; seamoby@ietf.org
> Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff.
>
>
>
> > As I outlined in one of my other posts, why would you
> perform CT to an
> > AR that did not have the necessary capabilities. Is this actually
> about
> > CAR failure??
> >
>
> Yes and no.
>
> Suppose the MN is expecting CT to be performed and it is not
> because the

A nit, but the MN does not expect CT. The MN expects continuous
service (i.e. seamless service), and knows nothing about how it is
supported (it could be provisioned).

> new AR can't interpret the context.
> The old AR may discover this via CAR, but if there is no way to
> communicate it to the MN, then the MN can't know to perform the
> signaling from scratch on the new AR.  One could either inform the MN
> beforehand to do the signaling, as is done with FMIPv6/BETH, or signal
> the MN on the new AR.
>
> For dynamic failures, such as when the AR runs out of Gold Class
> service, the signaling could only be done afterwards.

I understand these scenarios, but I do not understand what they have
to do with CT. CT has never intended to be an MN signalling protocol.
Let me try a counter example: the service authorization fails. Would
a CT message saying the AA context transfer failed be of much use
to the MN? No, because the problem wasn't with the context, it was with
a disconnect between the service request and authorization profile for
that MN.

There is a need for a "handover failure" indication message to the
MN (indicating full or partial handover failure), but this message should
be part of a different protocol from CT.

Gary

>
>             jak
>

------_=_NextPart_001_01C1DF3A.F5479672-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Mon Apr 8 16:39:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05698 for ; Mon, 8 Apr 2002 16:39:37 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA09471 for nsis-archive@odin.ietf.org; Mon, 8 Apr 2002 16:39:40 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA03821; Mon, 8 Apr 2002 15:44:05 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA03785 for ; Mon, 8 Apr 2002 15:44:01 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04148 for ; Mon, 8 Apr 2002 15:43:57 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g38JdOt15352; Mon, 8 Apr 2002 15:39:24 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 8 Apr 2002 15:39:24 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA49EB@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Cedric Westphal'" , john.loughney@nokia.com Cc: Hemant.Chaskar@nokia.com, nsis@ietf.org Subject: RE: [NSIS] Establishing QoS after handoff. Date: Mon, 8 Apr 2002 15:39:23 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DF35.160A8B18" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1DF35.160A8B18 Content-Type: text/plain; charset="iso-8859-1" I concur with Cedric's observations. I think that there is still confusion as to where CAR leaves off and NSIS begins. If CAR does QoS negotiation, then will it not require much of the same signalling semantics and syntax as the NSIS solution requires to establish QoS? Is this redundancy necessary? Also, while I keep thinking I that understand where CT ends and CAR/NSIS begin, this think is constantly challenged by proposals such as the one made recently to have CT signal service feature incompatibilities/transfer failures. How many signalling protocols does one need to create and maintain QoS??? Wouldn't it be preferably to have "a" context transfer protocol and "a" QoS signalling protocol and "a" discovery protocol? We are not (as far as I know) talking about alternative solutions here, but rather three protocols that may often be used together, hopefully with consistent results. Gary -----Original Message----- From: Cedric Westphal [mailto:cedric@iprg.nokia.com] Sent: April 5, 2002 21:43 To: john.loughney@nokia.com Cc: Hemant.Chaskar@nokia.com; nsis@ietf.org Subject: Re: [NSIS] Establishing QoS after handoff. John, just one question: john.loughney@nokia.com wrote: Hi all, Just to follow on to Hemant's comment: There is currently a debate going on in Seamoby as to whether this QoS negotiation be covered by NSIS or Seamoby (CAR discovery protocol). IMHO it should be covered by CAR discovery and not NSIS. CAR discovery is supposed to identify candidate access routers for handoff and QoS is an important property for candidacy. CAR discovery may be used to select handoff targets with correct QoS support / capabilities. Context Transfer (CT) can be used with the handoff procedure to ensure proper QoS state gets transfered to the new access router. how does the CAR know whether or not it is able to provide the QoS for the flows of the MN. If the question is QoS on the MN-CAR link, then it is easy, but what if the question is on the CAR-CN side? It seems to me that in Seamoby, both CARD and CT could act as triggers to NSIS (QI I guess). CARD to assess whether the CAR-CN is available, using NSIS as a probing mechanism, and CT to make the NAR-CN QoS re-establishment. If there is anyone interested in this work, please let me know. The SeaMoby chairs asked me to see if NSIS can provide them any information about QoS needs. Then both CARD and CT would need NSIS input/interaction... Cheers, Cedric. thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis ------_=_NextPart_001_01C1DF35.160A8B18 Content-Type: text/html; charset="iso-8859-1"
I concur with Cedric's observations.
 
I think that there is still confusion as to where CAR leaves off and NSIS begins.
If CAR does QoS negotiation, then will it not require much of the same signalling
semantics and syntax as the NSIS solution requires to establish QoS? Is this
redundancy necessary?
 
Also, while I keep thinking I that understand where CT ends and CAR/NSIS begin,
this think is constantly challenged by proposals such as the one made recently
to have CT signal service feature incompatibilities/transfer failures.
 
How many signalling protocols does one need to create and maintain QoS???
Wouldn't it be preferably to have "a" context transfer protocol and "a"
QoS signalling protocol and "a" discovery protocol?
 
We are not (as far as I know) talking about alternative solutions here, but rather
three protocols that may often be used together, hopefully with consistent results.
 
Gary
 
 
-----Original Message-----
From: Cedric Westphal [mailto:cedric@iprg.nokia.com]
Sent: April 5, 2002 21:43
To: john.loughney@nokia.com
Cc: Hemant.Chaskar@nokia.com; nsis@ietf.org
Subject: Re: [NSIS] Establishing QoS after handoff.

John,

just one question:

john.loughney@nokia.com wrote:
Hi all,

Just to follow on to Hemant's comment:

There is currently a debate going on in Seamoby as to whether 
this QoS negotiation be covered by NSIS or Seamoby (CAR 
discovery protocol). 

IMHO it should be covered by CAR discovery and not NSIS. CAR 
discovery is supposed to identify candidate access routers 
for handoff and QoS is an important property for candidacy. 

CAR discovery may be used to select handoff targets with
correct QoS support / capabilities.  Context Transfer (CT)
can be used with the handoff procedure to ensure proper
QoS state gets transfered to the new access router.

how does the CAR know whether or not it is able to provide the QoS
for the flows of the MN. If the question is QoS on the MN-CAR link,
then it is easy, but what if the question is on the CAR-CN side?

It seems to me that in Seamoby, both CARD and CT could act as triggers
to NSIS (QI I guess). CARD to assess whether the CAR-CN is available,
using NSIS as a probing mechanism, and CT to make the NAR-CN QoS
re-establishment.


If there is anyone interested in this work, please let me
know.  The SeaMoby chairs asked me to see if NSIS can provide
them any information about QoS needs.
Then both CARD and CT would need NSIS input/interaction...
Cheers,

Cedric.


thanks,
John

_______________________________________________
nsis mailing list
nsis@ietf.org
https://www1.ietf.org/mailman/listinfo/nsis

------_=_NextPart_001_01C1DF35.160A8B18-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Mon Apr 8 16:45:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05819 for ; Mon, 8 Apr 2002 16:45:40 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA10009 for nsis-archive@odin.ietf.org; Mon, 8 Apr 2002 16:45:44 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA04403; Mon, 8 Apr 2002 15:51:19 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA04250 for ; Mon, 8 Apr 2002 15:51:11 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04269; Mon, 8 Apr 2002 15:51:06 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g38JkYt15797; Mon, 8 Apr 2002 15:46:34 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 8 Apr 2002 15:46:34 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA49EC@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Nakhjiri Madjid-MNAKHJI1'" , "'Rajeev Koodli'" , James Kempf Cc: Hemant.Chaskar@nokia.com, nsis@ietf.org, seamoby@ietf.org Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Mon, 8 Apr 2002 15:46:32 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DF36.15A485BA" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1DF36.15A485BA Content-Type: text/plain; charset="iso-8859-1" Can anyone offer an explaining of how or why CT would add significantly to the already unreliable physics of handover? What failure modes for CT would be noticeable above the unavoidable rate of handover failures due the vagaries of wireless coverage and wireless link layer performance???? If CT fails, then the handover fails. It is that simple. If CT were to fail with every 2nd handover attempt, then there would be a problem. But, I cannot seriously see CT failing more then every one in a million handover attempts, or less. CT should not be attempted if there is an incompatibility between source and destination ARs. And, I HAD thought that it was the purpose of CAR to identify those incompatibilities and thus avoid doing CT when it is clear it would fail. How to mitigate those incompatibles is not a CT issue, it is a service adaptation issue, which can be resolved in a number of ways, some of which would imply signalled negotiation either between the ARs or between the ARs and the MN. Gary > -----Original Message----- > From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] > Sent: April 5, 2002 16:58 > To: 'Rajeev Koodli'; James Kempf > Cc: Kenward, Gary [WDLN2:AN10:EXCH]; Hemant.Chaskar@nokia.com; > nsis@ietf.org; seamoby@ietf.org > Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > Agreed. I don't think reliability in signaling, which by the way > neither CT requirements, nor nsis requirements are covering, has to > do with failure in QoS negotiation. I don't think you can count > the case, where the QoS information that CT has given the AR is not > applicable, as a CT failure. > > Madjid > > -----Original Message----- > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] > Sent: Friday, April 05, 2002 12:03 PM > To: James Kempf > Cc: Gary Kenward; Hemant.Chaskar@nokia.com; nsis@ietf.org; > seamoby@ietf.org > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > James Kempf wrote: > > > Rajeev, > > > > I agree, but there is still an issue of how the AR would > notify the MN > > if CT fails. Is this covered by CT or not? > > > > This notification should be covered by CT. We should offer > seamless handover to NSIS :-) Seriously, this concerns > robustness of CT protocol. > > -Rajeev > > > > > > jak > > > > ----- Original Message ----- > > From: "Rajeev Koodli" > > To: "James Kempf" > > Cc: "Gary Kenward" ; > > ; ; > > Sent: Friday, April 05, 2002 9:19 AM > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > > > Hello Jim, > > > > > > James Kempf wrote: > > > > > > > There is an issue if CT fails. In that case, some kind of > > negotiation > > > > after handover would be required. > > > > > > > > So, I'd say that some indication of CT failure is needed. > > > > > > > > > > Yes, but this is between AR and MN. If CT fails, the AR should > > > notify the MN to engage in context re-creation. > > > > > > My point was specific to signaling _beyond_ AR (i.e., upstream > > signaling) > > > independent of failure/success of CT. > > > > > > Hope this is clearer.. > > > > > > -Rajeev > > > > > > > > > > > > > > As for CAR, I don't see the relevance for QoS > negotiation, though it > > may > > > > be useful for finding a new wireless medium. I also see > it primarily > > for > > > > intertechnology handover, or, at best, interprovider handover. > > > > > > > > jak > > > > ----- Original Message ----- > > > > From: "Rajeev Koodli" > > > > To: "Gary Kenward" > > > > Cc: ; ; > > > > > Sent: Friday, April 05, 2002 9:01 AM > > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS > after handoff. > > > > > > > > > > > > > > Hello, > > > > > > > > > > well, if the issue is QoS establishment after handover, > > > > > > > > > > - CT is applicable for establishing QoS state at the AR > > > > > - if further signaling is desired beyond the AR, NSIS may > > > > > consider it. I don't see how _signaling_ for QoS > establishment > > > > > beyond AR is relevant for seamoby. > > > > > > > > > > CAR _discovery_ could exchange QoS capability as one of the > > > > > parameters that might then be fed to a selection > algorithm. Any > > > > > signaling for actually establishing QoS itself beyond the AR > > > > > should be outside the scope of seamoby.. > > > > > > > > > > Regards, > > > > > > > > > > -Rajeev > > > > > > > > > > > > > > > Gary Kenward wrote: > > > > > > > > > > > > > > > > > > > > > > > Hemant: > > > > > > > > > > > > Just a point of clarification, but as I > understand CARD (and > > > > > > I don't understand it well), it is not a QoS negotiation > > > > > > protocol. The main application that you are referring to > > primarily > > > > > > arises out of a perceived need to determine at the > MN the best > > link > > > > > > layer to handover over to when inter-technology > handovers are > > > > > > involved. > > > > > > It can be applied to intra-technology handovers, > but the value > > in > > > > > > that situation is highly questionable (e.g. since it is a > > discovery > > > > > > protocol, the implication is that the purpose is to > determine > > the > > > > > > choice of channels available; for intra-technology > handovers, > > there > > > > > > are many, many reasons why this "choice" may not be > available). > > > > > > > > > > > > There is a requirement, 5.1.2, which seems to imply NSIS > > > > involvement > > > > > > > > > > > > during/after a handover. John has stated that this > is not the > > > > > > intention > > > > > > (please correct me if I have this wrong John), in > which case I > > think > > > > > > 5.1.2 needs to be clarified. > > > > > > > > > > > > Specifically, is NSIS to be used to negotiated > new QoS for an > > > > > > existing flow after a handover, or is it specifically for > > > > establishing > > > > > > > > > > > > QoS for a new flow? I don't think the answer is boolean: the > > role > > > > > > of NSIS in QoS re-negotiation is still open, I believe, and > > clearly > > > > > > handover is a dynamic situation that could cause the QoS > > provided to > > > > > > change. > > > > > > > > > > > > I have been told there is no issue, but here's a > frightening > > > > > > scenario: > > > > > > > > > > > > - a handover takes place, and context > transfer has been > > used > > > > > > to > > > > > > move the QoS context to the new routers (by the > > requirements > > > > > > for > > > > > > CT this could be intra-, or inter- > technology. Some of us > > > > > > believe > > > > > > that for "seamless" handovers, the context will be > > available > > > > at > > > > > > > > > > > > routers before the first packets need to be > forwarded. > > This > > > > > > implies > > > > > > that there is a relationship, probabilistic perhaps, > > between > > > > > > the handover process and the target ARs for CT. > > > > > > > > > > > > - CARD is used by the MN to influence the > handover decision > > (it > > > > > > is not clear to me how this happens, but it > seems clear > > that > > > > > > for a more "seamless" handover, the MN > should chose an AR > > > > that > > > > > > has received the appropriate context; if > not, then what? > > > > > > > > > > > > - NSIS kicks in and starts re-negotiating QoS > because of > > > > changes > > > > > > introduced by the handover; > > > > > > > > > > > > How do these three protocols interact to produce > predictable > > > > > > outcomes? > > > > > > Or, perhaps, the question is, how do the functional entities > > > > > > associated > > > > > > with the three protocols interact before, during and after a > > > > handover? > > > > > > > > > > > > If it the interaction is within the functional entities, the > > > > > > respective > > > > > > wg's could declare the issue out of scope, but this approach > > does > > > > not > > > > > > sit well with me, for it seems to defer the problem to the > > people > > > > who > > > > > > have to implement this "stuff". > > > > > > > > > > > > Am I imagining things? > > > > > > > > > > > > Cheers, > > > > > > Gary > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Hemant.Chaskar@nokia.com > > [mailto:Hemant.Chaskar@nokia.com] > > > > > > > Sent: April 4, 2002 22:33 > > > > > > > To: nsis@ietf.org > > > > > > > Subject: RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > > > > > > > > > Hi Sharif: > > > > > > > > > > > > > > There is currently a debate going on in Seamoby > as to whether > > > > > > > this QoS negotiation be covered by NSIS or Seamoby (CAR > > > > > > > discovery protocol). > > > > > > > > > > > > > > IMHO it should be covered by CAR discovery and > not NSIS. CAR > > > > > > > discovery is supposed to identify candidate access routers > > > > > > > for handoff and QoS is an important property for > candidacy. > > > > > > > > > > > > > > Br, > > > > > > > Hemant > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: ext Shahrier, Sharif M. > > > > > > > [mailto:Sharif.Shahrier@InterDigital.com] > > > > > > > Sent: Thursday, April 04, 2002 3:35 PM > > > > > > > To: Shahrier, Sharif M. > > > > > > > Cc: 'nsis@ietf.org' > > > > > > > Subject: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > > > > > > > > > > > > > > > > I have a question for clarification. > > > > > > > > > > > > > > I think it was stated that NSIS should only be > concerned with > > the > > > > > > > establishment of QoS after handoff. > > > > > > > > > > > > > > This is inconvienent with respect to IP-level QoS > > > > > > > negotiation, which ideally > > > > > > > should be done before handoff has taken place. > > > > > > > > > > > > > > QoS negotiation is in the current requirements draft. > > > > > > > > > > > > > > So, NSIS signaling protocol development should be > concerned > > > > > > > with activity > > > > > > > before handoff occurs. > > > > > > > > > > > > > > Sharif. > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Seamoby mailing list > > > > > Seamoby@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > > > > > > _______________________________________________ > > > Seamoby mailing list > > > Seamoby@ietf.org > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > ------_=_NextPart_001_01C1DF36.15A485BA Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff.

Can anyone offer an explaining of how or why CT would = add significantly
to the already unreliable physics of = handover?

What failure modes for CT would be noticeable above = the unavoidable
rate of handover failures due the vagaries of = wireless coverage and
wireless link layer performance????

If CT fails, then the handover fails. It is that = simple. If CT were
to fail with every 2nd handover attempt, then there = would be a problem.
But, I cannot seriously see CT failing more then = every one in a million
handover attempts, or less.

CT should not be attempted if there is an = incompatibility between source
and destination ARs. And, I HAD thought that it was = the purpose of CAR
to identify those incompatibilities and thus avoid = doing CT when it is
clear it would fail. How to mitigate those = incompatibles is not a
CT issue, it is a service adaptation issue, which = can be resolved in
a number of ways, some of which would imply = signalled negotiation either
between the ARs or between the ARs and the MN. =

Gary

> -----Original Message-----
> From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@moto= rola.com]
> Sent: April 5, 2002 16:58
> To: 'Rajeev Koodli'; James Kempf
> Cc: Kenward, Gary [WDLN2:AN10:EXCH]; = Hemant.Chaskar@nokia.com;
> nsis@ietf.org; seamoby@ietf.org
> Subject: RE: [Seamoby] RE: [NSIS] Establishing = QoS after handoff.
>
>
> Agreed. I don't think reliability in signaling, = which by the way
> neither CT requirements, nor nsis requirements = are covering, has to
> do with failure in QoS negotiation. I don't = think you can count
> the case, where the QoS information that CT has = given the AR is not
> applicable, as a CT failure.
>
> Madjid
>
> -----Original Message-----
> From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com]<= /FONT>
> Sent: Friday, April 05, 2002 12:03 PM
> To: James Kempf
> Cc: Gary Kenward; Hemant.Chaskar@nokia.com; = nsis@ietf.org;
> seamoby@ietf.org
> Subject: Re: [Seamoby] RE: [NSIS] Establishing = QoS after handoff.
>
>
> James Kempf wrote:
>
> > Rajeev,
> >
> > I agree, but there is still an issue of = how the AR would
> notify the MN
> > if CT fails. Is this covered by CT or = not?
> >
>
> This notification should be covered by = CT.  We should offer
> seamless handover to NSIS :-) Seriously, this = concerns
> robustness of CT protocol.
>
> -Rajeev
>
>
> >
> = >           &n= bsp; jak
> >
> > ----- Original Message -----
> > From: "Rajeev Koodli" = <rajeev@iprg.nokia.com>
> > To: "James Kempf" = <kempf@docomolabs-usa.com>
> > Cc: "Gary Kenward" = <gkenward@nortelnetworks.com>;
> > <Hemant.Chaskar@nokia.com>; = <nsis@ietf.org>; <seamoby@ietf.org>
> > Sent: Friday, April 05, 2002 9:19 = AM
> > Subject: Re: [Seamoby] RE: [NSIS] = Establishing QoS after handoff.
> >
> > >
> > > Hello Jim,
> > >
> > > James Kempf wrote:
> > >
> > > > There is an issue if CT fails. = In that case, some kind of
> > negotiation
> > > > after handover would be = required.
> > > >
> > > > So, I'd say that some indication = of CT failure is needed.
> > > >
> > >
> > > Yes, but this is between AR and MN. = If CT fails, the AR should
> > > notify the MN to engage in context = re-creation.
> > >
> > > My point was specific to signaling = _beyond_ AR (i.e., upstream
> > signaling)
> > > independent of failure/success of = CT.
> > >
> > > Hope this is clearer..
> > >
> > > -Rajeev
> > >
> > >
> > > >
> > > > As for CAR, I don't see the = relevance for QoS
> negotiation, though it
> > may
> > > > be useful for finding a new = wireless medium. I also see
> it primarily
> > for
> > > > intertechnology handover, or, at = best, interprovider handover.
> > > >
> > > = >           &n= bsp; jak
> > > > ----- Original Message = -----
> > > > From: "Rajeev Koodli" = <rajeev@iprg.nokia.com>
> > > > To: "Gary Kenward" = <gkenward@nortelnetworks.com>
> > > > Cc: = <Hemant.Chaskar@nokia.com>; <nsis@ietf.org>;
> <seamoby@ietf.org>
> > > > Sent: Friday, April 05, 2002 = 9:01 AM
> > > > Subject: Re: [Seamoby] RE: = [NSIS] Establishing QoS
> after handoff.
> > > >
> > > > >
> > > > > Hello,
> > > > >
> > > > > well, if the issue is QoS = establishment after handover,
> > > > >
> > > > > - CT is applicable for = establishing QoS state at the AR
> > > > > - if further signaling is = desired beyond the AR, NSIS may
> > > > >     = consider it. I don't see how _signaling_ for QoS
> establishment
> > > > >     = beyond AR is relevant for seamoby.
> > > > >
> > > > > CAR _discovery_ could = exchange QoS capability as one of the
> > > > > parameters that might then = be fed to a selection
> algorithm. Any
> > > > > signaling for actually = establishing QoS itself beyond the AR
> > > > > should be outside the scope = of seamoby..
> > > > >
> > > > > Regards,
> > > > >
> > > > > -Rajeev
> > > > >
> > > > >
> > > > > Gary Kenward wrote:
> > > > >
> > > > > >
> > > > > >
> > > > > > Hemant:
> > > > > >
> > > > > >   Just a = point of clarification, but as I
> understand CARD (and
> > > > > > I don't understand it = well), it is not a QoS negotiation
> > > > > > protocol. The main = application that you are referring to
> > primarily
> > > > > > arises out of a = perceived need to determine at the
> MN the best
> > link
> > > > > > layer to handover over = to when inter-technology
> handovers are
> > > > > > involved.
> > > > > > It can be applied to = intra-technology handovers,
> but the value
> > in
> > > > > > that situation is = highly questionable (e.g. since it is a
> > discovery
> > > > > > protocol, the = implication is that the purpose is to
> determine
> > the
> > > > > > choice of channels = available; for intra-technology
> handovers,
> > there
> > > > > > are many, many reasons = why this "choice" may not be
> available).
> > > > > >
> > > > > >   There is a = requirement, 5.1.2, which seems to imply NSIS
> > > > involvement
> > > > > >
> > > > > > during/after a = handover. John has stated that this
> is not the
> > > > > > intention
> > > > > > (please correct me if = I have this wrong John), in
> which case I
> > think
> > > > > > 5.1.2 needs to be = clarified.
> > > > > >
> > > > > >   = Specifically, is NSIS to be used to negotiated
> new QoS for an
> > > > > > existing flow after a = handover, or is it specifically for
> > > > establishing
> > > > > >
> > > > > > QoS for a new flow? I = don't think the answer is boolean: the
> > role
> > > > > > of NSIS in QoS = re-negotiation is still open, I believe, and
> > clearly
> > > > > > handover is a dynamic = situation that could cause the QoS
> > provided to
> > > > > > change.
> > > > > >
> > > > > >   I have = been told there is no issue, but here's a
> frightening
> > > > > > scenario:
> > > > > >
> > > > > = >         - a handover takes = place, and context
> transfer has been
> > used
> > > > > > to
> > > > > = >        move the QoS context to = the new routers (by the
> > requirements
> > > > > > for
> > > > > = >        CT this could be intra-, = or inter-
> technology. Some of us
> > > > > > believe
> > > > > = >        that for = "seamless" handovers, the context will be
> > available
> > > > at
> > > > > >
> > > > > = >        routers before the first = packets need to be
> forwarded.
> > This
> > > > > > implies
> > > > > = >        that there is a = relationship, probabilistic perhaps,
> > between
> > > > > = >        the handover process and = the target ARs for CT.
> > > > > >
> > > > > = >      - CARD is used by the MN to = influence the
> handover decision
> > (it
> > > > > = >        is not clear to me how = this happens, but it
> seems clear
> > that
> > > > > = >        for a more = "seamless" handover, the MN
> should chose an AR
> > > > that
> > > > > = >        has received the = appropriate context; if
> not, then what?
> > > > > >
> > > > > = >      - NSIS kicks in and starts = re-negotiating QoS
> because of
> > > > changes
> > > > > = >        introduced by the = handover;
> > > > > >
> > > > > >   How do = these three protocols interact to produce
> predictable
> > > > > > outcomes?
> > > > > > Or, perhaps, the = question is, how do the functional entities
> > > > > > associated
> > > > > > with the three = protocols interact before, during and after a
> > > > handover?
> > > > > >
> > > > > > If it the interaction = is within the functional entities, the
> > > > > > respective
> > > > > > wg's could declare the = issue out of scope, but this approach
> > does
> > > > not
> > > > > > sit well with me, for = it seems to defer the problem to the
> > people
> > > > who
> > > > > > have to implement this = "stuff".
> > > > > >
> > > > > >   Am I = imagining things?
> > > > > >
> > > > > > Cheers,
> > > > > > Gary
> > > > > >
> > > > > > > -----Original = Message-----
> > > > > > > From: = Hemant.Chaskar@nokia.com
> > [mailto:Hemant.Chaskar@nokia.com= ]
> > > > > > > Sent: April 4, = 2002 22:33
> > > > > > > To: = nsis@ietf.org
> > > > > > > Subject: RE: = [NSIS] Establishing QoS after handoff.
> > > > > > >
> > > > > > >
> > > > > > > Hi Sharif:
> > > > > > >
> > > > > > > There is = currently a debate going on in Seamoby
> as to whether
> > > > > > > this QoS = negotiation be covered by NSIS or Seamoby (CAR
> > > > > > > discovery = protocol).
> > > > > > >
> > > > > > > IMHO it should be = covered by CAR discovery and
> not NSIS. CAR
> > > > > > > discovery is = supposed to identify candidate access routers
> > > > > > > for handoff and = QoS is an important property for
> candidacy.
> > > > > > >
> > > > > > > Br,
> > > > > > > Hemant
> > > > > > >
> > > > > > > -----Original = Message-----
> > > > > > > From: ext = Shahrier, Sharif M.
> > > > > > > [mailto:Sharif.Shahrier@= InterDigital.com]
> > > > > > > Sent: Thursday, = April 04, 2002 3:35 PM
> > > > > > > To: Shahrier, = Sharif M.
> > > > > > > Cc: = 'nsis@ietf.org'
> > > > > > > Subject: [NSIS] = Establishing QoS after handoff.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > I have a question = for clarification.
> > > > > > >
> > > > > > > I think it was = stated that NSIS should only be
> concerned with
> > the
> > > > > > > establishment of = QoS after handoff.
> > > > > > >
> > > > > > > This is = inconvienent with respect to IP-level QoS
> > > > > > > negotiation, = which ideally
> > > > > > > should be done = before handoff has taken place.
> > > > > > >
> > > > > > > QoS negotiation = is in the current requirements draft.
> > > > > > >
> > > > > > > So, NSIS = signaling protocol development should be
> concerned
> > > > > > > with = activity
> > > > > > > before handoff = occurs.
> > > > > > >
> > > > > > > Sharif.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > = _______________________________________________
> > > > > > > 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=
> > > > > > >
> > > > >
> > > > >
> > > > > = _______________________________________________
> > > > > Seamoby mailing list
> > > > > Seamoby@ietf.org
> > > > > https://www1.ietf.org/mailman/listinfo/seamoby
> > > > >
> > >
> > >
> > > = _______________________________________________
> > > Seamoby mailing list
> > > Seamoby@ietf.org
> > > https://www1.ietf.org/mailman/listinfo/seamoby
> > >
>
>
> = _______________________________________________
> Seamoby mailing list
> Seamoby@ietf.org
> https://www1.ietf.org/mailman/listinfo/seamoby
>

------_=_NextPart_001_01C1DF36.15A485BA-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Mon Apr 8 16:49:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05979 for ; Mon, 8 Apr 2002 16:49:27 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA10230 for nsis-archive@odin.ietf.org; Mon, 8 Apr 2002 16:49:30 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA08833; Mon, 8 Apr 2002 16:32:18 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA08803 for ; Mon, 8 Apr 2002 16:32:15 -0400 (EDT) Received: from iraun2.uka.de (iraun2.uka.de [129.13.10.91]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05430 for ; Mon, 8 Apr 2002 16:32:11 -0400 (EDT) Received: from irams1.ira.uka.de ([129.13.10.5]) by iraun2.uka.de with esmtp (Exim 3.30 #7 (Debian)) id 16ufoD-0002EM-00; Mon, 08 Apr 2002 22:32:13 +0200 Received: from i72pc127.tm.uni-karlsruhe.de ([141.3.70.78] helo=i72pc127.tm.uka.de) by irams1.ira.uka.de with esmtp (Exim 3.30 #7 (Debian)) id 16ufoC-000229-00; Mon, 08 Apr 2002 22:32:12 +0200 Received: from tpce10.ipv6.tm.uka.de (localhost [127.0.0.1]) by i72pc127.tm.uka.de (8.11.6/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id g38KWCf19869; Mon, 8 Apr 2002 22:32:12 +0200 Message-Id: <200204082032.g38KWCf19869@i72pc127.tm.uka.de> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4+dev To: Anders.P.Bergsten@telia.se cc: nsis@ietf.org Subject: Re: [NSIS] Looking back at RFC 1633 In-Reply-To: Message from Anders.P.Bergsten@telia.se of "Fri, 05 Apr 2002 10:56:02 +0200." <1BF8A5964E4EFA41A094B835FCA712912CCC49@TMS041MB.tcad.telia.se> References: <1BF8A5964E4EFA41A094B835FCA712912CCC49@TMS041MB.tcad.telia.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 08 Apr 2002 22:32:12 +0200 From: Roland Bless Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi Anders, > It's very interesting to read remarks like "there is an inescabable > requirement for routers to be able to reserve resources... This in > turn requires flow-specific state in the routers" and "We take the > view that there should be a single service model for the Internet". > One can ask oneself, has anyone of these statements truly changed? IMO after considering all the DiffServ work: Yes. Refering to the first point: In fact, DiffServ routers are not required to reserve resources. Bookkeeping of resources can also be done by other dedicated entities such as Domain Managers/BBs, thus removing resource management and signaling burden from routers. However, routers have to be configured, but only "first-hop routers" (or sometimes also "last-hop routers") per micro-flow. Boundary routers usually have only profiles per aggregates and interior routers normally don't need profiles (they have a rather static configured resource partitioning for their PHBs) and thus no flow-specific states. Second point: While it may be really important to have globally well-known services in the future, it is a good idea to let those things evolve by market demands etc. For the near future, it makes perfectly sense that ISPs provide their own locally defined services to their customers at first, because of easier management. > It's even more interesting to think of in conjunction with (pure) > diffserv where neither of these are true. > To my main point though, there are 6 points I could find that ought to > be interesting to discuss in regards to NSIS. These are either listed > as further work, or in one instance I found the text to be vague. > [Please, if you choose to respond to this email, alter the header so > it is clear which one of the six points you are addressing] I'll take all six... :-) > 1) Usage Feedback. "Another important issue in the service is the > model for usage feedback, also known as accounting...", "this is a > highly contentious issue, and we are not prepared to say more about > this at this time". > Have we collectively learned more about what "accounting"-models to > support today so we can determine what the requirements truly are? This is still difficult. But NSIS should be flexible enough to let those things evolve indepently and thus it should provide hooks for an AAA architecture, so that reservation requests can be authenticated and accounted. > 2) Reservation model "The 'reservation model' describes how an > application negotiates for a QoS level.", "Further work is needed to > define the amount of generality, with a corresponding level of > complexity, that is required in the reservation model." > Once again, have we learned more on this issue, or are we still at a > point where we do not know the answer? I see people asking for very > complex models and others (such as myself) that states that a yes/no > reply is enough. As I already stated: NSIS should support negotiation of service parameter _values_, which can be easily supported by a simple request/response dialogue when the response can also contain a service object with the negotiated parameter values. Service or service parameter negotiation can be added later by specialized negotiation protocols. > 3) Flow Id (under section 4.1.3) "One approach to reducing the > overhead of classification would be to provide a 'flow-id' field in > the Internet-layer packet header... There are a number of variations > of this concept, and engineering is required to choose the best > design." > Have we learned what is the best design? Or at least a reasonable good > design so we can get it deployed? Another related question, do we need > a definition of "flows" in NSIS? I think DiffServ also provides the answers here. In the data path, we don't really need a flow-id field. However, in the control path we need the definition of a flow (at least when we want to support micro-flows with end-to-end QoS). Therefore, we specifically must pay attention to scalability in the control plane. > 4) Receiver initiation "... For simplicity and economy, a setup > protocol should support only one direction of initiation, and, > and receiver initiation appears to us to be the clear winner." > I know there were some discussions on this topic at the IETF, but I > find it good to re-iterate this again. Is receiver initiation still > the clear winner? [for those who jump up a scream an immediate no, > please pay attention to multicast... :-)] And, does the > accounting-model have any impact on the reservation initiation > direction? I found it always a good idea to separate between the initiator of a reservation request and the actual data senders and receivers. It should be possible that the initiator is either the sender or the receiver or maybe also a third party. Looking at DiffServ, the admission control has usually to start from the sender, because traffic conditioning elements have to be adapted in a suitable order. However, there are also ways to have receiver-initiated reservations for unicast and multicast. > 5) Routing and reservation "Some have suggested that reservation setup > necessarily requires route set up, i.e., the imposition of a > virtual-circuit internet layer. However, our goal is to simply extend > the Internet architecture, not replace it.". > > I see (once again) some folks at the NSIS list advocating that a route > set up or VC-like mechanisms is necessary. With our current knowledge, > is there substansial reasons to change the conclusion of Braden et al? In my view, routing has to be considered, because the resource management must have knowledge of the actual data path. But NSIS should be independent of the used routing protocols and allow to use traditional routing protocols as well as QoS routing protocols etc. However, I see a strong requirement to have really stable paths which don't change too often. > (in later chapters) "It may eventually be possible to fold together > the routing and reservation setup problems, but we do not yet > understand enough to do that." > > Do we understand this issue better today? (this is perhaps somebody > elses problem... irtf-rrg?). QoS routing isn't that easy, but may be available in the future... so we should not rely on its availability, but see it more as a future improvement of resource usage... > 6) Mobility "The last routing-related issue is provided by mobile > hosts. Our conjecture is that mobility is not essentially different > from other route changes, so that the mechanism suggested ... will > suffice. More study and experimentation is needed to prove or > disprove this conjecture." > Have somebody been able to prove or disprove this conjecture? There are differences to route changes, especially during handover, e.g., resources for a new path may be requested before the actual route change happens. > ps, one issue I deliberately left out was the most obvious: > "We conclude that there is an inescapable requirement for routers to > be able to reserve resources, in order to provide special QoS for > specific user packet streams, or "flows". This in turn requires > flow-specific state in the routers,", with Frank Kelly's and others > work - is this true today, or can we do something much simpler? Or is > reservations simply a dead end... Consider the DiffServ architecture: one needs flow-specific state in routers, but not in _every_ router along the path, usually only in first-hop routers, so this should be manageable. By using aggregation also in the control plane, we don't need flow-specific states in every element along the (data or control) path. > psps I know we have touched on some > of these issues, but I do not see them as resolved. I think that the DiffServ architecture provides answers to most of the questions. Regards, Roland -- Roland Bless -- e-Mail: bless@tm.uka.de Institute of Telematics, University of Karlsruhe, Germany Zirkel 2, D-76128 Karlsruhe -- Office: Bld. 20.20, 3rd floor, R 358 Phone: +49 721 608-6413 Fax: +49 721 388097 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Mon Apr 8 16:53:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06107 for ; Mon, 8 Apr 2002 16:53:15 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA10552 for nsis-archive@odin.ietf.org; Mon, 8 Apr 2002 16:53:19 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA09153; Mon, 8 Apr 2002 16:35:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA09068 for ; Mon, 8 Apr 2002 16:34:59 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05556; Mon, 8 Apr 2002 16:34:54 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g38KUMt21288; Mon, 8 Apr 2002 16:30:22 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 8 Apr 2002 16:30:23 -0400 Received: from zrtps0km.us.nortel.com ([47.140.192.54]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 2P90FJ39; Mon, 8 Apr 2002 16:16:45 -0400 Received: from ertpsms3.internet.nortel.com (ertpsms3.internet.nortel.com [47.234.0.33] (may be forged)) by zrtps0km.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with SMTP id g38KGJ802708; Mon, 8 Apr 2002 16:16:19 -0400 (EDT) Received: from optimus.ietf.org (ietf.org [132.151.1.19]) by ertpsms3.internet.nortel.com with SMTP (MailShield v2.04 - SOLARIS/SPARC Jul 18 2001 17:16:48); Mon, 08 Apr 2002 16:21:40 -0400 Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA07021; Mon, 8 Apr 2002 16:13:45 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA06898 for ; Mon, 8 Apr 2002 16:13:38 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04941; Mon, 8 Apr 2002 16:13:34 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g38K8ji09475; Mon, 8 Apr 2002 16:08:46 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 8 Apr 2002 16:08:45 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA49F4@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Rajeev Koodli'" Cc: Nakhjiri Madjid-MNAKHJI1 , Hemant.Chaskar@nokia.com, nsis@ietf.org, seamoby@ietf.org Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Mon, 8 Apr 2002 16:30:23 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DF3C.25220886" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1DF3C.25220886 Content-Type: text/plain; charset="iso-8859-1" Rajeev: A user starts up an application that requests a "gold service". The protocol stack (perhaps an NSIS protocol stack) sends in a request from MN to AN for gold service". A handover occurs, and (according to your scenario), the QoS context transfer fails (for some inexplicable reason). Some entity (the CT protocol stack according to your proposal) sends an indication to the MN that the QoS context transfer has failed (according to your proposal). How does the MN know what to do with this notice? The MN has to understand: - what a handover is at the IP level - what an IP context transfer is - that QoS context is (sometimes) transferred separately from other context - what the nature of the failure was, and thus, what action to take. - how and with what entity to initiate QoS re-negotiation. The knowledge for all of the above is either explicitly or implicitly built into the MN. If the intent were for the MN to receive back a message that indicating "Gold service not available" then this is simply a session disconnect. If the intent is for the MN to be told that "the QoS associated with Gold service" has failed, then the MN has to know that Gold service is actually a combination of features (AAA, security, HC), and to initiate negotiation, it has to be able to talk to the individual network entities - entities which may not even exist within a given network (e.g. a provision model). So, how is the MN ignorant of CT? Service models? Keep in mind, according to the CT requirements, CT does not know what is contained in the data chunks it transports. Thus, at best, it can only forward to the MN that data chunk or another, opaque data chunk. Even this capability is a major modification to what should be a simple state machine for the CT protocol. Gary *snip* > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > ------_=_NextPart_001_01C1DF3C.25220886 Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff.

Rajeev:

  A user starts up an application that requests a "gold service".
The protocol stack (perhaps an NSIS protocol stack) sends in a
request from MN to AN for gold service". A handover occurs, and
(according to your scenario), the QoS context transfer fails (for some
inexplicable reason). Some entity (the CT protocol stack according to
your proposal) sends an indication to the MN that the QoS context transfer
has failed (according to your proposal). How does the MN know what to do
with this notice? The MN has to understand:
   
   - what a handover is at the IP level
   - what an IP context transfer is
   - that QoS context is (sometimes) transferred separately from other
     context
   - what the nature of the failure was, and thus, what action to take.
   - how and with what entity to initiate QoS re-negotiation.

  The knowledge for all of the above is either explicitly or implicitly
built into the MN. If the intent were for the MN to receive back a message
that indicating "Gold service not available" then this is simply a session
disconnect. If the intent is for the MN to be told that "the QoS associated
with Gold service" has failed, then the MN has to know that Gold service
is actually a combination of features (AAA, security, HC), and to initiate
negotiation, it has to be able to talk to the individual network entities
- entities which may not even exist within a given network (e.g. a provision
model).

 So, how is the MN ignorant of CT? Service models?

 Keep in mind, according to the CT requirements, CT does not know what
is contained in the data chunks it transports. Thus, at best, it can
only forward to the MN that data chunk or another, opaque data chunk.
Even this capability is a major modification to what should be
a simple state machine for the CT protocol.

Gary

*snip*

 

>
>
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis
>

------_=_NextPart_001_01C1DF3C.25220886-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Mon Apr 8 16:56:11 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06241 for ; Mon, 8 Apr 2002 16:56:06 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA10721 for nsis-archive@odin.ietf.org; Mon, 8 Apr 2002 16:56:10 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA09780; Mon, 8 Apr 2002 16:43:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA09672 for ; Mon, 8 Apr 2002 16:43:02 -0400 (EDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05748; Mon, 8 Apr 2002 16:42:57 -0400 (EDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id NAA04565; Mon, 8 Apr 2002 13:42:28 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g38KgS304947; Mon, 8 Apr 2002 13:42:28 -0700 X-mProtect: <200204082042> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd8vJw5Q; Mon, 08 Apr 2002 13:42:26 PDT Message-ID: <3CB200B2.7BFA438F@iprg.nokia.com> Date: Mon, 08 Apr 2002 13:42:26 -0700 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Gary Kenward CC: "'James Kempf'" , Nakhjiri Madjid-MNAKHJI1 , Hemant.Chaskar@nokia.com, nsis@ietf.org, seamoby@ietf.org Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. References: <9FBD322B7824D511B36900508BF93C9C01AA49ED@zcard031.ca.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit Gary Kenward wrote: > > > "Re-create" was Rajeev's term, not mine. I think that it is an > appropriate > term if one considers other mechanisms besides session setup > signalling. > Either way, it is not a CT function. > By "re-create" I meant the MN establishes a context through feature-specific signaling, e.g., QoS signaling. I think I described this in the associated posting. > > As I outlined in one of my other posts, why would you perform CT to an > > AR that did not have the necessary capabilities. Is this actually > about > CAR failure?? you may have missed my response.. Anyway, you would like to be able to do CT without assuming CAR support. When you do CT and the target AR does not support the feature or only partially supports it (IPv6/UDP/RTP versus IPv6/UDP only header compression) , that's an example where you want the MN notified. -Rajeev > > > Gary > > > -----Original Message----- > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > Sent: April 8, 2002 14:26 > > To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Rajeev Koodli'; Nakhjiri > > Madjid-MNAKHJI1 > > Cc: Hemant.Chaskar@nokia.com; nsis@ietf.org; seamoby@ietf.org > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > Gary, > > > > I don't think the issue is having the MN re-create the context. Is > is > > allowing the MN to recover by re-running the actions that > > were necessary > > to create the context in the first place, in the event the AR > > was unable > > to interpret it. > > Thus, for example, suppose that QoS context is transferred from old > to > > new AR, but new AR for some reason can't interpret it, > > perhaps there is > > no bandwidth left or perhaps the new AR uses a different > > representation > > for QoS context. The MN would need to be informed somehow so that it > > > could re-do its QoS signaling. > > > > jak > > > > ----- Original Message ----- > > From: "Gary Kenward" > > To: "'Rajeev Koodli'" ; "Nakhjiri > > Madjid-MNAKHJI1" > > Cc: ; ; > > Sent: Monday, April 08, 2002 10:54 AM > > Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > > Rajeev: > > > > > > In order for the MN to "recreate the context", the MN would > > > have to understand the semantics of Context transfer, etc., > > > and, more important, there would have to be a protocol or > > > protocols that would allow the MN to recreate contexts at an AR. > > > I doubt that the latter is going to happen (e.g. authentication). > > > > > > IF and when a CT fails, the easiest way to "recreate" context > > > is for the sessions to be dropped. This may seem drastic, > > > but in reality, what is going to cause CT to fail and > > > how often will this happen? > > > > > > There may be mitigating actions that could be taken to > re-establish > > > certain sessions. But these decisions are must be driven by > > the policy > > > of the network administration (explicit or implicity), and comply > > > with the security, resource management and accounting requirements > > > > for the network. Hopefully, none of these mitigating > > actions requires > > > more over-the-air signalling. > > > > > > Gary > > > > > > > -----Original Message----- > > > > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] > > > > Sent: April 5, 2002 17:46 > > > > To: Nakhjiri Madjid-MNAKHJI1 > > > > Cc: Kenward, Gary [WDLN2:AN10:EXCH]; Hemant.Chaskar@nokia.com; > > > > nsis@ietf.org; seamoby@ietf.org > > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after > handoff. > > > > > > > > > > > > > > > > Hello Madjid, > > > > > > > > Nakhjiri Madjid-MNAKHJI1 wrote: > > > > > > > > > Hello Rajeev, > > > > > > > > > > I agreed with everything you say below, except one thing: > > > > > CT can only transfer whatever QoS state that is usable at the > > newAR. > > > > > If the new network is using a different QoS technology with > > > > different > > > > > QoS parameters, then I am not sure if CT by itself can do > > > > the job, unless > > > > > you add your own mapping functionality. > > > > > > > > > > > > > This would be an example where the new AR sends a > > > > notification to the MN so that the MN can take > > > > appropriate action (for instance, attempt to > > > > re-create the context). > > > > > > > > Regards, > > > > > > > > -Rajeev > > > > > > > > > > > > > > > > > > BR, > > > > > Madjid > > > > > > > > > > -----Original Message----- > > > > > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] > > > > > Sent: Friday, April 05, 2002 11:01 AM > > > > > To: Gary Kenward > > > > > Cc: Hemant.Chaskar@nokia.com; nsis@ietf.org; seamoby@ietf.org > > > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS > > after handoff. > > > > > > > > > > Hello, > > > > > > > > > > well, if the issue is QoS establishment after handover, > > > > > > > > > > - CT is applicable for establishing QoS state at the AR > > > > > - if further signaling is desired beyond the AR, NSIS may > > > > > consider it. I don't see how _signaling_ for QoS > > establishment > > > > > beyond AR is relevant for seamoby. > > > > > > > > > > CAR _discovery_ could exchange QoS capability as one of the > > > > > parameters that might then be fed to a selection algorithm. > Any > > > > > signaling for actually establishing QoS itself beyond the AR > > > > > should be outside the scope of seamoby.. > > > > > > > > > > Regards, > > > > > > > > > > -Rajeev > > > > > > > > > > Gary Kenward wrote: > > > > > > > > > > > > > > > > > > > > > > > Hemant: > > > > > > > > > > > > Just a point of clarification, but as I understand CARD > (and > > > > > > I don't understand it well), it is not a QoS negotiation > > > > > > protocol. The main application that you are referring to > > primarily > > > > > > arises out of a perceived need to determine at the MN the > > > > best link > > > > > > layer to handover over to when inter-technology handovers > are > > > > > > involved. > > > > > > It can be applied to intra-technology handovers, but the > value > > in > > > > > > that situation is highly questionable (e.g. since it is a > > > > discovery > > > > > > protocol, the implication is that the purpose is to > determine > > the > > > > > > choice of channels available; for intra-technology > > > > handovers, there > > > > > > are many, many reasons why this "choice" may not be > > available). > > > > > > > > > > > > There is a requirement, 5.1.2, which seems to imply > > > > NSIS involvement > > > > > > > > > > > > during/after a handover. John has stated that this is not > the > > > > > > intention > > > > > > (please correct me if I have this wrong John), in which > > > > case I think > > > > > > 5.1.2 needs to be clarified. > > > > > > > > > > > > Specifically, is NSIS to be used to negotiated new > > QoS for an > > > > > > existing flow after a handover, or is it specifically for > > > > establishing > > > > > > > > > > > > QoS for a new flow? I don't think the answer is boolean: the > > > role > > > > > > of NSIS in QoS re-negotiation is still open, I believe, > > > > and clearly > > > > > > handover is a dynamic situation that could cause the QoS > > > > provided to > > > > > > change. > > > > > > > > > > > > I have been told there is no issue, but here's a > frightening > > > > > > scenario: > > > > > > > > > > > > - a handover takes place, and context transfer > > > > has been used > > > > > > to > > > > > > move the QoS context to the new routers (by the > > > > requirements > > > > > > for > > > > > > CT this could be intra-, or inter- technology. > > Some of us > > > > > > believe > > > > > > that for "seamless" handovers, the context will be > > > > available at > > > > > > > > > > > > routers before the first packets need to be > forwarded. > > This > > > > > > implies > > > > > > that there is a relationship, probabilistic > > > > perhaps, between > > > > > > the handover process and the target ARs for CT. > > > > > > > > > > > > - CARD is used by the MN to influence the handover > > > > decision (it > > > > > > is not clear to me how this happens, but it seems > > > > clear that > > > > > > for a more "seamless" handover, the MN should > > > > chose an AR that > > > > > > has received the appropriate context; if not, > > then what? > > > > > > > > > > > > - NSIS kicks in and starts re-negotiating QoS > > > > because of changes > > > > > > introduced by the handover; > > > > > > > > > > > > How do these three protocols interact to produce > predictable > > > > > > outcomes? > > > > > > Or, perhaps, the question is, how do the functional entities > > > > > > > associated > > > > > > with the three protocols interact before, during and > > > > after a handover? > > > > > > > > > > > > If it the interaction is within the functional entities, the > > > > > > > respective > > > > > > wg's could declare the issue out of scope, but this > > > > approach does not > > > > > > sit well with me, for it seems to defer the problem to > > > > the people who > > > > > > have to implement this "stuff". > > > > > > > > > > > > Am I imagining things? > > > > > > > > > > > > Cheers, > > > > > > Gary > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Hemant.Chaskar@nokia.com > > [mailto:Hemant.Chaskar@nokia.com] > > > > > > > Sent: April 4, 2002 22:33 > > > > > > > To: nsis@ietf.org > > > > > > > Subject: RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > > > > > > > > > Hi Sharif: > > > > > > > > > > > > > > There is currently a debate going on in Seamoby as > > to whether > > > > > > > this QoS negotiation be covered by NSIS or Seamoby (CAR > > > > > > > discovery protocol). > > > > > > > > > > > > > > IMHO it should be covered by CAR discovery and not NSIS. > CAR > > > > > > > discovery is supposed to identify candidate access routers > > > > > > > > for handoff and QoS is an important property for > candidacy. > > > > > > > > > > > > > > Br, > > > > > > > Hemant > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: ext Shahrier, Sharif M. > > > > > > > [mailto:Sharif.Shahrier@InterDigital.com] > > > > > > > Sent: Thursday, April 04, 2002 3:35 PM > > > > > > > To: Shahrier, Sharif M. > > > > > > > Cc: 'nsis@ietf.org' > > > > > > > Subject: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > > > > > > > > > > > > > > > > I have a question for clarification. > > > > > > > > > > > > > > I think it was stated that NSIS should only be > > > > concerned with the > > > > > > > establishment of QoS after handoff. > > > > > > > > > > > > > > This is inconvienent with respect to IP-level QoS > > > > > > > negotiation, which ideally > > > > > > > should be done before handoff has taken place. > > > > > > > > > > > > > > QoS negotiation is in the current requirements draft. > > > > > > > > > > > > > > So, NSIS signaling protocol development should be > concerned > > > > > > > with activity > > > > > > > before handoff occurs. > > > > > > > > > > > > > > Sharif. > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > 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 > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Seamoby mailing list > > > > > Seamoby@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > > _______________________________________________ > > > > > Seamoby mailing list > > > > > Seamoby@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > > > > > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Mon Apr 8 17:54:17 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07653 for ; Mon, 8 Apr 2002 17:54:17 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA15713 for nsis-archive@odin.ietf.org; Mon, 8 Apr 2002 17:54:21 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA14436; Mon, 8 Apr 2002 17:34:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA14405 for ; Mon, 8 Apr 2002 17:34:05 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07085 for ; Mon, 8 Apr 2002 17:33:55 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g38LXBt26346; Mon, 8 Apr 2002 17:33:11 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 8 Apr 2002 17:33:11 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA49F9@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Cedric Westphal'" , "'john.loughney@nokia.com'" Cc: "'Hemant.Chaskar@nokia.com'" , "'nsis@ietf.org'" Subject: RE: [NSIS] Establishing QoS after handoff. Date: Mon, 8 Apr 2002 17:33:12 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DF44.F0E73E02" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1DF44.F0E73E02 Content-Type: text/plain; charset="iso-8859-1" I concur with Cedric's observations. I think that there is still confusion as to where CAR leaves off and NSIS begins. If CAR does QoS negotiation, then will it not require much of the same signalling semantics and syntax as the NSIS solution requires to establish QoS? Is this redundancy necessary? Also, while I keep thinking I that understand where CT ends and CAR/NSIS begin, this think is constantly challenged by proposals such as the one made recently to have CT signal service feature incompatibilities/transfer failures. How many signalling protocols does one need to create and maintain QoS??? Wouldn't it be preferably to have "a" context transfer protocol and "a" QoS signalling protocol and "a" discovery protocol? We are not (as far as I know) talking about alternative solutions here, but rather three protocols that may often be used together, hopefully with consistent results. Gary -----Original Message----- From: Cedric Westphal [mailto:cedric@iprg.nokia.com] Sent: April 5, 2002 21:43 To: john.loughney@nokia.com Cc: Hemant.Chaskar@nokia.com; nsis@ietf.org Subject: Re: [NSIS] Establishing QoS after handoff. John, just one question: john.loughney@nokia.com wrote: Hi all,Just to follow on to Hemant's comment: There is currently a debate going on in Seamoby as to whether this QoS negotiation be covered by NSIS or Seamoby (CAR discovery protocol). IMHO it should be covered by CAR discovery and not NSIS. CAR discovery is supposed to identify candidate access routers for handoff and QoS is an important property for candidacy. CAR discovery may be used to select handoff targets withcorrect QoS support / capabilities. Context Transfer (CT)can be used with the handoff procedure to ensure properQoS state gets transfered to the new access router. how does the CAR know whether or not it is able to provide the QoS for the flows of the MN. If the question is QoS on the MN-CAR link, then it is easy, but what if the question is on the CAR-CN side? It seems to me that in Seamoby, both CARD and CT could act as triggers to NSIS (QI I guess). CARD to assess whether the CAR-CN is available, using NSIS as a probing mechanism, and CT to make the NAR-CN QoS re-establishment. If there is anyone interested in this work, please let meknow. The SeaMoby chairs asked me to see if NSIS can providethem any information about QoS needs. Then both CARD and CT would need NSIS input/interaction... Cheers, Cedric. thanks,John_______________________________________________nsis mailing listnsis@ietf.orghttps://www1.ietf.org/mailman/listinfo/nsis ------_=_NextPart_001_01C1DF44.F0E73E02 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [NSIS] Establishing QoS after handoff.

I concur with Cedric's observations.
 
I think that there is still confusion as to where = CAR leaves off and NSIS begins.
If CAR does QoS negotiation, then will it not = require much of the same signalling
semantics and syntax as the NSIS solution requires = to establish QoS? Is this
redundancy necessary?
 
Also, while I keep thinking I that understand where = CT ends and CAR/NSIS begin,
this think is constantly challenged by proposals = such as the one made recently
to have CT signal service feature = incompatibilities/transfer failures.
 
How many signalling protocols does one need to = create and maintain QoS???
Wouldn't it be preferably to have "a" = context transfer protocol and "a"
QoS signalling protocol and "a" discovery = protocol?
 
We are not (as far as I know) talking about = alternative solutions here, but rather
three protocols that may often be used together, = hopefully with consistent results.
 
Gary
 
 
-----Original Message-----
From: Cedric Westphal [mailto:cedric@iprg.nokia.com]<= /FONT>
Sent: April 5, 2002 21:43
To: john.loughney@nokia.com
Cc: Hemant.Chaskar@nokia.com; nsis@ietf.org
Subject: Re: [NSIS] Establishing QoS after = handoff.


John,

just one question:

john.loughney@nokia.com wrote:

Hi all,Just to follow on to Hemant's comment:
There is currently a debate going on in Seamoby as = to whether this QoS negotiation be covered by NSIS or Seamoby (CAR = discovery protocol). IMHO it should be covered by CAR discovery and not = NSIS. CAR discovery is supposed to identify candidate access routers = for handoff and QoS is an important property for candidacy.

CAR discovery may be used to select handoff targets = withcorrect QoS support / capabilities.  Context Transfer (CT)can = be used with the handoff procedure to ensure properQoS state gets = transfered to the new access router.

how does the CAR know whether or not it is able to = provide the QoS
for the flows of the MN. If the question is QoS on = the MN-CAR link,
then it is easy, but what if the question is on the = CAR-CN side?

It seems to me that in Seamoby, both CARD and CT = could act as triggers
to NSIS (QI I guess). CARD to assess whether the = CAR-CN is available,
using NSIS as a probing mechanism, and CT to make = the NAR-CN QoS
re-establishment.

If there is anyone interested in this work, please = let meknow.  The SeaMoby chairs asked me to see if NSIS can = providethem any information about QoS needs.

Then both CARD and CT would need NSIS = input/interaction...
Cheers,

Cedric.

thanks,John_______________________________________________nsis = mailing = listnsis@ietf.orghttps://www1.ietf.org/mailman/listinfo/nsis

------_=_NextPart_001_01C1DF44.F0E73E02-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Mon Apr 8 17:55:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07702 for ; Mon, 8 Apr 2002 17:55:21 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA15777 for nsis-archive@odin.ietf.org; Mon, 8 Apr 2002 17:55:25 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA14858; Mon, 8 Apr 2002 17:39:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA14751 for ; Mon, 8 Apr 2002 17:39:10 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07236; Mon, 8 Apr 2002 17:39:01 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g38LYSi14243; Mon, 8 Apr 2002 17:34:29 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 8 Apr 2002 17:34:28 -0400 Received: from zrtps0kk.us.nortel.com ([47.140.192.53]) by zcard00n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HLDB9CTY; Mon, 8 Apr 2002 15:59:05 -0400 Received: from 47.234.0.34 ([47.234.0.34]) by zrtps0kk.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with SMTP id g38JwjD12889; Mon, 8 Apr 2002 15:58:45 -0400 (EDT) Received: from optimus.ietf.org (ietf.org [132.151.1.19]) by with SMTP (MailShield v2.04 - SOLARIS/SPARC Jul 18 2001 17:16:48); Mon, 08 Apr 2002 15:55:23 -0400 Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA04370; Mon, 8 Apr 2002 15:51:18 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA04250 for ; Mon, 8 Apr 2002 15:51:11 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04269; Mon, 8 Apr 2002 15:51:06 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g38JkYt15797; Mon, 8 Apr 2002 15:46:34 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 8 Apr 2002 15:46:34 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA49FA@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Nakhjiri Madjid-MNAKHJI1'" , "'Rajeev Koodli'" , James Kempf Cc: Hemant.Chaskar@nokia.com, nsis@ietf.org, seamoby@ietf.org Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Mon, 8 Apr 2002 17:34:26 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DF45.0A4CEAB8" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1DF45.0A4CEAB8 Content-Type: text/plain; charset="iso-8859-1" Can anyone offer an explaining of how or why CT would add significantly to the already unreliable physics of handover? What failure modes for CT would be noticeable above the unavoidable rate of handover failures due the vagaries of wireless coverage and wireless link layer performance???? If CT fails, then the handover fails. It is that simple. If CT were to fail with every 2nd handover attempt, then there would be a problem. But, I cannot seriously see CT failing more then every one in a million handover attempts, or less. CT should not be attempted if there is an incompatibility between source and destination ARs. And, I HAD thought that it was the purpose of CAR to identify those incompatibilities and thus avoid doing CT when it is clear it would fail. How to mitigate those incompatibles is not a CT issue, it is a service adaptation issue, which can be resolved in a number of ways, some of which would imply signalled negotiation either between the ARs or between the ARs and the MN. Regards, Gary > -----Original Message----- > From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] > Sent: April 5, 2002 16:58 > To: 'Rajeev Koodli'; James Kempf > Cc: Kenward, Gary [WDLN2:AN10:EXCH]; Hemant.Chaskar@nokia.com; > nsis@ietf.org; seamoby@ietf.org > Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > Agreed. I don't think reliability in signaling, which by the way > neither CT requirements, nor nsis requirements are covering, has to > do with failure in QoS negotiation. I don't think you can count > the case, where the QoS information that CT has given the AR is not > applicable, as a CT failure. > > Madjid > > -----Original Message----- > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] > Sent: Friday, April 05, 2002 12:03 PM > To: James Kempf > Cc: Gary Kenward; Hemant.Chaskar@nokia.com; nsis@ietf.org; > seamoby@ietf.org > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > James Kempf wrote: > > > Rajeev, > > > > I agree, but there is still an issue of how the AR would > notify the MN > > if CT fails. Is this covered by CT or not? > > > *snip* > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > ------_=_NextPart_001_01C1DF45.0A4CEAB8 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff.

Can anyone offer an explaining of how or why CT would = add significantly
to the already unreliable physics of handover? =

What failure modes for CT would be noticeable above = the unavoidable
rate of handover failures due the vagaries of = wireless coverage and
wireless link layer performance????

If CT fails, then the handover fails. It is that = simple. If CT were
to fail with every 2nd handover attempt, then there = would be a problem.
But, I cannot seriously see CT failing more then = every one in a million
handover attempts, or less.

CT should not be attempted if there is an = incompatibility between source
and destination ARs. And, I HAD thought that it was = the purpose of CAR
to identify those incompatibilities and thus avoid = doing CT when it is
clear it would fail. How to mitigate those = incompatibles is not a
CT issue, it is a service adaptation issue, which = can be resolved in
a number of ways, some of which would imply = signalled negotiation either
between the ARs or between the ARs and the MN. =

Regards,
Gary

> -----Original Message-----
> From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@moto= rola.com]
> Sent: April 5, 2002 16:58
> To: 'Rajeev Koodli'; James Kempf
> Cc: Kenward, Gary [WDLN2:AN10:EXCH]; = Hemant.Chaskar@nokia.com;
> nsis@ietf.org; seamoby@ietf.org
> Subject: RE: [Seamoby] RE: [NSIS] Establishing = QoS after handoff.
>
>
> Agreed. I don't think reliability in signaling, = which by the way
> neither CT requirements, nor nsis requirements = are covering, has to
> do with failure in QoS negotiation. I don't = think you can count
> the case, where the QoS information that CT has = given the AR is not
> applicable, as a CT failure.
>
> Madjid
>
> -----Original Message-----
> From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] =
> Sent: Friday, April 05, 2002 12:03 PM
> To: James Kempf
> Cc: Gary Kenward; Hemant.Chaskar@nokia.com; = nsis@ietf.org;
> seamoby@ietf.org
> Subject: Re: [Seamoby] RE: [NSIS] Establishing = QoS after handoff.
>
>
> James Kempf wrote:
>
> > Rajeev,
> >
> > I agree, but there is still an issue of = how the AR would
> notify the MN
> > if CT fails. Is this covered by CT or not? =
> >
>
*snip*
> _______________________________________________ =
> Seamoby mailing list
> Seamoby@ietf.org
> https://www1.ietf.org/mailman/listinfo/seamoby =
>

------_=_NextPart_001_01C1DF45.0A4CEAB8-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Mon Apr 8 18:09:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07991 for ; Mon, 8 Apr 2002 18:09:37 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA17071 for nsis-archive@odin.ietf.org; Mon, 8 Apr 2002 18:09:41 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA16127; Mon, 8 Apr 2002 17:59:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA16046 for ; Mon, 8 Apr 2002 17:58:59 -0400 (EDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07784; Mon, 8 Apr 2002 17:58:53 -0400 (EDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id OAA09738; Mon, 8 Apr 2002 14:58:26 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g38LwO830511; Mon, 8 Apr 2002 14:58:24 -0700 X-mProtect: <200204082158> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdiUEV7a; Mon, 08 Apr 2002 14:58:23 PDT Message-ID: <3CB2127F.A4E83662@iprg.nokia.com> Date: Mon, 08 Apr 2002 14:58:23 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Gary Kenward CC: nsis@ietf.org, seamoby@ietf.org Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. References: <9FBD322B7824D511B36900508BF93C9C01AA49FA@zcard031.ca.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit Hello Gary, I have $0.02 to add to the discussion: > Can anyone offer an explaining of how or why CT would add significantly > to the already unreliable physics of handover? Since I took physics in college, I can answer this. It would not add significantly to handover unreliability. > What failure modes for CT would be noticeable above the unavoidable > rate of handover failures due the vagaries of wireless coverage and > wireless link layer performance???? Congestion at intermediate routing points comes to mind. Just because two access points are both within range of a mobile node does not mean that they are neighbors to each other. They may even be attached to completely different physical media. > If CT fails, then the handover fails. It is that simple. If CT were > to fail with every 2nd handover attempt, then there would be a problem. I quite disagree with this statement. It depends on very many things. For instance, we have to be able to run CT without CARD. So, the destination access router might not offer header compression at all, for instance. Thus, the handover would succeed, but the context transfer (or, part of it) would fail. > But, I cannot seriously see CT failing more then every one in a million > handover attempts, or less. Cool! This could be good news. > CT should not be attempted if there is an incompatibility between source > and destination ARs. As noted above, I quite disagree with this statement. > And, I HAD thought that it was the purpose of CAR > to identify those incompatibilities and thus avoid doing CT when it is > clear it would fail. But, we have to be allowed to do CT without ever running CARD. For instance, we have reactive mode. > How to mitigate those incompatibles is not a > CT issue, it is a service adaptation issue, which can be resolved in > a number of ways, some of which would imply signalled negotiation either > between the ARs or between the ARs and the MN. Sometimes, the service cannot be adapted, and the feature context is just plain lost, because the feature is unavailable. Suppose, for example, that the contexts transferred include header compression, QoS, security, and other features. Now suppose that _only_ the security context can be transferred. That's still better than nothing! Maybe the QoS application will have to terminate, or go into degraded mode, but the other applications that need security will still be able to go on undisturbed. Why not? Regards, Charlie P. PS. I relucantly left NSIS on the CC: list, but shouldn't it be pruned? _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon Apr 8 21:13:18 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12185 for ; Mon, 8 Apr 2002 21:13:18 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA28162 for nsis-archive@odin.ietf.org; Mon, 8 Apr 2002 21:13:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA26342; Mon, 8 Apr 2002 20:57:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA26287 for ; Mon, 8 Apr 2002 20:56:59 -0400 (EDT) Received: from c007.snv.cp.net (c007-h014.c007.snv.cp.net [209.228.33.221]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA11706 for ; Mon, 8 Apr 2002 20:56:56 -0400 (EDT) Received: (cpmta 25904 invoked from network); 8 Apr 2002 17:56:26 -0700 Received: from 65.187.225.53 (HELO Study) by smtp.directvinternet.com (209.228.33.221) with SMTP; 8 Apr 2002 17:56:26 -0700 X-Sent: 9 Apr 2002 00:56:26 GMT Message-ID: <007101c1df61$64e44db0$0902a8c0@Study> From: "Phil Neumiller" To: "James Kempf" , "Gary Kenward" , "Nakhjiri Madjid-MNAKHJI1" , "Rajeev Koodli" Cc: , , References: <9FBD322B7824D511B36900508BF93C9C01AA49E8@zcard031.ca.nortel.com> <02ab01c1df2b$b0512420$7e6015ac@T23KEMPF> Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Mon, 8 Apr 2002 20:56:32 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit > Gary, > > I agree about session establishment, but the fact remains that if > failure of a context transfer for some reason leaves the MN without any > indication that it should proceed to re-establish the feature, then the > MN can't know when it should redo signaling to set up its new state. We > faced this issue with BETH/FMIPv6 and the solution we found there was to > have routers on the border of a fast handover coverage area inform the > MN what handover algorithm was supported by routers in the other > coverage area. While I think this could be done for the cases involving > router configuration, such as where the next access router can't > interpret the context, I am not so sure about failure due to dynamic > conditions, such as that the router currently has all its Gold Class > service bandwidth allocated (a QoS failure). This is wishful thinking. Lets finish the seamless handover over IP before we get into "gold class service". Convince me we have done just the basics! _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon Apr 8 21:13:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12201 for ; Mon, 8 Apr 2002 21:13:28 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA28178 for nsis-archive@odin.ietf.org; Mon, 8 Apr 2002 21:13:30 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA26211; Mon, 8 Apr 2002 20:55:00 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA26145 for ; Mon, 8 Apr 2002 20:54:55 -0400 (EDT) Received: from c007.snv.cp.net (c007-h013.c007.snv.cp.net [209.228.33.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA11674 for ; Mon, 8 Apr 2002 20:54:52 -0400 (EDT) Received: (cpmta 14576 invoked from network); 8 Apr 2002 17:54:22 -0700 Received: from 65.187.225.53 (HELO Study) by smtp.directvinternet.com (209.228.33.220) with SMTP; 8 Apr 2002 17:54:22 -0700 X-Sent: 9 Apr 2002 00:54:22 GMT Message-ID: <006b01c1df61$1b0293a0$0902a8c0@Study> From: "Phil Neumiller" To: "Rajeev Koodli" , "Gary Kenward" Cc: "Nakhjiri Madjid-MNAKHJI1" , , , References: <9FBD322B7824D511B36900508BF93C9C01AA49E6@zcard031.ca.nortel.com> <3CB1E487.5D2B7B37@iprg.nokia.com> Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Mon, 8 Apr 2002 20:54:28 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit > > IF and when a CT fails, the easiest way to "recreate" context > > is for the sessions to be dropped. This may seem drastic, > > but in reality, what is going to cause CT to fail and > > how often will this happen? > > > > This is a drastic idea! I think we can do better. Yes, stay connected to multiple ARs. You will need it anyway for log normal shadow fading in outdoor environments. People on this list don't realize that frequencies are going up and these things will deployed outdoors where shadow fading is the killer. Its not going to be one big cell after another. Its going to be connections two or three crappy cells and making the best use of them. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon Apr 8 21:14:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12233 for ; Mon, 8 Apr 2002 21:14:24 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA28223 for nsis-archive@odin.ietf.org; Mon, 8 Apr 2002 21:14:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA25994; Mon, 8 Apr 2002 20:52:32 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA25929 for ; Mon, 8 Apr 2002 20:52:25 -0400 (EDT) Received: from c007.snv.cp.net (c007-h013.c007.snv.cp.net [209.228.33.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA11604 for ; Mon, 8 Apr 2002 20:52:22 -0400 (EDT) Received: (cpmta 11662 invoked from network); 8 Apr 2002 17:51:43 -0700 Received: from 65.187.225.53 (HELO Study) by smtp.directvinternet.com (209.228.33.220) with SMTP; 8 Apr 2002 17:51:43 -0700 X-Sent: 9 Apr 2002 00:51:43 GMT Message-ID: <006501c1df60$bc502cf0$0902a8c0@Study> From: "Phil Neumiller" To: "James Kempf" , "Gary Kenward" , "'Rajeev Koodli'" , "Nakhjiri Madjid-MNAKHJI1" Cc: , , References: <9FBD322B7824D511B36900508BF93C9C01AA49E6@zcard031.ca.nortel.com> <02a201c1df2a$cc4810e0$7e6015ac@T23KEMPF> Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Mon, 8 Apr 2002 20:51:49 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "James Kempf" To: "Gary Kenward" ; "'Rajeev Koodli'" ; "Nakhjiri Madjid-MNAKHJI1" Cc: ; ; Sent: Monday, April 08, 2002 2:25 PM Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > Gary, > > I don't think the issue is having the MN re-create the context. Is is > allowing the MN to recover by re-running the actions that were necessary > to create the context in the first place, in the event the AR was unable > to interpret it. Don't you agree that there will need to be several target ARs all receiving the context simultaneously, possibly via an anycast addressing structure? > Thus, for example, suppose that QoS context is transferred from old to > new AR, but new AR for some reason can't interpret it, perhaps there is > no bandwidth left or perhaps the new AR uses a different representation > for QoS context. The MN would need to be informed somehow so that it > could re-do its QoS signaling. Reword as, for example, suppose that QoS context is transferred to "a newly added AR", but the new AR can not interpret it. The MN could choose to skip using this AR completely. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon Apr 8 21:14:51 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12261 for ; Mon, 8 Apr 2002 21:14:51 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA28279 for nsis-archive@odin.ietf.org; Mon, 8 Apr 2002 21:14:53 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA26492; Mon, 8 Apr 2002 20:58:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA26415 for ; Mon, 8 Apr 2002 20:58:02 -0400 (EDT) Received: from c007.snv.cp.net (c007-h011.c007.snv.cp.net [209.228.33.217]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA11720 for ; Mon, 8 Apr 2002 20:57:59 -0400 (EDT) Received: (cpmta 12385 invoked from network); 8 Apr 2002 17:57:31 -0700 Received: from 65.187.225.53 (HELO Study) by smtp.directvinternet.com (209.228.33.217) with SMTP; 8 Apr 2002 17:57:31 -0700 X-Sent: 9 Apr 2002 00:57:31 GMT Message-ID: <007f01c1df61$8b8ab670$0902a8c0@Study> From: "Phil Neumiller" To: "Gary Kenward" , "'James Kempf'" , "'Rajeev Koodli'" , "Nakhjiri Madjid-MNAKHJI1" Cc: , , References: <9FBD322B7824D511B36900508BF93C9C01AA49ED@zcard031.ca.nortel.com> Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Mon, 8 Apr 2002 20:57:37 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_007C_01C1DF40.03CAFC20" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_007C_01C1DF40.03CAFC20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff.>>Gary wrote: >>As I outlined in one of my other posts, why would you perform CT to an = >>AR that did not have the necessary capabilities. Is this actually = about=20 >>CAR failure??=20 Yupper I agree! ------=_NextPart_000_007C_01C1DF40.03CAFC20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Seamoby] RE: [NSIS] Establishing QoS after = handoff.
>>Gary wrote:
>>As I outlined in one of my other posts, why = would you=20 perform CT to an
>>AR that did not have = the=20 necessary capabilities. Is this actually about
>>CAR failure??
 
Yupper I agree!
 
------=_NextPart_000_007C_01C1DF40.03CAFC20-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon Apr 8 21:17:47 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12318 for ; Mon, 8 Apr 2002 21:17:47 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA28472 for nsis-archive@odin.ietf.org; Mon, 8 Apr 2002 21:17:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA27071; Mon, 8 Apr 2002 21:01:22 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA27006 for ; Mon, 8 Apr 2002 21:01:18 -0400 (EDT) Received: from c007.snv.cp.net (c007-h000.c007.snv.cp.net [209.228.33.206]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA11815 for ; Mon, 8 Apr 2002 21:01:15 -0400 (EDT) Received: (cpmta 703 invoked from network); 8 Apr 2002 18:00:46 -0700 Received: from 65.187.225.53 (HELO Study) by smtp.directvinternet.com (209.228.33.206) with SMTP; 8 Apr 2002 18:00:46 -0700 X-Sent: 9 Apr 2002 01:00:46 GMT Message-ID: <008801c1df62$001ffd10$0902a8c0@Study> From: "Phil Neumiller" To: "Gary Kenward" , "'Rajeev Koodli'" Cc: "Nakhjiri Madjid-MNAKHJI1" , , , References: <9FBD322B7824D511B36900508BF93C9C01AA49EF@zcard031.ca.nortel.com> Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Mon, 8 Apr 2002 21:00:53 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff.Aaarrghgh! See below.... >----- Original Message ----- >From: Gary Kenward >To: 'Rajeev Koodli' >Cc: Nakhjiri Madjid-MNAKHJI1 ; Hemant.Chaskar@nokia.com ; nsis@ietf.org ; seamoby@ietf.org >Sent: Monday, April 08, 2002 4:08 PM >Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. >Rajeev: > A user starts up an application that requests a "gold service". Define "gold service"? Define SeaMoby? What on earth are we talking about. The starting place is seamless handover and always has been. If we win that battle the rest is relatively easy. Why do we focus on the chrome when we need to work on the engine? >The protocol stack (perhaps an NSIS protocol stack) sends in a >request from MN to AN for gold service". Nice. Why don't we get UDP/TCP/SCTP to work first? _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon Apr 8 21:24:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12606 for ; Mon, 8 Apr 2002 21:24:41 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA28891 for nsis-archive@odin.ietf.org; Mon, 8 Apr 2002 21:24:43 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA27824; Mon, 8 Apr 2002 21:09:41 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA27678 for ; Mon, 8 Apr 2002 21:09:32 -0400 (EDT) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12028; Mon, 8 Apr 2002 21:09:25 -0400 (EDT) Received: from T23KEMPF (dhcp171.docomolabs-usa.com [172.21.96.171]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g3918SI10963; Mon, 8 Apr 2002 18:08:28 -0700 (PDT) Message-ID: <002b01c1df62$d622f9d0$ab6015ac@T23KEMPF> From: "James Kempf" To: "Gary Kenward" , "Nakhjiri Madjid-MNAKHJI1" , "Rajeev Koodli" Cc: , , References: <9FBD322B7824D511B36900508BF93C9C01AA49EE@zcard031.ca.nortel.com> Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Mon, 8 Apr 2002 18:06:50 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit Gary, Well, clearly we have a disagreement here. If it is not the CT protocol, then I do not know how else it should be done. Basically, if the router can't for some reason use the context to complete the handover, I believe it has an obligation to inform the MN so that the MN can recover. jak ----- Original Message ----- From: "Gary Kenward" To: "'James Kempf'" ; "Nakhjiri Madjid-MNAKHJI1" ; "Rajeev Koodli" Cc: ; ; Sent: Monday, April 08, 2002 12:51 PM Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > I agree that the MN must be notified (frankly, ulimitately, the MN > will find out, even without a signalling message). > > I disagree that this has anything to do with the CT protocol. > > Gary > > > -----Original Message----- > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > Sent: April 8, 2002 14:32 > > To: Kenward, Gary [WDLN2:AN10:EXCH]; Nakhjiri Madjid-MNAKHJI1; Rajeev > > Koodli > > Cc: Hemant.Chaskar@nokia.com; nsis@ietf.org; seamoby@ietf.org > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > Gary, > > > > I agree about session establishment, but the fact remains that if > > failure of a context transfer for some reason leaves the MN > > without any > > indication that it should proceed to re-establish the > > feature, then the > > MN can't know when it should redo signaling to set up its new > > state. We > > faced this issue with BETH/FMIPv6 and the solution we found > > there was to > > have routers on the border of a fast handover coverage area inform the > > MN what handover algorithm was supported by routers in the other > > coverage area. While I think this could be done for the cases > > involving > > router configuration, such as where the next access router can't > > interpret the context, I am not so sure about failure due to dynamic > > conditions, such as that the router currently has all its Gold Class > > service bandwidth allocated (a QoS failure). > > > > In any event, I think there is need for some kind of signaling to > > indicate to the MN that context transfer has failed and that the MN > > needs to redo signaling to re-establish feature contexts. > > > > jak > > > > ----- Original Message ----- > > From: "Gary Kenward" > > To: "'James Kempf'" ; "Nakhjiri > > Madjid-MNAKHJI1" ; "Rajeev Koodli" > > > > Cc: ; ; > > Sent: Monday, April 08, 2002 11:08 AM > > Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > > James: > > > > > > My main problem with the theme in this discussion is that > > > CT is a context transfer protocol, not a session management > > protocol. > > > In particular, when there are feature context specific issues, it is > > > best to handle session re-establishment/re-negotiation/maintenance > > using > > > the protocol(s) that were designed to set up the services > > in the first > > > place. CT should not be stretched into being a general signalling > > protocol. > > > > > > In addition, there is the perhaps greater argument that the most > > > effective method of correcting handover issues is not through over > > > the air signalling exchanges. Given the nature of the wireless link, > > > it will almost always be faster and always be more cost > > effective, to > > > correct any problems with signalling within the > > infrastructure (if it > > is > > > needed). > > > > > > Gary > > > > > > > -----Original Message----- > > > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > > > Sent: April 8, 2002 11:42 > > > > To: Nakhjiri Madjid-MNAKHJI1; Rajeev Koodli > > > > Cc: Kenward, Gary [WDLN2:AN10:EXCH]; Hemant.Chaskar@nokia.com; > > > > nsis@ietf.org; seamoby@ietf.org > > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > Madjid, > > > > > > > > The issue isn't reliability, it is whether the target AR can > > interpret > > > > the context intelligably. If not, the MN may need to recover > > > > by actually > > > > re-initializing whatever feature the context was being transfered > > for. > > > > But it cannot do this unless it knows that the CT has failed. > > > > > > > > For some feature contexts, like header compression, this > > > > isn't a problem > > > > because it will re-initialize automatically, but for AAA or QoS it > > > > clearly will be. > > > > > > > > jak > > > > > > > > ----- Original Message ----- > > > > From: "Nakhjiri Madjid-MNAKHJI1" > > > > To: "'James Kempf'" ; "Rajeev Koodli" > > > > > > > > Cc: "Gary Kenward" ; > > > > ; ; > > > > Sent: Friday, April 05, 2002 3:00 PM > > > > Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > Well, you are opening a can of worm that took seamoby 3 months > > > > > to close without any results. People could not agree on the > > > > > reliability needs of CT. We added a reliability mechanism to our > > > > > CT proposal that covered both retransmission and updates. > > > > > > > > > > Madjid > > > > > > > > > > -----Original Message----- > > > > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > > > > Sent: Friday, April 05, 2002 12:22 PM > > > > > To: Rajeev Koodli > > > > > Cc: Gary Kenward; Hemant.Chaskar@nokia.com; nsis@ietf.org; > > > > > seamoby@ietf.org > > > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS > > after handoff. > > > > > > > > > > > > > > > Agree. > > > > > > > > > > But I don't see anything in the CT requirements about > > handling CT > > > > > failure. > > > > > > > > > > ??? > > > > > > > > > > jak > > > > > > > > > > ----- Original Message ----- > > > > > From: "Rajeev Koodli" > > > > > To: "James Kempf" > > > > > Cc: "Gary Kenward" ; > > > > > ; ; > > > > > Sent: Friday, April 05, 2002 10:02 AM > > > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS > > after handoff. > > > > > > > > > > > > > > > > James Kempf wrote: > > > > > > > > > > > > > Rajeev, > > > > > > > > > > > > > > I agree, but there is still an issue of how the AR would > > notify > > > > the > > > > > MN > > > > > > > if CT fails. Is this covered by CT or not? > > > > > > > > > > > > > > > > > > > This notification should be covered by CT. We should offer > > > > > > seamless handover to NSIS :-) Seriously, this concerns > > > > > > robustness of CT protocol. > > > > > > > > > > > > -Rajeev > > > > > > > > > > > > > > > > > > > > > > > > > > jak > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > From: "Rajeev Koodli" > > > > > > > To: "James Kempf" > > > > > > > Cc: "Gary Kenward" ; > > > > > > > ; ; > > > > > > > > > Sent: Friday, April 05, 2002 9:19 AM > > > > > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS > > > > after handoff. > > > > > > > > > > > > > > > > > > > > > > > Hello Jim, > > > > > > > > > > > > > > > > James Kempf wrote: > > > > > > > > > > > > > > > > > There is an issue if CT fails. In that case, > > some kind of > > > > > > > negotiation > > > > > > > > > after handover would be required. > > > > > > > > > > > > > > > > > > So, I'd say that some indication of CT failure > > is needed. > > > > > > > > > > > > > > > > > > > > > > > > > Yes, but this is between AR and MN. If CT fails, the AR > > should > > > > > > > > notify the MN to engage in context re-creation. > > > > > > > > > > > > > > > > My point was specific to signaling _beyond_ AR (i.e., > > upstream > > > > > > > signaling) > > > > > > > > independent of failure/success of CT. > > > > > > > > > > > > > > > > Hope this is clearer.. > > > > > > > > > > > > > > > > -Rajeev > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > As for CAR, I don't see the relevance for QoS > > negotiation, > > > > > though it > > > > > > > may > > > > > > > > > be useful for finding a new wireless medium. I > > also see it > > > > > primarily > > > > > > > for > > > > > > > > > intertechnology handover, or, at best, > > > > interprovider handover. > > > > > > > > > > > > > > > > > > jak > > > > > > > > > ----- Original Message ----- > > > > > > > > > From: "Rajeev Koodli" > > > > > > > > > To: "Gary Kenward" > > > > > > > > > Cc: ; ; > > > > > > > > > > > > > > Sent: Friday, April 05, 2002 9:01 AM > > > > > > > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after > > > > > handoff. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hello, > > > > > > > > > > > > > > > > > > > > well, if the issue is QoS establishment after > > handover, > > > > > > > > > > > > > > > > > > > > - CT is applicable for establishing QoS state > > at the AR > > > > > > > > > > - if further signaling is desired beyond the AR, NSIS > > may > > > > > > > > > > consider it. I don't see how _signaling_ for QoS > > > > > establishment > > > > > > > > > > beyond AR is relevant for seamoby. > > > > > > > > > > > > > > > > > > > > CAR _discovery_ could exchange QoS capability as > > > > one of the > > > > > > > > > > parameters that might then be fed to a selection > > > > algorithm. > > > > > Any > > > > > > > > > > signaling for actually establishing QoS itself > > > > beyond the AR > > > > > > > > > > should be outside the scope of seamoby.. > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > > > > > > > -Rajeev > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Gary Kenward wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hemant: > > > > > > > > > > > > > > > > > > > > > > Just a point of clarification, but as I > > > > understand CARD > > > > > (and > > > > > > > > > > > I don't understand it well), it is not a QoS > > negotiation > > > > > > > > > > > protocol. The main application that you are > > referring > > to > > > > > > > primarily > > > > > > > > > > > arises out of a perceived need to determine at > > > > the MN the > > > > > best > > > > > > > link > > > > > > > > > > > layer to handover over to when inter-technology > > > > handovers > > > > > are > > > > > > > > > > > involved. > > > > > > > > > > > It can be applied to intra-technology handovers, but > > the > > > > > value > > > > > > > in > > > > > > > > > > > that situation is highly questionable (e.g. > > > > since it is a > > > > > > > discovery > > > > > > > > > > > protocol, the implication is that the purpose is to > > > > > determine > > > > > > > the > > > > > > > > > > > choice of channels available; for intra-technology > > > > > handovers, > > > > > > > there > > > > > > > > > > > are many, many reasons why this "choice" may not be > > > > > available). > > > > > > > > > > > > > > > > > > > > > > There is a requirement, 5.1.2, which seems to > > > > imply NSIS > > > > > > > > > involvement > > > > > > > > > > > > > > > > > > > > > > during/after a handover. John has stated that > > > > this is not > > > > > the > > > > > > > > > > > intention > > > > > > > > > > > (please correct me if I have this wrong John), in > > which > > > > case > > > > > I > > > > > > > think > > > > > > > > > > > 5.1.2 needs to be clarified. > > > > > > > > > > > > > > > > > > > > > > Specifically, is NSIS to be used to negotiated new > > QoS > > > > for > > > > > an > > > > > > > > > > > existing flow after a handover, or is it > > > > specifically for > > > > > > > > > establishing > > > > > > > > > > > > > > > > > > > > > > QoS for a new flow? I don't think the answer is > > boolean: > > > > the > > > > > > > role > > > > > > > > > > > of NSIS in QoS re-negotiation is still open, I > > believe, > > > > and > > > > > > > clearly > > > > > > > > > > > handover is a dynamic situation that could cause the > > QoS > > > > > > > provided to > > > > > > > > > > > change. > > > > > > > > > > > > > > > > > > > > > > I have been told there is no issue, but here's a > > > > > frightening > > > > > > > > > > > scenario: > > > > > > > > > > > > > > > > > > > > > > - a handover takes place, and context > > > > transfer has > > > > > been > > > > > > > used > > > > > > > > > > > to > > > > > > > > > > > move the QoS context to the new > > routers (by the > > > > > > > requirements > > > > > > > > > > > for > > > > > > > > > > > CT this could be intra-, or inter- > > > > technology. Some > > > > > of us > > > > > > > > > > > believe > > > > > > > > > > > that for "seamless" handovers, the > > > > context will be > > > > > > > available > > > > > > > > > at > > > > > > > > > > > > > > > > > > > > > > routers before the first packets need to be > > > > > forwarded. > > > > > > > This > > > > > > > > > > > implies > > > > > > > > > > > that there is a relationship, probabilistic > > > > perhaps, > > > > > > > between > > > > > > > > > > > the handover process and the target > > ARs for CT. > > > > > > > > > > > > > > > > > > > > > > - CARD is used by the MN to influence the > > handover > > > > > decision > > > > > > > (it > > > > > > > > > > > is not clear to me how this happens, but it > > seems > > > > > clear > > > > > > > that > > > > > > > > > > > for a more "seamless" handover, the MN > > > > should chose > > > > > an AR > > > > > > > > > that > > > > > > > > > > > has received the appropriate context; if > > > > not, then > > > > > what? > > > > > > > > > > > > > > > > > > > > > > - NSIS kicks in and starts re-negotiating > > > > QoS because > > > > > of > > > > > > > > > changes > > > > > > > > > > > introduced by the handover; > > > > > > > > > > > > > > > > > > > > > > How do these three protocols interact to produce > > > > > predictable > > > > > > > > > > > outcomes? > > > > > > > > > > > Or, perhaps, the question is, how do the functional > > > > entities > > > > > > > > > > > associated > > > > > > > > > > > with the three protocols interact before, > > > > during and after > > > > a > > > > > > > > > handover? > > > > > > > > > > > > > > > > > > > > > > If it the interaction is within the functional > > entities, > > > > the > > > > > > > > > > > respective > > > > > > > > > > > wg's could declare the issue out of scope, but this > > > > approach > > > > > > > does > > > > > > > > > not > > > > > > > > > > > sit well with me, for it seems to defer the > > > > problem to the > > > > > > > people > > > > > > > > > who > > > > > > > > > > > have to implement this "stuff". > > > > > > > > > > > > > > > > > > > > > > Am I imagining things? > > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > Gary > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > From: Hemant.Chaskar@nokia.com > > > > > > > [mailto:Hemant.Chaskar@nokia.com] > > > > > > > > > > > > Sent: April 4, 2002 22:33 > > > > > > > > > > > > To: nsis@ietf.org > > > > > > > > > > > > Subject: RE: [NSIS] Establishing QoS > > after handoff. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Sharif: > > > > > > > > > > > > > > > > > > > > > > > > There is currently a debate going on in Seamoby as > > to > > > > > whether > > > > > > > > > > > > this QoS negotiation be covered by NSIS or > > > > Seamoby (CAR > > > > > > > > > > > > discovery protocol). > > > > > > > > > > > > > > > > > > > > > > > > IMHO it should be covered by CAR discovery > > > > and not NSIS. > > > > > CAR > > > > > > > > > > > > discovery is supposed to identify candidate access > > > > routers > > > > > > > > > > > > for handoff and QoS is an important property for > > > > > candidacy. > > > > > > > > > > > > > > > > > > > > > > > > Br, > > > > > > > > > > > > Hemant > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > From: ext Shahrier, Sharif M. > > > > > > > > > > > > [mailto:Sharif.Shahrier@InterDigital.com] > > > > > > > > > > > > Sent: Thursday, April 04, 2002 3:35 PM > > > > > > > > > > > > To: Shahrier, Sharif M. > > > > > > > > > > > > Cc: 'nsis@ietf.org' > > > > > > > > > > > > Subject: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I have a question for clarification. > > > > > > > > > > > > > > > > > > > > > > > > I think it was stated that NSIS should only > > > > be concerned > > > > > with > > > > > > > the > > > > > > > > > > > > establishment of QoS after handoff. > > > > > > > > > > > > > > > > > > > > > > > > This is inconvienent with respect to IP-level QoS > > > > > > > > > > > > negotiation, which ideally > > > > > > > > > > > > should be done before handoff has taken place. > > > > > > > > > > > > > > > > > > > > > > > > QoS negotiation is in the current requirements > > draft. > > > > > > > > > > > > > > > > > > > > > > > > So, NSIS signaling protocol development should be > > > > > concerned > > > > > > > > > > > > with activity > > > > > > > > > > > > before handoff occurs. > > > > > > > > > > > > > > > > > > > > > > > > Sharif. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > Seamoby mailing list > > > > > > > > > > Seamoby@ietf.org > > > > > > > > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > Seamoby mailing list > > > > > > > > Seamoby@ietf.org > > > > > > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > Seamoby mailing list > > > > > > Seamoby@ietf.org > > > > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Seamoby mailing list > > > > > Seamoby@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > > _______________________________________________ > > > > > Seamoby mailing list > > > > > Seamoby@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > > > > > > > > > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon Apr 8 21:25:31 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12668 for ; Mon, 8 Apr 2002 21:25:31 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA28931 for nsis-archive@odin.ietf.org; Mon, 8 Apr 2002 21:25:33 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA27914; Mon, 8 Apr 2002 21:09:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA27829 for ; Mon, 8 Apr 2002 21:09:42 -0400 (EDT) Received: from c007.snv.cp.net (c007-h014.c007.snv.cp.net [209.228.33.221]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA12042 for ; Mon, 8 Apr 2002 21:09:38 -0400 (EDT) Received: (cpmta 1844 invoked from network); 8 Apr 2002 18:09:10 -0700 Received: from 65.187.225.53 (HELO Study) by smtp.directvinternet.com (209.228.33.221) with SMTP; 8 Apr 2002 18:09:10 -0700 X-Sent: 9 Apr 2002 01:09:10 GMT Message-ID: <00dd01c1df63$2c753640$0902a8c0@Study> From: "Phil Neumiller" To: "Charles E. Perkins" , "Gary Kenward" Cc: , References: <9FBD322B7824D511B36900508BF93C9C01AA49FA@zcard031.ca.nortel.com> <3CB2127F.A4E83662@iprg.nokia.com> Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Mon, 8 Apr 2002 21:09:17 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit ----- Original Message ----- > > What failure modes for CT would be noticeable above the unavoidable > > rate of handover failures due the vagaries of wireless coverage and > > wireless link layer performance???? > > Congestion at intermediate routing points comes to mind. Yes, and SOME MANET protocols are sensitive to this. > Just because two access points are both within range of a mobile node > does not mean that they are neighbors to each other. Aah, but maybe they want to be eh? Then what? > They may even > be attached to completely different physical media. Yes, but lets say I walk into a room with a Microsoft X100B-35S 100 Mbps wireless interface and you have your Binford 8000 and we want to chat. Should we not be able to take advantage of the local infrastructure? Securely??? _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon Apr 8 21:35:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12959 for ; Mon, 8 Apr 2002 21:35:12 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA29820 for nsis-archive@odin.ietf.org; Mon, 8 Apr 2002 21:35:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA28394; Mon, 8 Apr 2002 21:15:22 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA28328 for ; Mon, 8 Apr 2002 21:15:17 -0400 (EDT) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12302; Mon, 8 Apr 2002 21:15:14 -0400 (EDT) Received: from T23KEMPF (dhcp171.docomolabs-usa.com [172.21.96.171]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g391DqI11183; Mon, 8 Apr 2002 18:13:52 -0700 (PDT) Message-ID: <004a01c1df63$9751a070$ab6015ac@T23KEMPF> From: "James Kempf" To: "Gary Kenward" , "'Rajeev Koodli'" , "Nakhjiri Madjid-MNAKHJI1" Cc: , , References: <9FBD322B7824D511B36900508BF93C9C01AA49F0@zcard031.ca.nortel.com> Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Mon, 8 Apr 2002 18:12:14 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit Gary, When you say "handover failure" I think Mobile IP, and there is already some signaling available in FMIPv6/BETH to do this. This signaling does not extend to attributes of the IP service like whether or not the MN can connect to the network, what class of QoS service it gets, and any other security, etc.. There is currently no way to signal that the network expects the MN to reestablish these, except to say that the MN has entered a new AAA domain and should therefore perform network entry from scratch. This seems a little too heavyweight to me. jak ----- Original Message ----- From: "Gary Kenward" To: "'James Kempf'" ; "'Rajeev Koodli'" ; "Nakhjiri Madjid-MNAKHJI1" Cc: ; ; Sent: Monday, April 08, 2002 1:21 PM Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > James: > > > -----Original Message----- > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > Sent: April 8, 2002 15:55 > > To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Rajeev Koodli'; Nakhjiri > > Madjid-MNAKHJI1 > > Cc: Hemant.Chaskar@nokia.com; nsis@ietf.org; seamoby@ietf.org > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > As I outlined in one of my other posts, why would you > > perform CT to an > > > AR that did not have the necessary capabilities. Is this actually > > about > > > CAR failure?? > > > > > > > Yes and no. > > > > Suppose the MN is expecting CT to be performed and it is not > > because the > > A nit, but the MN does not expect CT. The MN expects continuous > service (i.e. seamless service), and knows nothing about how it is > supported (it could be provisioned). > > > new AR can't interpret the context. > > The old AR may discover this via CAR, but if there is no way to > > communicate it to the MN, then the MN can't know to perform the > > signaling from scratch on the new AR. One could either inform the MN > > beforehand to do the signaling, as is done with FMIPv6/BETH, or signal > > the MN on the new AR. > > > > For dynamic failures, such as when the AR runs out of Gold Class > > service, the signaling could only be done afterwards. > > I understand these scenarios, but I do not understand what they have > to do with CT. CT has never intended to be an MN signalling protocol. > Let me try a counter example: the service authorization fails. Would > a CT message saying the AA context transfer failed be of much use > to the MN? No, because the problem wasn't with the context, it was with > a disconnect between the service request and authorization profile for > that MN. > > There is a need for a "handover failure" indication message to the > MN (indicating full or partial handover failure), but this message should > be part of a different protocol from CT. > > Gary > > > > > jak > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon Apr 8 21:35:59 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12989 for ; Mon, 8 Apr 2002 21:35:58 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA29861 for nsis-archive@odin.ietf.org; Mon, 8 Apr 2002 21:36:01 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA28694; Mon, 8 Apr 2002 21:21:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA28624 for ; Mon, 8 Apr 2002 21:21:22 -0400 (EDT) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12444; Mon, 8 Apr 2002 21:21:18 -0400 (EDT) Received: from T23KEMPF (dhcp171.docomolabs-usa.com [172.21.96.171]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g391KTI11417; Mon, 8 Apr 2002 18:20:30 -0700 (PDT) Message-ID: <006001c1df64$847e5500$ab6015ac@T23KEMPF> From: "James Kempf" To: "Gary Kenward" , "'Rajeev Koodli'" Cc: "Nakhjiri Madjid-MNAKHJI1" , , , References: <9FBD322B7824D511B36900508BF93C9C01AA49F4@zcard031.ca.nortel.com> Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Mon, 8 Apr 2002 18:18:52 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit Gary, OK, I think I am beginning to see your point. The CT protocol is just a container, if a particular feature context fails, it is up to the code handling the feature context to actually perform the notification of the MN. The CT code doesn't do particular features. I think there is still the case of a failure in interpretation by the new AR, or even a failure in CT itself, like it got lost on the way. jak ----- Original Message ----- From: "Gary Kenward" To: "'Rajeev Koodli'" Cc: "Nakhjiri Madjid-MNAKHJI1" ; ; ; Sent: Monday, April 08, 2002 1:30 PM Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > Rajeev: > > A user starts up an application that requests a "gold service". > The protocol stack (perhaps an NSIS protocol stack) sends in a > request from MN to AN for gold service". A handover occurs, and > (according to your scenario), the QoS context transfer fails (for some > inexplicable reason). Some entity (the CT protocol stack according to > your proposal) sends an indication to the MN that the QoS context transfer > has failed (according to your proposal). How does the MN know what to do > with this notice? The MN has to understand: > > - what a handover is at the IP level > - what an IP context transfer is > - that QoS context is (sometimes) transferred separately from other > context > - what the nature of the failure was, and thus, what action to take. > - how and with what entity to initiate QoS re-negotiation. > > The knowledge for all of the above is either explicitly or implicitly > built into the MN. If the intent were for the MN to receive back a message > that indicating "Gold service not available" then this is simply a session > disconnect. If the intent is for the MN to be told that "the QoS associated > with Gold service" has failed, then the MN has to know that Gold service > is actually a combination of features (AAA, security, HC), and to initiate > negotiation, it has to be able to talk to the individual network entities > - entities which may not even exist within a given network (e.g. a provision > > model). > > So, how is the MN ignorant of CT? Service models? > > Keep in mind, according to the CT requirements, CT does not know what > is contained in the data chunks it transports. Thus, at best, it can > only forward to the MN that data chunk or another, opaque data chunk. > Even this capability is a major modification to what should be > a simple state machine for the CT protocol. > > Gary > > *snip* > > > > > > > > > _______________________________________________ > > 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 daemon@optimus.ietf.org Mon Apr 8 22:17:05 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14456 for ; Mon, 8 Apr 2002 22:17:04 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA01753 for nsis-archive@odin.ietf.org; Mon, 8 Apr 2002 22:17:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA00675; Mon, 8 Apr 2002 21:59:04 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA00612 for ; Mon, 8 Apr 2002 21:58:58 -0400 (EDT) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14191; Mon, 8 Apr 2002 21:58:54 -0400 (EDT) Received: from T23KEMPF (dhcp68.docomolabs-usa.com [172.21.96.68]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g391vWI12818; Mon, 8 Apr 2002 18:57:32 -0700 (PDT) Message-ID: <011201c1df69$b147fe10$ab6015ac@T23KEMPF> From: "James Kempf" To: "Phil Neumiller" , "Gary Kenward" , "'Rajeev Koodli'" , "Nakhjiri Madjid-MNAKHJI1" Cc: , , References: <9FBD322B7824D511B36900508BF93C9C01AA49E6@zcard031.ca.nortel.com> <02a201c1df2a$cc4810e0$7e6015ac@T23KEMPF> <006501c1df60$bc502cf0$0902a8c0@Study> Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Mon, 8 Apr 2002 18:55:54 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit Phil, > > Gary, > > > > I don't think the issue is having the MN re-create the context. Is is > > allowing the MN to recover by re-running the actions that were necessary > > to create the context in the first place, in the event the AR was unable > > to interpret it. > > Don't you agree that there will need to be several target ARs all receiving > the context > simultaneously, possibly via an anycast addressing structure? > Sure, in IPv6. But there is still no guarantee that the transfer will succeed. > > > Thus, for example, suppose that QoS context is transferred from old to > > new AR, but new AR for some reason can't interpret it, perhaps there is > > no bandwidth left or perhaps the new AR uses a different representation > > for QoS context. The MN would need to be informed somehow so that it > > could re-do its QoS signaling. > > Reword as, for example, suppose that QoS context is transferred to "a newly > added AR", but the new AR can not interpret it. The MN could choose to skip > using this AR completely. > Right, but it would have to know that so it could move to a different AR (if it had a choice). jak _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Tue Apr 9 01:51:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18693 for ; Tue, 9 Apr 2002 01:51:15 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA21372 for nsis-archive@odin.ietf.org; Tue, 9 Apr 2002 01:51:16 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA21196; Tue, 9 Apr 2002 01:46:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA21165 for ; Tue, 9 Apr 2002 01:46:23 -0400 (EDT) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18608 for ; Tue, 9 Apr 2002 01:46:21 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g395jVu00409 for ; Tue, 9 Apr 2002 08:45:32 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 9 Apr 2002 08:46:21 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 9 Apr 2002 08:46:21 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] Establishing QoS after handoff. Date: Tue, 9 Apr 2002 08:46:19 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64E25@esebe004.NOE.Nokia.com> Thread-Topic: [NSIS] Establishing QoS after handoff. Thread-Index: AcHfNamBn+zcEc7TR3yGOcSTkrcH8wAU+lzQ To: , Cc: , X-OriginalArrivalTime: 09 Apr 2002 05:46:21.0053 (UTC) FILETIME=[E0590AD0:01C1DF89] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id BAA21166 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Gary, > I think that there is still confusion as to where CAR leaves off and NSIS begins. > If CAR does QoS negotiation, then will it not require much of the same signalling > semantics and syntax as the NSIS solution requires to establish QoS? Is this > redundancy necessary? As I have been suggesting, perhaps it would be good to document these concerns in an Internet Draft - emails can only go so far. > Also, while I keep thinking I that understand where CT ends and CAR/NSIS begin, > this think is constantly challenged by proposals such as the one made recently > to have CT signal service feature incompatibilities/transfer failures. My personal opinion (in this area) is that SeaMoby works on solutions that focus on what happens in & during a handover between ARs and NSIS is more focused on the end-to-edge or end-to-end signaling path. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Tue Apr 9 03:16:11 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28142 for ; Tue, 9 Apr 2002 03:16:10 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA26127 for nsis-archive@odin.ietf.org; Tue, 9 Apr 2002 03:16:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA25863; Tue, 9 Apr 2002 03:10:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA25833 for ; Tue, 9 Apr 2002 03:10:25 -0400 (EDT) Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28046 for ; Tue, 9 Apr 2002 03:10:21 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g397BIJ03200 for ; Tue, 9 Apr 2002 10:11:18 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 9 Apr 2002 10:10:12 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 9 Apr 2002 10:10:13 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Tue, 9 Apr 2002 10:10:13 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD38D8E@esebe004.NOE.Nokia.com> Thread-Topic: NSIS Scoping (was Preemption) Thread-Index: AcHfKbiw5kMwUTXQQEaWcD+vOpLFigAatWCw To: , X-OriginalArrivalTime: 09 Apr 2002 07:10:13.0812 (UTC) FILETIME=[981B1F40:01C1DF95] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id DAA25834 Subject: [NSIS] RE: NSIS Scoping (was Preemption) Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi James, > I recommend including this option verses having to retrofit it into your work down the > road when this capability requirement from SPs and semi-private networks will look for > mechanisms to be utilized and find that NSIS isn't one of them. I seriously don't mean > that as any sort of threat, I just am in touch with many network administrators that > wish to have this capability and want the IETF to continue to include the possibility > of it in Standards Track efforts. > > All the while knowing that enabling this capability is a matter of local policy... The best way forward for this is to document what those needs are. Could you create a strawman draft? Thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Tue Apr 9 06:53:05 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01543 for ; Tue, 9 Apr 2002 06:53:05 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA08902 for nsis-archive@odin.ietf.org; Tue, 9 Apr 2002 06:53:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA08639; Tue, 9 Apr 2002 06:48:12 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA08608 for ; Tue, 9 Apr 2002 06:48:10 -0400 (EDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01495 for ; Tue, 9 Apr 2002 06:48:07 -0400 (EDT) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g39Am7s7012887 for ; Tue, 9 Apr 2002 12:48:07 +0200 (MEST) Received: FROM esealnt746.al.sw.ericsson.se BY esealnt461 ; Tue Apr 09 12:46:40 2002 +0200 Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 9 Apr 2002 12:46:41 +0200 Message-ID: <18A375D0D9974F41B8A10F193CA83E490AD6B3@enleent102.nl.eu.ericsson.se> From: "Georgios Karagiannis (ELN)" To: "'Sven Van den Bosch'" , nsis@ietf.org Subject: RE: [NSIS] proposals related to NSIS WG draft Date: Tue, 9 Apr 2002 12:46:39 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi Sven I agree with you, on introducing the term "QoS Receiver", however, I would very much appreciate if the sentence: "QoS Receiver: Network entity, located at the edge of or inside a QoS ..." is changed into: ""QoS Receiver: Network entity, located at an end host, an edge of or inside a QoS ..." Best Regards, Georgios -----Original Message----- From: Sven Van den Bosch [mailto:svenvandenbosch@hotmail.com] Sent: dinsdag 19 maart 2002 23:44 To: nsis@ietf.org Subject: [NSIS] proposals related to NSIS WG draft Hi all, As an outcome of this morning's NSIS meeting, we propose the following detailed additions to the WG draft. 1. Terminology - QoS Controller: Network entity responsible for interpreting and implementing the signaled QoS in the network. Failure to do so implies an admission control decision. It can only be triggered by another NSIS entity of the same instance (a QoS Initiator or another QoS Controller). - QoS Receiver: Network entity, located at the edge of or inside a QoS domain, responsible for terminating an instance of an NSIS protocol. It has the additional functionality that it may initiate an acknowledgment towards the QI and that it may trigger another NSIS entity (QoS Initiator or QoS Controller of another instance of the NSIS protocol) - QoS Initiator: Network entity, located at the edge of or inside a QoS domain, responsible for initiating an instance of an NSIS QoS signaling protocol. It may be triggered by the application layer, by the termination of a local QoS signaling mechanism (possibly another instance of NSIS signaling) or by a QoS Controller of another of a client instance of an NSIS protocol. It provides a mapping between the QoS parameters contained in the trigger and the QoS parameters in the instance of the NSIS protocol for which is serves as QoS Initiator. 2. Use cases/scenarios: 2 are available from the draft-buchli (sections 4.1 and 4.2) 3. Requirements * New requirements - in section MUST support priority The priority of a flow is essentially decoupled from its QoS requirements. Therefore the protocol MUST support priority. As a consequence, it MUST support preemption of traffic flows in case of congestion or failure. A preemption action MAY trigger an attempt to resetup the request by means of another instance of an NSIS signaling protocol. - in section 5.3: MAY support grouping of microflows (possibly only for feedback) As a consequence of the optimization for the interactive multimedia services, the signaling should allow one unique request for several micro flows having the same origination and destination IP addresses. This is usually the case for multimedia SIP calls where the voice and video micro flows follow the same path. This grouping of requests allows optimization of the QoS processing. Note that this may be detrimental for the call setup time. The use of grouping for microflows may be restricted to teardown and/or notification messages when call setup time is a concern. - in section 5.5: Protocol content The per-flow QoS requests are mapped onto the bandwidth pipe, which is specified by an SLS. These pipes may provide statistical guarantees such as delay and packet loss bounds (depending on the QoS class). In order to invoke per-flow QoS services the only parameter needed is a required rate, a means to identify the data path (mapping on SLS) and eventually a reservation identifier. 1) Microflow/reservation description The signaling should allow the request to describe the microflow whose QoS would be guaranteed by giving at least the source and destination IP addresses of the media flow. In case the QC is stateful (per microflow) there may be a need to include a unique reservation identifier (e.g. QI identifier+counter) such that in case of e.g. a tear down message the reservation can be easily identified in the QC. 2) Traffic descriptor The required peak rate must be signaled. Optionally the traffic parameters may be expressed in terms of token bucket parameters (similar to the TSpec in RSVP). - in section 5.10: Interworking with provisioning * Requirements for which to change priority or formulation - MUST support signalling to entities outside the data path (reformulation) - MUST NOT be adversely impacted by mobility aspects (applicable for end-to-end) A QoS controller in an end-to-end instance of an NSIS protocol MUST NOT be adversely affected by mobility issues. Any mobility scenario should be tackled by other uses of an NSIS protocol and is outside the realm of an end-to-end application of the NSIS protocol. _________________________________________________________________ Download MSN Explorer gratis van http://explorer.msn.nl/intl.asp. _______________________________________________ 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 daemon@optimus.ietf.org Tue Apr 9 07:07:23 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01793 for ; Tue, 9 Apr 2002 07:07:18 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA10053 for nsis-archive@odin.ietf.org; Tue, 9 Apr 2002 07:07:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA09795; Tue, 9 Apr 2002 07:01:36 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA09752 for ; Tue, 9 Apr 2002 07:01:32 -0400 (EDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01722 for ; Tue, 9 Apr 2002 07:01:29 -0400 (EDT) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g39B1Is7019844 for ; Tue, 9 Apr 2002 13:01:18 +0200 (MEST) Received: FROM esealnt746.al.sw.ericsson.se BY esealnt461 ; Tue Apr 09 12:59:20 2002 +0200 Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 9 Apr 2002 12:59:20 +0200 Message-ID: <18A375D0D9974F41B8A10F193CA83E490AD6B4@enleent102.nl.eu.ericsson.se> From: "Georgios Karagiannis (ELN)" To: "'Anders.P.Bergsten@telia.se'" , nsis@ietf.org Cc: brunner@ccrle.nec.de Subject: RE: [NSIS] proposal to add requirement text Date: Tue, 9 Apr 2002 12:59:14 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi Anders Sorry for the delay on sending this reply. Regarding your proposal on scalability. Actually I agree, but I would very much appreciate if you could change the following sentence: " to constrain the load (CPU load, memory space, signaling bandwidth consumption and signaling intensity) on devices .." into: " to constrain the load (CPU load, memory space, signaling bandwidth consumption and signaling intensity) and the number of reservation states on devices .." Best Regards, Georgios -----Original Message----- From: Anders.P.Bergsten@telia.se [mailto:Anders.P.Bergsten@telia.se] Sent: donderdag 21 maart 2002 23:52 To: nsis@ietf.org Cc: brunner@ccrle.nec.de Subject: [NSIS] proposal to add requirement text All, off line discussions revealed that the scalability sections (5.6) could be slightly updated. I suggest wording along these lines: The nsis architecture should give the ability to constrain the load (CPU load, memory space, signaling bandwidth consumption and signaling intensity) on devices where it is needed. This can be achieved by many different methods, for example message aggregation, by ignoring signaling message, header compression or minimizing functionality. The architecture may choose any of these methods as long as the requirement is met. (the reasoning behind the words are the following, if I have the ability to control the load the protocol(s) generate in a singel device, the protocol will "scale". And the words does not mandate any particular solution) A related requirement that was discussed was transport quality for the signaling protocol where I propose the following text. The nsis architecture should allow the network operator to assign the nsis protocol messages a certain transport quality. As signaling opens up for possible denial-of-service attacks, this requirement gives the network operator a mean, but also the obligation, to trade-off between signaling latency and the impact (from the signaling messages) on devices within his/her network. From protocol design this requirement states that the protocol messages should be detectable, at least where the control and assignment of the messages priority is done. Anders _______________________________________________ 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 daemon@optimus.ietf.org Tue Apr 9 10:05:59 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05870 for ; Tue, 9 Apr 2002 10:05:59 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA21777 for nsis-archive@odin.ietf.org; Tue, 9 Apr 2002 10:06:00 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA21459; Tue, 9 Apr 2002 10:02:40 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA21407 for ; Tue, 9 Apr 2002 10:02:37 -0400 (EDT) Received: from idcpa4.pa.interdigital.com (idcmail.interdigital.com [12.32.197.142]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05763 for ; Tue, 9 Apr 2002 10:02:35 -0400 (EDT) Received: by idcpa4.interdigital.com with Internet Mail Service (5.5.2653.19) id <2S8311X7>; Tue, 9 Apr 2002 10:00:52 -0400 Message-ID: From: "Shahrier, Sharif M." To: "Shahrier, Sharif M." Cc: nsis@ietf.org Subject: [NSIS] Establishment of RSVP parameters for RSVP Date: Tue, 9 Apr 2002 10:00:51 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org The determination of RSVP parameters to achieve the requested QoS is the task of the QoS control devices. It is my impression that how these parameters are derived are out of scope for NSIS? Is this true? Also, can someone please explain where the entities QoS Controller and QoS Initiator are located with respect to RSVP protocol. I.e. are they only at the edge of the network, or are they to be present at every RSVP node along the transmission path? Sharif. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Tue Apr 9 10:13:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06125 for ; Tue, 9 Apr 2002 10:13:08 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA22204 for nsis-archive@odin.ietf.org; Tue, 9 Apr 2002 10:13:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA21887; Tue, 9 Apr 2002 10:07:44 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA21857 for ; Tue, 9 Apr 2002 10:07:42 -0400 (EDT) Received: from rsys000a.roke.co.uk (rsys000a.roke.co.uk [193.118.201.102]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA05968 for ; Tue, 9 Apr 2002 10:07:38 -0400 (EDT) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Tue, 9 Apr 2002 15:06:25 +0100 Message-ID: <76C92FBBFB58D411AE760090271ED4181EA22D@rsys002a.roke.co.uk> From: "Hancock, Robert" To: nsis@ietf.org Date: Tue, 9 Apr 2002 15:06:17 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Subject: [NSIS] attempted summary of pre-emption thread Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; charset="iso-8859-1" dear all, well, this is quite a thread to come back from a short holiday to. I attempt to make a summary (partly for my own benefit): ================== 1. pre-emption (let's call it 'session pre-emption'?) is a useful and sometimes mandatory capability within networks (examples: emergency call handling; operation after capacity loss e.g. due to partial network failure). 2. only the network can decide what sessions to pre-empt in favour of what other sessions. 3. QoS signalling has to carry enough information to enable the network to make this decision (and that information might have to be authenticated or otherwise processed to classify the session securely); however, this information does not need to be visible to the signalling protocol. 4. if a session is pre-empted, the network might (should?) want to tell affected users that their QoS has been degraded. ================== If this is complete, the implications for NSIS would seem to be: A) from (3), the QoS data carried has to include particular information - but since this is opaque to us anyway, there is no new requirement here. B) in support of (4), the signalling protocol has to be able to send an asynchronous message about a QoS change - but I think we also have this already (for other reasons). So, no new requirements. But maybe some more pointers about how important (B) is and where in the network. (But note: (B) isn't needed to support pre-emption, it's just a side effect of doing pre-emption, so maybe the added significance is not great.) I've thought hard in the past but can't think of any new requirements for NSIS from this topic. I'd be interested to see any. If this method of reasoning is useful, maybe it is helpful to capture it in the requirements appendix as a scenario ("here's how a pre-emption event is handled and what NSIS capabilities are used to do so"), or is that a framework issue? robert h. now to the handover one ... --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; name="RMRL-Disclaimer.txt" Content-Disposition: attachment; filename="RMRL-Disclaimer.txt" Content-Transfer-Encoding: 7bit The information contained in this e-mail and any attachments is confidential to Roke Manor Research Ltd and must not be passed to any third party without permission. This communication is for information only and shall not create or change any contractual relationship. --------------InterScan_NT_MIME_Boundary-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Tue Apr 9 13:23:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12868 for ; Tue, 9 Apr 2002 13:23:49 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA06025 for nsis-archive@odin.ietf.org; Tue, 9 Apr 2002 13:23:50 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA05138; Tue, 9 Apr 2002 13:08:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA05103 for ; Tue, 9 Apr 2002 13:08:05 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12311 for ; Tue, 9 Apr 2002 13:08:03 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g39H7Wg29916; Tue, 9 Apr 2002 13:07:32 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 9 Apr 2002 13:07:32 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4A00@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Hancock, Robert'" , nsis@ietf.org Subject: RE: [NSIS] attempted summary of pre-emption thread Date: Tue, 9 Apr 2002 13:07:29 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DFE9.0796D406" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1DFE9.0796D406 Content-Type: text/plain; charset="iso-8859-1" Robert: As a follow up: it is my understanding that IEPREP (and GETS) is targeting non-pre-emptive support for emergency traffic. Perhaps someone on this list active the IEPREP can expand upon (or correct) this requirement. I did a quick scan of the IEPREP wg drafts, and although there are discussions of QoS requirements, only one discussion pre-emption and then, only as an option. Regardless, the Diff Serv working group is considering extensions to the current definitions of the code space (I cannot comment, however, on what the consensus is). If there is a need to add pre-emption as one of the forwarding services provided to a traffic flow, then the proposal should be made to the Diff Serv wg. Regards, Gary > -----Original Message----- > From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] > Sent: April 9, 2002 10:06 > To: nsis@ietf.org > Subject: [NSIS] attempted summary of pre-emption thread > > > dear all, > > well, this is quite a thread to come back from a short holiday to. > I attempt to make a summary (partly for my own benefit): > > ================== > 1. pre-emption (let's call it 'session pre-emption'?) is a > useful and sometimes mandatory capability within networks > (examples: emergency call handling; operation after capacity > loss e.g. due to partial network failure). > > 2. only the network can decide what sessions to pre-empt in > favour of what other sessions. > > 3. QoS signalling has to carry enough information to enable > the network to make this decision (and that information might > have to be authenticated or otherwise processed to classify > the session securely); however, this information does not > need to be visible to the signalling protocol. > > 4. if a session is pre-empted, the network might (should?) > want to tell affected users that their QoS has been degraded. > ================== > > If this is complete, the implications for NSIS would seem to be: > A) from (3), the QoS data carried has to include particular > information - but since this is opaque to us anyway, there is > no new requirement here. > B) in support of (4), the signalling protocol has to be able > to send an asynchronous message about a QoS change - but I > think we also have this already (for other reasons). > > So, no new requirements. But maybe some more pointers about > how important (B) is and where in the network. (But note: (B) > isn't needed to support pre-emption, it's just a side effect > of doing pre-emption, so maybe the added significance is not great.) > > I've thought hard in the past but can't think of any new > requirements for NSIS from this topic. I'd be interested to see any. > If this method of reasoning is useful, maybe it is helpful to > capture it in the requirements appendix as a scenario > ("here's how a pre-emption event is handled and what NSIS > capabilities are used to do so"), or is that a framework issue? > > robert h. > now to the handover one ... > ------_=_NextPart_001_01C1DFE9.0796D406 Content-Type: text/html; charset="iso-8859-1" RE: [NSIS] attempted summary of pre-emption thread

Robert:

  As a follow up: it is my understanding that IEPREP (and GETS)
is targeting non-pre-emptive support for emergency traffic.
Perhaps someone on this list active the IEPREP can expand upon (or correct)
this requirement. I did a quick scan of the IEPREP wg drafts, and although
there are discussions of QoS requirements, only one discussion pre-emption
and then, only as an option.

  Regardless, the Diff Serv working group is considering extensions
to the current definitions of the code space (I cannot comment, however,
on what the consensus is). If there is a need to add pre-emption as one
of the forwarding services provided to a traffic flow, then the proposal
should be made to the Diff Serv wg.

Regards,
Gary

> -----Original Message-----
> From: Hancock, Robert [mailto:robert.hancock@roke.co.uk]
> Sent: April 9, 2002 10:06
> To: nsis@ietf.org
> Subject: [NSIS] attempted summary of pre-emption thread
>
>
> dear all,
>
> well, this is quite a thread to come back from a short holiday to.
> I attempt to make a summary (partly for my own benefit):
>
> ==================
> 1. pre-emption (let's call it 'session pre-emption'?) is a
> useful and sometimes mandatory capability within networks
> (examples: emergency call handling; operation after capacity
> loss e.g. due to partial network failure).
>
> 2. only the network can decide what sessions to pre-empt in
> favour of what other sessions.
>
> 3. QoS signalling has to carry enough information to enable
> the network to make this decision (and that information might
> have to be authenticated or otherwise processed to classify
> the session securely); however, this information does not
> need to be visible to the signalling protocol.
>
> 4. if a session is pre-empted, the network might (should?)
> want to tell affected users that their QoS has been degraded.
> ==================
>
> If this is complete, the implications for NSIS would seem to be:
> A) from (3), the QoS data carried has to include particular
> information - but since this is opaque to us anyway, there is
> no new requirement here.
> B) in support of (4), the signalling protocol has to be able
> to send an asynchronous message about a QoS change - but I
> think we also have this already (for other reasons).
>
> So, no new requirements. But maybe some more pointers about
> how important (B) is and where in the network. (But note: (B)
> isn't needed to support pre-emption, it's just a side effect
> of doing pre-emption, so maybe the added significance is not great.)
>
> I've thought hard in the past but can't think of any new
> requirements for NSIS from this topic. I'd be interested to see any.
> If this method of reasoning is useful, maybe it is helpful to
> capture it in the requirements appendix as a scenario
> ("here's how a pre-emption event is handled and what NSIS
> capabilities are used to do so"), or is that a framework issue?
>
> robert h.
> now to the handover one ...
>

------_=_NextPart_001_01C1DFE9.0796D406-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Tue Apr 9 14:03:53 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14456 for ; Tue, 9 Apr 2002 14:03:53 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA09334 for nsis-archive@odin.ietf.org; Tue, 9 Apr 2002 14:03:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA08432; Tue, 9 Apr 2002 13:56:46 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA08368 for ; Tue, 9 Apr 2002 13:56:41 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14248; Tue, 9 Apr 2002 13:56:38 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g39Htog03427; Tue, 9 Apr 2002 13:55:50 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 9 Apr 2002 13:55:50 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4A01@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Charles E. Perkins'" Cc: "'nsis@ietf.org'" , seamoby@ietf.org Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Tue, 9 Apr 2002 13:55:49 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DFEF.C7DF5688" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1DFEF.C7DF5688 Content-Type: text/plain; charset="iso-8859-1" Charlie: Thanks for the $0.02. Some comments/questions: > -----Original Message----- > From: Charles E. Perkins [mailto:charliep@iprg.nokia.com] > Sent: April 8, 2002 17:58 > To: Kenward, Gary [WDLN2:AN10:EXCH] > Cc: nsis@ietf.org; seamoby@ietf.org > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > Hello Gary, > > I have $0.02 to add to the discussion: > > > Can anyone offer an explaining of how or why CT would add > significantly > > to the already unreliable physics of handover? > > Since I took physics in college, I can answer this. It would not > add significantly to handover unreliability. Then why should we worry about it? The ultimate question is, given that you detect a failure, can you make a significant improvement on the handover performance? > > > What failure modes for CT would be noticeable above the unavoidable > > rate of handover failures due the vagaries of wireless coverage and > > wireless link layer performance???? > > Congestion at intermediate routing points comes to mind. > Just because two access points are both within range of a mobile node > does not mean that they are neighbors to each other. They may even > be attached to completely different physical media. Could you not avoid this with traffic engineering? It would seem to me to be a bad choice, regardless, to throw your CT traffic in with your BE traffic. The impact on delay of transfer alone would be enough reason to provide special treatment for CT. And, if the CT is failing because of congestion, why would any signalling messages indicating failure and attempting recovery not also be congested? > > > If CT fails, then the handover fails. It is that simple. If CT were > > to fail with every 2nd handover attempt, then there would > be a problem. > > I quite disagree with this statement. It depends on very many things. > For instance, we have to be able to run CT without CARD. So, the > destination access router might not offer header compression at all, > for instance. Thus, the handover would succeed, but the > context transfer > (or, part of it) would fail. Ok. I wasn't clear. I did not mean to imply that all handovers require CT. I meant that if a handover of a flow requires context to work, and the CT fails, then the flow handover fails. Since this is, as you agree, a rare event insignificant amongst all the other reasons handovers fail, why worry about it? > > > But, I cannot seriously see CT failing more then every one > in a million > > handover attempts, or less. > > Cool! This could be good news. I am as nervous as anyone in pushing requirements onto the people who engineer a working network. There job is hard enough. However, I just do not see running signalling and signalling related traffic such as CT, through the same congested paths as BE traffic. Even for wireless ad-hoc networks, I would presume that there will be a need identified for some special traffic treatment over the air to facilitate signalling between nodes. > > > CT should not be attempted if there is an incompatibility > between source > > and destination ARs. > > As noted above, I quite disagree with this statement. I don't see the relationship between your disagreement and your notes above. If CARD is present, then the network should know ahead of time what the capabilities of a target router are, and what mitigating action needs to be taken to effect a useful CT. If CARD is not present, then the solution is to configure the network appropriately. This may include facilities at ARs for context translation ("may" - I think this is getting ahead of the current state of the art). The only other scenario I can think of is where the network configuration is dynamic, and thus the capabilities of the ARs can change dynamically. This is one reason why I mentioned wireless ad-hoc networks. It is not clear to me that we should be attempting to solve this very complex problem within SEAMOBY, as there are any number of assumptions that must be made to make the problem tractable. > > > And, I HAD thought that it was the > purpose of CAR > > to identify those incompatibilities and thus avoid doing CT > when it is > > clear it would fail. > > But, we have to be allowed to do CT without ever running CARD. > For instance, we have reactive mode. Reactive mode does not mean no CARD. What you are suggesting is a collection of ARs with different capabilities, unknown during configuration time, and where CARD is not used. I would propose that this is an unrealistic scenario. Said another way, I propose that if the capabilities of the ARs are known and unchanging, the network can be engineered for CT without CARD to work. Note that this statement applies to wireless ad-hoc networks and mobile ARs as well as fixed, wired ARs. If the capabilities of the ARs at the time of a handover are not pre-determinable, then I suggest that this is where CARD is used with the greatest import. Any other scenarios can be deemed poor network engineering practice. > > > How to mitigate those incompatibles is not a > > CT issue, it is a service adaptation issue, which can be resolved in > > a number of ways, some of which would imply signalled > negotiation either > > between the ARs or between the ARs and the MN. > > Sometimes, the service cannot be adapted, and the feature context is > just plain lost, because the feature is unavailable. > Suppose, for example, > that the contexts transferred include header compression, > QoS, security, > and other features. Now suppose that _only_ the security > context can be > transferred. That's still better than nothing! Maybe the > QoS application > will have to terminate, or go into degraded mode, but the > other applications > that need security will still be able to go on undisturbed. Why not? Sure, but what does this have to do with CT? There may be many reasons why a particular feature might fail, including malformed, missing or incompatible context. My position is this is not a ct issue, but rather an issue with the service entities themselves, which may mean the service entities perform some mitigating action, including informing the MN. Example: if the security context transfer fails, should a CT entity inform the MN, or should it be the responsibility of the security service entities? I think the latter. > > Regards, > Charlie P. > > PS. I relucantly left NSIS on the CC: list, but shouldn't it > be pruned? Perhaps. I haven't seen any complaints from NSIS as yet. I think some of us are trying to figure out what the respective roles of each protocol are and, most important, the inter-relationships. E.g. if QoS re-negotiation is to happen as a result of handover, in my view, it makes sense that we should use the capabilities of the NSIS protocol to do this re-negotiation, rather then replicate similar functionality in CARD or CT. The difficulty I suspect with this, is that none of the protocols exist yet, so it is hard for many of us to see what the trade-offs are. Perhaps the answer is to decide now where the divisions between the problem spaces (via requirements and objectives), and worry about trade-offs later. (Requirements drafts are not legal documents: they can be revised with sufficient reason.) Cheers, Gary > ------_=_NextPart_001_01C1DFEF.C7DF5688 Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff.

Charlie:

 Thanks for the $0.02. Some comments/questions:

> -----Original Message-----
> From: Charles E. Perkins [mailto:charliep@iprg.nokia.com]
> Sent: April 8, 2002 17:58
> To: Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: nsis@ietf.org; seamoby@ietf.org
> Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff.
>
>
>
> Hello Gary,
>
> I have $0.02 to add to the discussion:
>
> > Can anyone offer an explaining of how or why CT would add
> significantly
> > to the already unreliable physics of handover?
>
> Since I took physics in college, I can answer this.  It would not
> add significantly to handover unreliability.

Then why should we worry about it? The ultimate question is, given
that you detect a failure, can you make a significant improvement
on the handover performance?

>
> > What failure modes for CT would be noticeable above the unavoidable
> > rate of handover failures due the vagaries of wireless coverage and
> > wireless link layer performance????
>
> Congestion at intermediate routing points comes to mind.
> Just because two access points are both within range of a mobile node
> does not mean that they are neighbors to each other.  They may even
> be attached to completely different physical media.

Could you not avoid this with traffic engineering? It would seem to me
to be a bad choice, regardless, to throw your CT traffic in with your
BE traffic. The impact on delay of transfer alone would be enough reason
to provide special treatment for CT. And, if the CT is failing because
of congestion, why would any signalling messages indicating failure and
attempting recovery not also be congested?

>
> > If CT fails, then the handover fails. It is that simple. If CT were
> > to fail with every 2nd handover attempt, then there would
> be a problem.
>
> I quite disagree with this statement.  It depends on very many things.
> For instance, we have to be able to run CT without CARD.  So, the
> destination access router might not offer header compression at all,
> for instance.  Thus, the handover would succeed, but the
> context transfer
> (or, part of it) would fail.

Ok. I wasn't clear. I did not mean to imply that all handovers require CT.
I meant that if a handover of a flow requires context to work, and the
CT fails, then the flow handover fails. Since this is, as you agree, a
rare event insignificant amongst all the other reasons handovers fail,
why worry about it?

>
> > But, I cannot seriously see CT failing more then every one
> in a million
> > handover attempts, or less.
>
> Cool!  This could be good news.

I am as nervous as anyone in pushing requirements onto the people
who engineer a working network. There job is hard enough. However,
I just do not see running signalling and signalling related traffic
such as CT, through the same congested paths as BE traffic. Even for
wireless ad-hoc networks, I would presume that there will be a need
identified for some special traffic treatment over the air to facilitate
signalling between nodes.

>
> > CT should not be attempted if there is an incompatibility
> between source
> > and destination ARs.
>
> As noted above, I quite disagree with this statement.

I don't see the relationship between your disagreement and
your notes above.

If CARD is present, then the network should know ahead of time
what the capabilities of a target router are, and what mitigating
action needs to be taken to effect a useful CT.

If CARD is not present, then the solution is to configure the
network appropriately. This may include facilities at ARs
for context translation ("may" - I think this is getting ahead
of the current state of the art).

The only other scenario I can think of is where the network configuration
is dynamic, and thus the capabilities of the ARs can change dynamically.
This is one reason why I mentioned wireless ad-hoc networks. It is not
clear to me that we should be attempting to solve this very complex
problem within SEAMOBY, as there are any number of assumptions that
must be made to make the problem tractable.

>
> >                       And, I HAD thought that it was the
> purpose of CAR
> > to identify those incompatibilities and thus avoid doing CT
> when it is
> > clear it would fail.
>
> But, we have to be allowed to do CT without ever running CARD.
> For instance, we have reactive mode.

Reactive mode does not mean no CARD.

What you are suggesting is a collection of ARs with different capabilities,
unknown during configuration time, and where CARD is not used. I would propose
that this is an unrealistic scenario.

Said another way, I propose that if the capabilities of the ARs are known
and unchanging, the network can be engineered for CT without CARD to work.
Note that this statement applies to wireless ad-hoc networks and mobile
ARs as well as fixed, wired ARs.

If the capabilities of the ARs at the time of a handover are not pre-determinable,
then I suggest that this is where CARD is used with the greatest import.

Any other scenarios can be deemed poor network engineering practice.

>
> >                        How to mitigate those incompatibles is not a
> > CT issue, it is a service adaptation issue, which can be resolved in
> > a number of ways, some of which would imply signalled
> negotiation either
> > between the ARs or between the ARs and the MN.
>
> Sometimes, the service cannot be adapted, and the feature context is
> just plain lost, because the feature is unavailable. 
> Suppose, for example,
> that the contexts transferred include header compression,
> QoS, security,
> and other features.  Now suppose that _only_ the security
> context can be
> transferred.  That's still better than nothing!  Maybe the
> QoS application
> will have to terminate, or go into degraded mode, but the
> other applications
> that need security will still be able to go on undisturbed.  Why not?

Sure, but what does this have to do with CT? There may be many reasons
why a particular feature might fail, including malformed, missing or
incompatible context. My position is this is not a ct issue, but rather
an issue with the service entities themselves, which may mean the service
entities perform some mitigating action, including informing the MN.

Example: if the security context transfer fails, should a CT entity inform
the MN, or should it be the responsibility of the security service entities?
I think the latter.

>
> Regards,
> Charlie P.
>
> PS. I relucantly left NSIS on the CC: list, but shouldn't it
> be pruned?

Perhaps. I haven't seen any complaints from NSIS as yet. I think some of
us are trying to figure out what the respective roles of each protocol are
and, most important, the inter-relationships. E.g. if QoS re-negotiation is
to happen as a result of handover, in my view, it makes sense that we should
use the capabilities of the NSIS protocol to do this re-negotiation, rather
then replicate similar functionality in CARD or CT. The difficulty I suspect
with this, is that none of the protocols exist yet, so it is hard for many
of us to see what the trade-offs are.

Perhaps the answer is to decide now where the divisions between the problem
spaces (via requirements and objectives), and worry about trade-offs later.
(Requirements drafts are not legal documents: they can be revised with sufficient
reason.)

Cheers,
Gary
>

------_=_NextPart_001_01C1DFEF.C7DF5688-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Tue Apr 9 14:33:23 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15847 for ; Tue, 9 Apr 2002 14:33:23 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA11834 for nsis-archive@odin.ietf.org; Tue, 9 Apr 2002 14:33:25 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA10317; Tue, 9 Apr 2002 14:17:12 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA10198 for ; Tue, 9 Apr 2002 14:17:04 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15102; Tue, 9 Apr 2002 14:17:01 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g39ICPq26994; Tue, 9 Apr 2002 14:12:25 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 9 Apr 2002 14:12:26 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4A04@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Phil Neumiller'" , Rajeev Koodli Cc: Nakhjiri Madjid-MNAKHJI1 , Hemant.Chaskar@nokia.com, nsis@ietf.org, seamoby@ietf.org Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Tue, 9 Apr 2002 14:12:20 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DFF1.FD0BA71A" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1DFF1.FD0BA71A Content-Type: text/plain; charset="iso-8859-1" Phil: > -----Original Message----- > From: Phil Neumiller [mailto:pneumiller@directvinternet.com] *snip* > > Yes, stay connected to multiple ARs. You will need it anyway for > log normal shadow fading in outdoor environments. People on this > list don't realize that frequencies are going up and these things will > deployed > outdoors where shadow fading is the killer. Its not going to Don't forget the pain of rain! > be one big > cell > after another. Its going to be connections two or three > crappy cells and > making the best use of them. > > > ------_=_NextPart_001_01C1DFF1.FD0BA71A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff.

Phil:

> -----Original Message-----
> From: Phil Neumiller [mailto:pneumiller@directv= internet.com]

*snip*

>
> Yes, stay connected to multiple ARs.  You = will need it anyway for
> log normal shadow fading in outdoor = environments.  People on this
> list don't realize that frequencies are going = up and these things will
> deployed
> outdoors where shadow fading is the = killer.  Its not going to

Don't forget the pain of rain!

> be one big
> cell
> after another.  Its going to be = connections two or three
> crappy cells and
> making the best use of them.
>
>
>

------_=_NextPart_001_01C1DFF1.FD0BA71A-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Tue Apr 9 14:47:09 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16626 for ; Tue, 9 Apr 2002 14:47:09 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA12583 for nsis-archive@odin.ietf.org; Tue, 9 Apr 2002 14:47:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA11588; Tue, 9 Apr 2002 14:31:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA11527 for ; Tue, 9 Apr 2002 14:31:46 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15737; Tue, 9 Apr 2002 14:31:43 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g39IUug06268; Tue, 9 Apr 2002 14:30:56 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 9 Apr 2002 14:30:56 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4A06@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'James Kempf'" , "'Rajeev Koodli'" , Nakhjiri Madjid-MNAKHJI1 Cc: Hemant.Chaskar@nokia.com, nsis@ietf.org, seamoby@ietf.org Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Tue, 9 Apr 2002 14:30:51 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DFF3.BEDD7138" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1DFF3.BEDD7138 Content-Type: text/plain; charset="iso-8859-1" James: Sorry, but I am a bit confused (as usual), are you saying then that doing these functions with the CT protocol is less heavyweight, and thus preferable? The default action, always, is for the session to be dropped. This will ultimately force the MN to take action (oh, ok, some MNs will simply halt and catch fire). Anything more then dropping the session is simply to improve the handover performance under various conditions. Typically, when one gets into exception scenarios, the solutions become too complex or degrade performance too much to be justified against the potential gains. A classic example is run time type/value checking in C/C++. If there are no recovery mechanisms for the potential faults you describe, then does it make sense to build one into CT? On the other hand, if these mechanisms are built into the handover algorithm, or into the session support, then putting it into CT would be redundant, would it not? Gary > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: April 8, 2002 21:12 > To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Rajeev Koodli'; Nakhjiri > Madjid-MNAKHJI1 > Cc: Hemant.Chaskar@nokia.com; nsis@ietf.org; seamoby@ietf.org > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > Gary, > > When you say "handover failure" I think Mobile IP, and there > is already > some signaling available in FMIPv6/BETH to do this. This > signaling does > not extend to attributes of the IP service like whether or not the MN > can connect to the network, what class of QoS service it gets, and any > other security, etc.. There is currently no way to signal that the > network expects the MN to reestablish these, except to say that the MN > has entered a new AAA domain and should therefore perform > network entry > from scratch. This seems a little too heavyweight to me. > > jak > > ----- Original Message ----- > From: "Gary Kenward" > To: "'James Kempf'" ; "'Rajeev Koodli'" > ; "Nakhjiri Madjid-MNAKHJI1" > > Cc: ; ; > Sent: Monday, April 08, 2002 1:21 PM > Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > James: > > > > > -----Original Message----- > > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > > Sent: April 8, 2002 15:55 > > > To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Rajeev Koodli'; Nakhjiri > > > Madjid-MNAKHJI1 > > > Cc: Hemant.Chaskar@nokia.com; nsis@ietf.org; seamoby@ietf.org > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > As I outlined in one of my other posts, why would you > > > perform CT to an > > > > AR that did not have the necessary capabilities. Is > this actually > > > about > > > > CAR failure?? > > > > > > > > > > Yes and no. > > > > > > Suppose the MN is expecting CT to be performed and it is not > > > because the > > > > A nit, but the MN does not expect CT. The MN expects continuous > > service (i.e. seamless service), and knows nothing about how it is > > supported (it could be provisioned). > > > > > new AR can't interpret the context. > > > The old AR may discover this via CAR, but if there is no way to > > > communicate it to the MN, then the MN can't know to perform the > > > signaling from scratch on the new AR. One could either inform the > MN > > > beforehand to do the signaling, as is done with FMIPv6/BETH, or > signal > > > the MN on the new AR. > > > > > > For dynamic failures, such as when the AR runs out of Gold Class > > > service, the signaling could only be done afterwards. > > > > I understand these scenarios, but I do not understand what they have > > to do with CT. CT has never intended to be an MN signalling > protocol. > > Let me try a counter example: the service authorization fails. Would > > a CT message saying the AA context transfer failed be of much use > > to the MN? No, because the problem wasn't with the context, it was > with > > a disconnect between the service request and authorization > profile for > > that MN. > > > > There is a need for a "handover failure" indication message to the > > MN (indicating full or partial handover failure), but this message > should > > be part of a different protocol from CT. > > > > Gary > > > > > > > > jak > > > > > > ------_=_NextPart_001_01C1DFF3.BEDD7138 Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff.

James:

  Sorry, but I am a bit confused (as usual), are you saying
then that doing these functions with the CT protocol is less
heavyweight, and thus preferable?

  The default action, always, is for the session to be dropped.
This will ultimately force the MN to take action (oh, ok, some
MNs will simply halt and catch fire). Anything more then dropping
the session is simply to improve the handover performance under
various conditions. Typically, when one gets into exception scenarios,
the solutions become too complex or degrade performance too much
to be justified against the potential gains. A classic example is
run time type/value checking in C/C++.

  If there are no recovery mechanisms for the potential faults
you describe, then does it make sense to build one into CT?
On the other hand, if these mechanisms are built into the handover
algorithm, or into the session support, then putting it into CT
would be redundant, would it not?

Gary

> -----Original Message-----
> From: James Kempf [mailto:kempf@docomolabs-usa.com]
> Sent: April 8, 2002 21:12
> To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Rajeev Koodli'; Nakhjiri
> Madjid-MNAKHJI1
> Cc: Hemant.Chaskar@nokia.com; nsis@ietf.org; seamoby@ietf.org
> Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff.
>
>
> Gary,
>
> When you say "handover failure" I think Mobile IP, and there
> is already
> some signaling available in FMIPv6/BETH to do this. This
> signaling does
> not extend to attributes of the IP service like whether or not the MN
> can connect to the network, what class of QoS service it gets, and any
> other security, etc.. There is currently no way to signal that the
> network expects the MN to reestablish these, except to say that the MN
> has entered a new AAA domain and should therefore perform
> network entry
> from scratch. This seems a little too heavyweight to me.
>
>             jak
>
> ----- Original Message -----
> From: "Gary Kenward" <gkenward@nortelnetworks.com>
> To: "'James Kempf'" <kempf@docomolabs-usa.com>; "'Rajeev Koodli'"
> <rajeev@iprg.nokia.com>; "Nakhjiri Madjid-MNAKHJI1"
> <Madjid.Nakhjiri@motorola.com>
> Cc: <Hemant.Chaskar@nokia.com>; <nsis@ietf.org>; <seamoby@ietf.org>
> Sent: Monday, April 08, 2002 1:21 PM
> Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff.
>
>
> > James:
> >
> > > -----Original Message-----
> > > From: James Kempf [mailto:kempf@docomolabs-usa.com]
> > > Sent: April 8, 2002 15:55
> > > To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Rajeev Koodli'; Nakhjiri
> > > Madjid-MNAKHJI1
> > > Cc: Hemant.Chaskar@nokia.com; nsis@ietf.org; seamoby@ietf.org
> > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff.
> > >
> > >
> > >
> > > > As I outlined in one of my other posts, why would you
> > > perform CT to an
> > > > AR that did not have the necessary capabilities. Is
> this actually
> > > about
> > > > CAR failure??
> > > >
> > >
> > > Yes and no.
> > >
> > > Suppose the MN is expecting CT to be performed and it is not
> > > because the
> >
> > A nit, but the MN does not expect CT. The MN expects continuous
> > service (i.e. seamless service), and knows nothing about how it is
> > supported (it could be provisioned).
> >
> > > new AR can't interpret the context.
> > > The old AR may discover this via CAR, but if there is no way to
> > > communicate it to the MN, then the MN can't know to perform the
> > > signaling from scratch on the new AR.  One could either inform the
> MN
> > > beforehand to do the signaling, as is done with FMIPv6/BETH, or
> signal
> > > the MN on the new AR.
> > >
> > > For dynamic failures, such as when the AR runs out of Gold Class
> > > service, the signaling could only be done afterwards.
> >
> > I understand these scenarios, but I do not understand what they have
> > to do with CT. CT has never intended to be an MN signalling
> protocol.
> > Let me try a counter example: the service authorization fails. Would
> > a CT message saying the AA context transfer failed be of much use
> > to the MN? No, because the problem wasn't with the context, it was
> with
> > a disconnect between the service request and authorization
> profile for
> > that MN.
> >
> > There is a need for a "handover failure" indication message to the
> > MN (indicating full or partial handover failure), but this message
> should
> > be part of a different protocol from CT.
> >
> > Gary
> >
> > >
> > >             jak
> > >
> >
>

------_=_NextPart_001_01C1DFF3.BEDD7138-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Tue Apr 9 15:00:10 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17123 for ; Tue, 9 Apr 2002 15:00:09 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA13067 for nsis-archive@odin.ietf.org; Tue, 9 Apr 2002 15:00:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA12753; Tue, 9 Apr 2002 14:52:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA12724 for ; Tue, 9 Apr 2002 14:52:01 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16787 for ; Tue, 9 Apr 2002 14:51:57 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g39IpBq29475; Tue, 9 Apr 2002 14:51:11 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 9 Apr 2002 14:51:12 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4A07@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'john.loughney@nokia.com'" , cedric@iprg.nokia.com Cc: Hemant.Chaskar@nokia.com, nsis@ietf.org Subject: RE: [NSIS] Establishing QoS after handoff. Date: Tue, 9 Apr 2002 14:51:08 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DFF7.828F7380" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1DFF7.828F7380 Content-Type: text/plain; charset="iso-8859-1" John: I don't think it as simple as saying that Seamoby focuses on handover. I agree that NSIS should not be "handover aware", however, (and this may be explicitly a seamoby issue), CT/CARD should not, in my view, be performing service re-negotiation. If for no other reason then the redundant functionality that is implied (and the difficulty in maintaining the two negotiation protocols). I will think about a draft, but I suspect it is premature/overkill. In my mind, the issue is about which entity controls the QoS offered to the MN, and is responsible for keeping the MN informed and reacting to it's requests. In my simple view, that's NSIS (and certainly NOT CT). The issue from an NSIS point of view, I guess, is what entity in the framework corresponds to a new AR that is having difficulty providing QoS support, and how does it invoke an action that includes notification of the MN? Gary > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: April 9, 2002 01:46 > To: Kenward, Gary [WDLN2:AN10:EXCH]; cedric@iprg.nokia.com > Cc: Hemant.Chaskar@nokia.com; nsis@ietf.org > Subject: RE: [NSIS] Establishing QoS after handoff. > > > Hi Gary, > > > I think that there is still confusion as to where CAR > leaves off and NSIS begins. > > If CAR does QoS negotiation, then will it not require much > of the same signalling > > semantics and syntax as the NSIS solution requires to > establish QoS? Is this > > redundancy necessary? > > As I have been suggesting, perhaps it would be good to > document these concerns > in an Internet Draft - emails can only go so far. > > > Also, while I keep thinking I that understand where CT ends > and CAR/NSIS begin, > > this think is constantly challenged by proposals such as > the one made recently > > to have CT signal service feature > incompatibilities/transfer failures. > > My personal opinion (in this area) is that SeaMoby works on > solutions that focus > on what happens in & during a handover between ARs and NSIS > is more focused on > the end-to-edge or end-to-end signaling path. > > John > ------_=_NextPart_001_01C1DFF7.828F7380 Content-Type: text/html; charset="iso-8859-1" RE: [NSIS] Establishing QoS after handoff.

John:

  I don't think it as simple as saying that Seamoby focuses on
handover. I agree that NSIS should not be "handover aware", however,
(and this may be explicitly a seamoby issue), CT/CARD should not,
in my view, be performing service re-negotiation. If for no other
reason then the redundant functionality that is implied (and the
difficulty in maintaining the two negotiation protocols).

  I will think about a draft, but I suspect it is premature/overkill.
In my mind, the issue is about which entity controls the QoS offered
to the MN, and is responsible for keeping the MN informed and reacting
to it's requests. In my simple view, that's NSIS (and certainly NOT
CT).

  The issue from an NSIS point of view, I guess, is what entity in
the framework corresponds to a new AR that is having difficulty providing
QoS support, and how does it invoke an action that includes notification
of the MN?

Gary

> -----Original Message-----
> From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]
> Sent: April 9, 2002 01:46
> To: Kenward, Gary [WDLN2:AN10:EXCH]; cedric@iprg.nokia.com
> Cc: Hemant.Chaskar@nokia.com; nsis@ietf.org
> Subject: RE: [NSIS] Establishing QoS after handoff.
>
>
> Hi Gary,
>
> > I think that there is still confusion as to where CAR
> leaves off and NSIS begins.
> > If CAR does QoS negotiation, then will it not require much
> of the same signalling
> > semantics and syntax as the NSIS solution requires to
> establish QoS? Is this
> > redundancy necessary?
>
> As I have been suggesting, perhaps it would be good to
> document these concerns
> in an Internet Draft - emails can only go so far.
>
> > Also, while I keep thinking I that understand where CT ends
> and CAR/NSIS begin,
> > this think is constantly challenged by proposals such as
> the one made recently
> > to have CT signal service feature
> incompatibilities/transfer failures.
>
> My personal opinion (in this area) is that SeaMoby works on
> solutions that focus
> on what happens in & during a handover between ARs and NSIS
> is more focused on
> the end-to-edge or end-to-end signaling path.
>
> John
>

------_=_NextPart_001_01C1DFF7.828F7380-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Tue Apr 9 15:14:44 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17635 for ; Tue, 9 Apr 2002 15:14:42 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA14210 for nsis-archive@odin.ietf.org; Tue, 9 Apr 2002 15:14:45 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA13961; Tue, 9 Apr 2002 15:09:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA13930 for ; Tue, 9 Apr 2002 15:09:52 -0400 (EDT) Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17421 for ; Tue, 9 Apr 2002 15:09:49 -0400 (EDT) Received: from JMPOLK-W2K (ssh-sjc-1.cisco.com [171.68.225.134]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id MAA04933; Tue, 9 Apr 2002 12:09:14 -0700 (PDT) Message-Id: <4.1.20020409134945.02d313e0@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Tue, 09 Apr 2002 14:09:13 -0500 To: "Hancock, Robert" , nsis@ietf.org From: "James M. Polk" Subject: Re: [NSIS] attempted summary of pre-emption thread In-Reply-To: <76C92FBBFB58D411AE760090271ED4181EA22D@rsys002a.roke.co.uk > Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_79237237==_.ALT" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org --=====================_79237237==_.ALT Content-Type: text/plain; charset="us-ascii" At 03:06 PM 4/9/2002 +0100, Hancock, Robert wrote: I'm confused by your conclusions. Let me quote you, but rearrange what you wrote to show this below. You stated 2 times that QOS information was necessary in the signaling: > >3. QoS signalling has to carry enough information to enable the network to >make this decision (and that information might have to be authenticated or >otherwise processed to classify the session securely); >If this is complete, the implications for NSIS would seem to be: >A) from (3), the QoS data carried has to include particular information - and that if preemption does occur, the "network" should tell someone: >4. if a session is pre-empted, the network might (should?) want to tell >affected users that their QoS has been degraded. >================== > yet state this information now *doesn't* need to be included here: >however, this >information does not need to be visible to the signalling protocol. > and conclude with "no new requirement" for preemption: >but since this is opaque to us anyway, there is no new requirement here. >So, no new requirements. > >I've thought hard in the past but can't think of any new requirements for >NSIS from this topic. I'd be interested to see any. Your logic within your email is flawed and poorly written, and doesn't support the conclusion you wrote. Please review what you wrote that I've highlighted above near the top and tell me how you stated that this information "~ ...has to include particular (identifying) information (for preemption to properly be performed)....", yet conclude that it "~...isn't needed....So, no new requirements." > >robert h. > Robert - you didn't read my email obviously as I stated many networks that have this capability that NSIS *won't* be an appropriate QOS mechanism for interfacing with if this is not included... ************************************* "People generally demand more respect for their own rights than they are willing to allow for others" James M. Polk Consulting Engineer Office of the CTO Cisco Systems 2200 East President George Bush Turnpike Richardson, TX 75082 USA w) 972.813.5208 f) 972.813.5280 www.cisco.com --=====================_79237237==_.ALT Content-Type: text/html; charset="us-ascii"
At 03:06 PM 4/9/2002 +0100, Hancock, Robert wrote:

I'm confused by your conclusions. Let me quote you, but rearrange what you wrote to show this below.

You stated 2 times that QOS information was necessary in the signaling:
>
>3. QoS signalling has to carry enough information to enable the network to
>make this decision (and that information might have to be authenticated or
>otherwise processed to classify the session securely);

>If this is complete, the implications for NSIS would seem to be:
>A) from (3), the QoS data carried has to include particular information -

and that if preemption does occur, the "network" should tell someone:

>4. if a session is pre-empted, the network might (should?) want to tell
>affected users that their QoS has been degraded.
>==================
>
yet state this information now *doesn't* need to be included here:

>however, this
>information does not need to be visible to the signalling protocol.
>

and conclude with "no new requirement" for preemption:

>but since this is opaque to us anyway, there is no new requirement here.

>So, no new requirements.
>
>I've thought hard in the past but can't think of any new requirements for
>NSIS from this topic. I'd be interested to see any.

Your logic within your email is flawed and poorly written, and doesn't support the conclusion you wrote. Please review what you wrote that I've highlighted above near the top and tell me how you stated that this information "~ ...has to include particular (identifying) information (for preemption to properly be performed)....", yet conclude that it "~...isn't needed....So, no new requirements."

>
>robert h.
>
Robert - you didn't read my email obviously as I stated many networks that have this capability that NSIS *won't* be an appropriate QOS mechanism for interfacing with if this is not included...



*************************************
"People generally demand more respect for their own rights than they are willing to allow for others"

James M. Polk
Consulting Engineer
Office of the CTO

Cisco Systems
2200 East President George Bush Turnpike
Richardson, TX  75082 USA
w) 972.813.5208
f)  972.813.5280
www.cisco.com --=====================_79237237==_.ALT-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Tue Apr 9 15:18:11 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17852 for ; Tue, 9 Apr 2002 15:18:11 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA14450 for nsis-archive@odin.ietf.org; Tue, 9 Apr 2002 15:18:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA13805; Tue, 9 Apr 2002 15:05:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA13729 for ; Tue, 9 Apr 2002 15:05:49 -0400 (EDT) Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17302 for ; Tue, 9 Apr 2002 15:05:46 -0400 (EDT) Received: from JMPOLK-W2K (ssh-sjc-1.cisco.com [171.68.225.134]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id LAA08220; Tue, 9 Apr 2002 11:49:32 -0700 (PDT) Message-Id: <4.1.20020409134502.02deeb00@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Tue, 09 Apr 2002 13:49:30 -0500 To: "Gary Kenward", "'Hancock, Robert'" , nsis@ietf.org From: "James M. Polk" Subject: RE: [NSIS] attempted summary of pre-emption thread In-Reply-To: <9FBD322B7824D511B36900508BF93C9C01AA4A00@zcard031.ca.norte l.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_78054816==_.ALT" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org --=====================_78054816==_.ALT Content-Type: text/plain; charset="us-ascii" At 01:07 PM 4/9/2002 -0400, Gary Kenward wrote: > > Robert: > > As a follow up: it is my understanding that IEPREP (and GETS) > is targeting non-pre-emptive support for emergency traffic. > Perhaps someone on this list active the IEPREP can expand upon (or correct) > this requirement. I did a quick scan of the IEPREP wg drafts, and although > there are discussions of QoS requirements, only one discussion pre-emption > and then, only as an option. I am involved within the IEPREP WG (spoke at the Minn meeting - and not about preemption) and preemption has been a topic of many long threads there. Preemption has been agreed upon to be optional in many networks, mandatory in others, while not_practiced or not_allowed in still others. As a result, preemption will be explicitly mentioned within that WG's Framework and Requirements IDs in future releases (both are only -00 now). > > Regardless, the Diff Serv working group is considering extensions > to the current definitions of the code space (I cannot comment, however, > on what the consensus is). If there is a need to add pre-emption as one > of the forwarding services provided to a traffic flow, then the proposal > should be made to the Diff Serv wg. > > Regards, > Gary > > > -----Original Message----- > > From: Hancock, Robert > [mailto:robert.hancock@roke.co.uk] > > Sent: April 9, 2002 10:06 > > To: nsis@ietf.org > > Subject: [NSIS] attempted summary of pre-emption thread > > > > > > dear all, > > > > well, this is quite a thread to come back from a short holiday to. > > I attempt to make a summary (partly for my own benefit): > > > > ================== > > 1. pre-emption (let's call it 'session pre-emption'?) is a > > useful and sometimes mandatory capability within networks > > (examples: emergency call handling; operation after capacity > > loss e.g. due to partial network failure). > > > > 2. only the network can decide what sessions to pre-empt in > > favour of what other sessions. > > > > 3. QoS signalling has to carry enough information to enable > > the network to make this decision (and that information might > > have to be authenticated or otherwise processed to classify > > the session securely); however, this information does not > > need to be visible to the signalling protocol. > > > > 4. if a session is pre-empted, the network might (should?) > > want to tell affected users that their QoS has been degraded. > > ================== > > > > If this is complete, the implications for NSIS would seem to be: > > A) from (3), the QoS data carried has to include particular > > information - but since this is opaque to us anyway, there is > > no new requirement here. > > B) in support of (4), the signalling protocol has to be able > > to send an asynchronous message about a QoS change - but I > > think we also have this already (for other reasons). > > > > So, no new requirements. But maybe some more pointers about > > how important (B) is and where in the network. (But note: (B) > > isn't needed to support pre-emption, it's just a side effect > > of doing pre-emption, so maybe the added significance is not great.) > > > > I've thought hard in the past but can't think of any new > > requirements for NSIS from this topic. I'd be interested to see any. > > If this method of reasoning is useful, maybe it is helpful to > > capture it in the requirements appendix as a scenario > > ("here's how a pre-emption event is handled and what NSIS > > capabilities are used to do so"), or is that a framework issue? > > > > robert h. > > now to the handover one ... > > ************************************* "People generally demand more respect for their own rights than they are willing to allow for others" James M. Polk Consulting Engineer Office of the CTO Cisco Systems 2200 East President George Bush Turnpike Richardson, TX 75082 USA w) 972.813.5208 f) 972.813.5280 www.cisco.com --=====================_78054816==_.ALT Content-Type: text/html; charset="us-ascii" At 01:07 PM 4/9/2002 -0400, Gary Kenward wrote:

Robert:

  As a follow up: it is my understanding that IEPREP (and GETS)
is targeting non-pre-emptive support for emergency traffic.
Perhaps someone on this list active the IEPREP can expand upon (or correct)
this requirement. I did a quick scan of the IEPREP wg drafts, and although
there are discussions of QoS requirements, only one discussion pre-emption
and then, only as an option.

I am involved within the IEPREP WG (spoke at the Minn meeting - and not about preemption) and preemption has been a topic of many long threads there. Preemption has been agreed upon to be optional in many networks, mandatory in others, while not_practiced or not_allowed in still others. As a result, preemption will be explicitly mentioned within that WG's Framework and Requirements IDs in future releases (both are only -00 now).


  Regardless, the Diff Serv working group is considering extensions
to the current definitions of the code space (I cannot comment, however,
on what the consensus is). If there is a need to add pre-emption as one
of the forwarding services provided to a traffic flow, then the proposal
should be made to the Diff Serv wg.

Regards,
Gary

> -----Original Message-----
> From: Hancock, Robert [mailto:robert.hancock@roke.co.uk]
> Sent: April 9, 2002 10:06
> To: nsis@ietf.org
> Subject: [NSIS] attempted summary of pre-emption thread
>
>
> dear all,
>
> well, this is quite a thread to come back from a short holiday to.
> I attempt to make a summary (partly for my own benefit):
>
> ==================
> 1. pre-emption (let's call it 'session pre-emption'?) is a
> useful and sometimes mandatory capability within networks
> (examples: emergency call handling; operation after capacity
> loss e.g. due to partial network failure).
>
> 2. only the network can decide what sessions to pre-empt in
> favour of what other sessions.
>
> 3. QoS signalling has to carry enough information to enable
> the network to make this decision (and that information might
> have to be authenticated or otherwise processed to classify
> the session securely); however, this information does not
> need to be visible to the signalling protocol.
>
> 4. if a session is pre-empted, the network might (should?)
> want to tell affected users that their QoS has been degraded.
> ==================
>
> If this is complete, the implications for NSIS would seem to be:
> A) from (3), the QoS data carried has to include particular
> information - but since this is opaque to us anyway, there is
> no new requirement here.
> B) in support of (4), the signalling protocol has to be able
> to send an asynchronous message about a QoS change - but I
> think we also have this already (for other reasons).
>
> So, no new requirements. But maybe some more pointers about
> how important (B) is and where in the network. (But note: (B)
> isn't needed to support pre-emption, it's just a side effect
> of doing pre-emption, so maybe the added significance is not great.)
>
> I've thought hard in the past but can't think of any new
> requirements for NSIS from this topic. I'd be interested to see any.
> If this method of reasoning is useful, maybe it is helpful to
> capture it in the requirements appendix as a scenario
> ("here's how a pre-emption event is handled and what NSIS
> capabilities are used to do so"), or is that a framework issue?
>
> robert h.
> now to the handover one ...
>


*************************************
"People generally demand more respect for their own rights than they are willing to allow for others"

James M. Polk
Consulting Engineer
Office of the CTO

Cisco Systems
2200 East President George Bush Turnpike
Richardson, TX  75082 USA
w) 972.813.5208
f)  972.813.5280
www.cisco.com --=====================_78054816==_.ALT-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Tue Apr 9 15:22:29 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17957 for ; Tue, 9 Apr 2002 15:22:29 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA14643 for nsis-archive@odin.ietf.org; Tue, 9 Apr 2002 15:22:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA14163; Tue, 9 Apr 2002 15:14:19 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA14103 for ; Tue, 9 Apr 2002 15:14:15 -0400 (EDT) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17577; Tue, 9 Apr 2002 15:14:10 -0400 (EDT) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g39J28I12008; Tue, 9 Apr 2002 12:02:08 -0700 (PDT) Message-ID: <019c01c1dff8$d2b252f0$7e6015ac@T23KEMPF> From: "James Kempf" To: "Gary Kenward" , "'Rajeev Koodli'" , "Nakhjiri Madjid-MNAKHJI1" Cc: , , References: <9FBD322B7824D511B36900508BF93C9C01AA4A06@zcard031.ca.nortel.com> Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Tue, 9 Apr 2002 12:00:31 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit Gary, > Sorry, but I am a bit confused (as usual), are you saying > then that doing these functions with the CT protocol is less > heavyweight, and thus preferable? > No, I'm saying that "dropping the session" is more heavyweight. And what do you mean by a session anyway? IP is connectionless. I think what you mean is that all feature contexts for the MN revert to the startup state, namely gone. > The default action, always, is for the session to be dropped. > This will ultimately force the MN to take action (oh, ok, some > MNs will simply halt and catch fire). Anything more then dropping > the session is simply to improve the handover performance under > various conditions. Typically, when one gets into exception scenarios, > the solutions become too complex or degrade performance too much > to be justified against the potential gains. A classic example is > run time type/value checking in C/C++. > My point is, if the MN never finds out about this, then it can't take any action. > If there are no recovery mechanisms for the potential faults > you describe, then does it make sense to build one into CT? > On the other hand, if these mechanisms are built into the handover > algorithm, or into the session support, then putting it into CT > would be redundant, would it not? > I'm not saying that there should be recovery built into CT. What I am saying is that the MN has got to know when it has to redo signaling in order to reestablish stuff like it's AAA state or it's QoS state. We went through this exact conversation on the MIP list with respect to BETH. The MN doesn't get involved in handover with BETH, so it needs to be informed when BETH handover fails (in practice, we tell it when BETH handover is about to fail). Then it can do standard MIP signaling in order to get a care of address. I'm willing to grant that having CT do feature by feature failure notification doesn't make sense, but I still think there needs to be some way to tell the MN that seamlessness has failed or is about to fail so it can take the right steps to restart the original network admission procedure. I think this is needed if for no other reason than when the MN reaches the edge of the operator's domain, if the operator doesn't have the right business agreements with the next operator, the MN has got to know to redo network entry, i.e. AAA from scratch, QoS from scratch, etc. jak _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Tue Apr 9 15:30:53 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18268 for ; Tue, 9 Apr 2002 15:30:52 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA15203 for nsis-archive@odin.ietf.org; Tue, 9 Apr 2002 15:30:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA14618; Tue, 9 Apr 2002 15:21:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA14557 for ; Tue, 9 Apr 2002 15:21:53 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17937; Tue, 9 Apr 2002 15:21:49 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g39JLJg09865; Tue, 9 Apr 2002 15:21:20 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 9 Apr 2002 15:21:20 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4A0B@zcard031.ca.nortel.com> From: "Gary Kenward" Cc: "'nsis@ietf.org'" , "'seamoby@ietf.org'" Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Tue, 9 Apr 2002 15:21:19 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DFFB.9C13BB6E" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1DFFB.9C13BB6E Content-Type: text/plain; charset="iso-8859-1" Phil: Yup, Phil, I have studied it. My point was that the unreliability of CT should not be noticeable with respect to the relative unreliability of handover. And the latter is far from 100% reliable, even with all the advances. Of course, one could make CT grossly unreliable, but I contend that it is easier to make an information transfer between two (relatively close) nodes in a wired network reliable then it is to make anything in wireless more reliable. Cheers, Gary -----Original Message----- From: Phil Neumiller [mailto:pneumiller@directvinternet.com] Sent: April 8, 2002 20:43 To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Nakhjiri Madjid-MNAKHJI1'; 'Rajeev Koodli'; James Kempf Cc: Hemant.Chaskar@nokia.com; nsis@ietf.org; seamoby@ietf.org Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Hmm. Gary have you studied the mechanics (i.e. the physics as you put it) of 3G aka CDMA handover? Why do you say its unreliable? Make before break won the battle years ago. Why do people in the IETF incessently restrict themselve to legacy handovers???? ----- Original Message ----- From: Gary Kenward To: 'Nakhjiri Madjid-MNAKHJI1' ; 'Rajeev Koodli' ; James Kempf Cc: Hemant.Chaskar@nokia.com ; nsis@ietf.org ; seamoby@ietf.org Sent: Monday, April 08, 2002 3:46 PM Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Can anyone offer an explaining of how or why CT would add significantly to the already unreliable physics of handover? What failure modes for CT would be noticeable above the unavoidable rate of handover failures due the vagaries of wireless coverage and wireless link layer performance???? If CT fails, then the handover fails. It is that simple. If CT were to fail with every 2nd handover attempt, then there would be a problem. But, I cannot seriously see CT failing more then every one in a million handover attempts, or less. CT should not be attempted if there is an incompatibility between source and destination ARs. And, I HAD thought that it was the purpose of CAR to identify those incompatibilities and thus avoid doing CT when it is clear it would fail. How to mitigate those incompatibles is not a CT issue, it is a service adaptation issue, which can be resolved in a number of ways, some of which would imply signalled negotiation either between the ARs or between the ARs and the MN. Gary > -----Original Message----- > From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] > Sent: April 5, 2002 16:58 > To: 'Rajeev Koodli'; James Kempf > Cc: Kenward, Gary [WDLN2:AN10:EXCH]; Hemant.Chaskar@nokia.com; > nsis@ietf.org; seamoby@ietf.org > Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > Agreed. I don't think reliability in signaling, which by the way > neither CT requirements, nor nsis requirements are covering, has to > do with failure in QoS negotiation. I don't think you can count > the case, where the QoS information that CT has given the AR is not > applicable, as a CT failure. > > Madjid > > -----Original Message----- > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] > Sent: Friday, April 05, 2002 12:03 PM > To: James Kempf > Cc: Gary Kenward; Hemant.Chaskar@nokia.com; nsis@ietf.org; > seamoby@ietf.org > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > James Kempf wrote: > > > Rajeev, > > > > I agree, but there is still an issue of how the AR would > notify the MN > > if CT fails. Is this covered by CT or not? > > > > This notification should be covered by CT. We should offer > seamless handover to NSIS :-) Seriously, this concerns > robustness of CT protocol. > > -Rajeev > > > ------_=_NextPart_001_01C1DFFB.9C13BB6E Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff.

Phil:
 
  Yup, Phil, I have studied it. My point was that the unreliability of CT should not
be noticeable with respect to the relative unreliability of handover. And the
latter is far from 100% reliable, even with all the advances.
 
  Of course, one could make CT grossly unreliable, but I contend that it is easier
to make an information transfer between two (relatively close) nodes in a wired
network reliable then it is to make anything in wireless more reliable.
 
Cheers,
Gary
-----Original Message-----
From: Phil Neumiller [mailto:pneumiller@directvinternet.com]
Sent: April 8, 2002 20:43
To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Nakhjiri Madjid-MNAKHJI1'; 'Rajeev Koodli'; James Kempf
Cc: Hemant.Chaskar@nokia.com; nsis@ietf.org; seamoby@ietf.org
Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff.


Hmm.  Gary have you studied the mechanics (i.e. the physics as you put it) of 3G aka
CDMA handover?  Why do you say its unreliable?  Make before break won the battle years
ago.  Why do people in the IETF incessently restrict themselve to legacy handovers????
 
----- Original Message -----
From: Gary Kenward
To: 'Nakhjiri Madjid-MNAKHJI1' ; 'Rajeev Koodli' ; James Kempf
Cc: Hemant.Chaskar@nokia.com ; nsis@ietf.org ; seamoby@ietf.org
Sent: Monday, April 08, 2002 3:46 PM
Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff.


Can anyone offer an explaining of how or why CT would add significantly
to the already unreliable physics of handover?
What failure modes for CT would be noticeable above the unavoidable
rate of handover failures due the vagaries of wireless coverage and
wireless link layer performance????
If CT fails, then the handover fails. It is that simple. If CT were
to fail with every 2nd handover attempt, then there would be a problem.
But, I cannot seriously see CT failing more then every one in a million
handover attempts, or less.
CT should not be attempted if there is an incompatibility between source
and destination ARs. And, I HAD thought that it was the purpose of CAR
to identify those incompatibilities and thus avoid doing CT when it is
clear it would fail. How to mitigate those incompatibles is not a
CT issue, it is a service adaptation issue, which can be resolved in
a number of ways, some of which would imply signalled negotiation either
between the ARs or between the ARs and the MN.
Gary
> -----Original Message-----
> From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com]
> Sent: April 5, 2002 16:58
> To: 'Rajeev Koodli'; James Kempf
> Cc: Kenward, Gary [WDLN2:AN10:EXCH]; Hemant.Chaskar@nokia.com;
> nsis@ietf.org; seamoby@ietf.org
> Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff.
>
>
> Agreed. I don't think reliability in signaling, which by the way
> neither CT requirements, nor nsis requirements are covering, has to
> do with failure in QoS negotiation. I don't think you can count
> the case, where the QoS information that CT has given the AR is not
> applicable, as a CT failure.
>
> Madjid
>
> -----Original Message-----
> From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com]
> Sent: Friday, April 05, 2002 12:03 PM
> To: James Kempf
> Cc: Gary Kenward; Hemant.Chaskar@nokia.com; nsis@ietf.org;
> seamoby@ietf.org
> Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff.
>
>
> James Kempf wrote:
>
> > Rajeev,
> >
> > I agree, but there is still an issue of how the AR would
> notify the MN
> > if CT fails. Is this covered by CT or not?
> >
>
> This notification should be covered by CT.  We should offer
> seamless handover to NSIS :-) Seriously, this concerns
> robustness of CT protocol.
>
> -Rajeev
>
>
>

------_=_NextPart_001_01C1DFFB.9C13BB6E-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Tue Apr 9 16:03:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19827 for ; Tue, 9 Apr 2002 16:03:27 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA17229 for nsis-archive@odin.ietf.org; Tue, 9 Apr 2002 16:03:29 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA16313; Tue, 9 Apr 2002 15:50:12 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA16158 for ; Tue, 9 Apr 2002 15:50:03 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19163; Tue, 9 Apr 2002 15:49:59 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g39JnBq06102; Tue, 9 Apr 2002 15:49:11 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 9 Apr 2002 15:49:12 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4A0C@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'James Kempf'" , "'Rajeev Koodli'" , Nakhjiri Madjid-MNAKHJI1 Cc: Hemant.Chaskar@nokia.com, nsis@ietf.org, seamoby@ietf.org Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Tue, 9 Apr 2002 15:49:10 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DFFF.9DDF7DEE" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1DFFF.9DDF7DEE Content-Type: text/plain; charset="iso-8859-1" James: > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: April 9, 2002 15:01 > To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Rajeev Koodli'; Nakhjiri > Madjid-MNAKHJI1 > Cc: Hemant.Chaskar@nokia.com; nsis@ietf.org; seamoby@ietf.org > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > Gary, > > > Sorry, but I am a bit confused (as usual), are you saying > > then that doing these functions with the CT protocol is less > > heavyweight, and thus preferable? > > > > No, I'm saying that "dropping the session" is more > heavyweight. And what Agreed. It would be better to try and fix things first. The real question is at what level. > do you mean by a session anyway? > IP is connectionless. Well...sessions do not require connections. But I have a feeling we both do not want to open up that can-of-worms debate. When I say "session", I mean all the collection of services/resources that have been set up to support an IP flow, QoS, AAA, HC, etc. If you have a better word, I'll use it. > > I think what you mean is that all feature contexts for the MN > revert to > the startup state, namely gone. Ok. Except, that it may be only the feature contexts for a given microflow. E.g just because a new AR cannot support EF PHB, does not mean that the BE flows need to be dropped. > > > The default action, always, is for the session to be dropped. > > This will ultimately force the MN to take action (oh, ok, some > > MNs will simply halt and catch fire). Anything more then dropping > > the session is simply to improve the handover performance under > > various conditions. Typically, when one gets into exception > scenarios, > > the solutions become too complex or degrade performance too much > > to be justified against the potential gains. A classic example is > > run time type/value checking in C/C++. > > > > My point is, if the MN never finds out about this, then it can't take > any action. My points is that this is not a CT protocol function. There are any number of failure points for a service feature, and it is the responsibility of the control entity for that service feature to notify the MN. > > > If there are no recovery mechanisms for the potential faults > > you describe, then does it make sense to build one into CT? > > On the other hand, if these mechanisms are built into the handover > > algorithm, or into the session support, then putting it into CT > > would be redundant, would it not? > > > > I'm not saying that there should be recovery built into CT. What I am > saying is > that the MN has got to know when it has to redo signaling in order to > reestablish > stuff like it's AAA state or it's QoS state. see comment above. But, btw: how does the MN re-establish state without dropping the flow? E.g. authentication? authorization? does re-establishing EF PHB make any sense (if you cannot do it within a 100 ms, has the service not been "dropped" anyway?) > > We went through this exact conversation on the MIP list with > respect to > BETH. The > MN doesn't get involved in handover with BETH, so it needs to be > informed when > BETH handover fails (in practice, we tell it when BETH > handover is about > to fail). > Then it can do standard MIP signaling in order to get a care > of address. > > I'm willing to grant that having CT do feature by feature failure > notification doesn't make sense, > but I still think there needs to be some way to tell the MN that > seamlessness has failed > or is about to fail so it can take the right steps to restart the > original network admission > procedure. > > I think this is needed if for no other reason than when the MN reaches > the edge of the operator's > domain, if the operator doesn't have the right business > agreements with > the next operator, the MN > has got to know to redo network entry, i.e. AAA from scratch, QoS from > scratch, etc. We agree on the first part of these two paragraphs. But, I am confused: I am not aware of any current facilities within QoS/AAA that allows the MN to repair AAA/QoS state as opposed to "building it from scratch". Certainly, protocols can be extended, but then, they can also be extended to allow for notification. Consider: o CT fails for a specific context o CT somehow sends notification that the context for QoS has failed. o MN determines (somehow) what this failure message means (again, consider that CT can, at best, notify that a particular data chunk failed somehow at the new AR, not why). o MN initiates a re-negotiation with the appropriate network entity (AAA server perhaps? an QoS Controller perhaps?) Versus: o CT fails for a specific context o service feature entity at new AR determines that it is unable to support one or more of the MN flows either because it does not have the context, or because it cannot support the context o new AR determines, perhaps using local policy decisions, what mitigating action can to be taken locally (e.g. downgrade an AF flow to a BE flow to support forwarding until new negotiations can take place). - OR - o new AR determines, perhaps using local policy decisions, that the control entity for the feature (e.g. the AAA server), needs to be notified (e.g. the service lacks proper authorization), the control entity can then take direct action (e.g. perhaps by some inter-system authorization exchange). - OR - o new AR determines, perhaps using local policy decisions, that the MN is should fix the problem, and sends a notification. Which scenario appears more flexible, more responsive, and more likely to support seamless handovers? Gary > > jak > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > ------_=_NextPart_001_01C1DFFF.9DDF7DEE Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff.

James:

> -----Original Message-----
> From: James Kempf [mailto:kempf@docomolabs-usa.com]
> Sent: April 9, 2002 15:01
> To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Rajeev Koodli'; Nakhjiri
> Madjid-MNAKHJI1
> Cc: Hemant.Chaskar@nokia.com; nsis@ietf.org; seamoby@ietf.org
> Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff.
>
>
> Gary,
>
> >   Sorry, but I am a bit confused (as usual), are you saying
> > then that doing these functions with the CT protocol is less
> > heavyweight, and thus preferable?
> >
>
> No, I'm saying that "dropping the session" is more
> heavyweight. And what

Agreed. It would be better to try and fix things first. The real
question is at what level.

> do you mean by a session anyway?
> IP is connectionless.

Well...sessions do not require connections. But I have a feeling
we both do not want to open up that can-of-worms debate.

When I say "session", I mean all the collection of services/resources
that have been set up to support an IP flow, QoS, AAA, HC, etc.
If you have a better word, I'll use it.

>
> I think what you mean is that all feature contexts for the MN
> revert to
> the startup state, namely gone.

Ok. Except, that it may be only the feature contexts for a given
microflow. E.g just because a new AR cannot support EF PHB, does
not mean that the BE flows need to be dropped.

>
> >   The default action, always, is for the session to be dropped.
> > This will ultimately force the MN to take action (oh, ok, some
> > MNs will simply halt and catch fire). Anything more then dropping
> > the session is simply to improve the handover performance under
> > various conditions. Typically, when one gets into exception
> scenarios,
> > the solutions become too complex or degrade performance too much
> > to be justified against the potential gains. A classic example is
> > run time type/value checking in C/C++.
> >
>
> My point is, if the MN never finds out about this, then it can't take
> any action.

My points is that this is not a CT protocol function. There are any
number of failure points for a service feature, and it is the responsibility
of the control entity for that service feature to notify the MN.

>
> >   If there are no recovery mechanisms for the potential faults
> > you describe, then does it make sense to build one into CT?
> > On the other hand, if these mechanisms are built into the handover
> > algorithm, or into the session support, then putting it into CT
> > would be redundant, would it not?
> >
>
> I'm not saying that there should be recovery built into CT. What I am
> saying is
> that the MN has got to know when it has to redo signaling in order to
> reestablish
> stuff like it's AAA state or it's QoS state.

see comment above.

But, btw: how does the MN re-establish state without dropping the flow?
E.g. authentication? authorization? does re-establishing EF PHB make
any sense (if you cannot do it within a 100 ms, has the service not
been "dropped" anyway?)

>
> We went through this exact conversation on the MIP list with
> respect to
> BETH. The
> MN doesn't get involved in handover with BETH, so it needs to be
> informed when
> BETH handover fails (in practice, we tell it when BETH
> handover is about
> to fail).
> Then it can do standard MIP signaling in order to get a care
> of address.
>
> I'm willing to grant that having CT do feature by feature failure
> notification doesn't make sense,
> but I still think there needs to be some way to tell the MN that
> seamlessness has failed
> or is about to fail so it can take the right steps to restart the
> original network admission
> procedure.
>
> I think this is needed if for no other reason than when the MN reaches
> the edge of the operator's
> domain, if the operator doesn't have the right business
> agreements with
> the next operator, the MN
> has got to know to redo network entry, i.e. AAA from scratch, QoS from
> scratch, etc.

We agree on the first part of these two paragraphs. But, I am confused:
I am not aware of any current facilities within QoS/AAA that allows the MN
to repair AAA/QoS state as opposed to "building it from scratch". Certainly,
protocols can be extended, but then, they can also be extended to allow
for notification.

Consider:

   o CT fails for a specific context

   o CT somehow sends notification that the context for QoS has failed.

   o MN determines (somehow) what this failure message means (again, consider that
CT can, at best, notify that a particular data chunk failed somehow at the new AR,
not why).

   o MN initiates a re-negotiation with the appropriate network entity (AAA server
perhaps? an QoS Controller perhaps?)

Versus:

   o CT fails for a specific context

   o service feature entity at new AR determines that it is unable to support
     one or more of the MN flows either because it does not have the context,
     or because it cannot support the context

   o new AR determines, perhaps using local policy decisions, what mitigating
     action can to be taken locally (e.g. downgrade an AF flow to a BE flow to
     support forwarding until new negotiations can take place).

                                  - OR -

   o new AR determines, perhaps using local policy decisions, that the control
     entity for the feature (e.g. the AAA server), needs to be notified (e.g.
     the service lacks proper authorization), the control entity can then take
     direct action (e.g. perhaps by some inter-system authorization exchange).

                                  - OR -

   o new AR determines, perhaps using local policy decisions, that the MN is
     should fix the problem, and sends a notification.

Which scenario appears more flexible, more responsive, and more likely to
support seamless handovers?

Gary

>
>             jak
>
>
>
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis
>

------_=_NextPart_001_01C1DFFF.9DDF7DEE-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Tue Apr 9 16:11:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20410 for ; Tue, 9 Apr 2002 16:11:32 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA17668 for nsis-archive@odin.ietf.org; Tue, 9 Apr 2002 16:11:35 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA17420; Tue, 9 Apr 2002 16:06:18 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA17379 for ; Tue, 9 Apr 2002 16:06:15 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20044 for ; Tue, 9 Apr 2002 16:06:10 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g39K1eq09724; Tue, 9 Apr 2002 16:01:40 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 9 Apr 2002 16:01:41 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4A0D@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'James M. Polk'" , "Hancock, Robert" , nsis@ietf.org Subject: RE: [NSIS] attempted summary of pre-emption thread Date: Tue, 9 Apr 2002 16:01:38 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1E001.5BD175CC" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1E001.5BD175CC Content-Type: text/plain; charset="iso-8859-1" James: Robert's email was clear to me, and well stated. He was saying that if there is a requirement for pre-emption, then it can be captured in the data description (hopefully, an opaque TLV data chunk) for the QoS, and there is no need for a change in the requirements for NSIS. There may be, and Robert did not address this, a need to change the IETF definitions for QoS, iff the intent is to have pre-emption supported as part of the standard offerings. E.g. if a pre-emptive EF PHB is required, then the Diff Serv wg must make the change, not NSIS. In addition, there is no reason why the NSIS protocol cannot carry network, and even device specific TLV data chunks. However, the contents of these data chunks need not be visible to NSIS - how would the fact that the QoS contained a specification for pre-emption change the semantics of the NSIS protocols? Given that the answer, as far as I can tell is no, then as long as the NSIS syntax allows for the information to be conveyed, it is not necessary to identify the meaning of the QoS specification in the NSIS standard because it is not used by NSIS. This is a very different approach from SS7, UNI, SSCPS, GSM, UMTS, .... IP is an internetworking protocol, and must work across many different networks. NSIS should also work across all (predominant) networks. Given the alternative of defining variants of the protocol for every network, it is often more productive to define a generic capability, and leave the network specific stuff to the respective SDOs. Regards, Gary -----Original Message----- From: James M. Polk [mailto:jmpolk@cisco.com] Sent: April 9, 2002 15:09 To: Hancock, Robert; nsis@ietf.org Subject: Re: [NSIS] attempted summary of pre-emption thread At 03:06 PM 4/9/2002 +0100, Hancock, Robert wrote: I'm confused by your conclusions. Let me quote you, but rearrange what you wrote to show this below. You stated 2 times that QOS information was necessary in the signaling: > >3. QoS signalling has to carry enough information to enable the network to >make this decision (and that information might have to be authenticated or >otherwise processed to classify the session securely); >If this is complete, the implications for NSIS would seem to be: >A) from (3), the QoS data carried has to include particular information - and that if preemption does occur, the "network" should tell someone: >4. if a session is pre-empted, the network might (should?) want to tell >affected users that their QoS has been degraded. >================== > yet state this information now *doesn't* need to be included here: >however, this >information does not need to be visible to the signalling protocol. > and conclude with "no new requirement" for preemption: >but since this is opaque to us anyway, there is no new requirement here. >So, no new requirements. > >I've thought hard in the past but can't think of any new requirements for >NSIS from this topic. I'd be interested to see any. Your logic within your email is flawed and poorly written, and doesn't support the conclusion you wrote. Please review what you wrote that I've highlighted above near the top and tell me how you stated that this information "~ ...has to include particular (identifying) information (for preemption to properly be performed)....", yet conclude that it "~...isn't needed....So, no new requirements." > >robert h. > Robert - you didn't read my email obviously as I stated many networks that have this capability that NSIS *won't* be an appropriate QOS mechanism for interfacing with if this is not included... ************************************* "People generally demand more respect for their own rights than they are willing to allow for others" James M. Polk Consulting Engineer Office of the CTO Cisco Systems 2200 East President George Bush Turnpike Richardson, TX 75082 USA w) 972.813.5208 f) 972.813.5280 www.cisco.com ------_=_NextPart_001_01C1E001.5BD175CC Content-Type: text/html; charset="iso-8859-1" RE: [NSIS] attempted summary of pre-emption thread

James:

  Robert's email was clear to me, and well stated. He was saying that if there
is a requirement for pre-emption, then it can be captured in the data description
(hopefully, an opaque TLV data chunk) for the QoS, and there is no need for a
change in the requirements for NSIS.

  There may be, and Robert did not address this, a need to change the IETF definitions
for QoS, iff the intent is to have pre-emption supported as part of the standard offerings.
E.g. if a pre-emptive EF PHB is required, then the Diff Serv wg must make the change, not
NSIS.

  In addition, there is no reason why the NSIS protocol cannot carry network,
and even device specific TLV data chunks. However, the contents of these data
chunks need not be visible to NSIS - how would the fact that the QoS contained
a specification for pre-emption change the semantics of the NSIS protocols? Given
that the answer, as far as I can tell is no, then as long as the NSIS syntax allows
for the information to be conveyed, it is not necessary to identify the meaning of
the QoS specification in the NSIS standard because it is not used by NSIS.

  This is a very different approach from SS7, UNI, SSCPS, GSM, UMTS, .... IP is an
internetworking protocol, and must work across many different networks. NSIS should
also work across all (predominant) networks. Given the alternative of defining variants
of the protocol for every network, it is often more productive to define a generic capability,
and leave the network specific stuff to the respective SDOs.

Regards,
Gary

-----Original Message-----
From: James M. Polk [mailto:jmpolk@cisco.com]
Sent: April 9, 2002 15:09
To: Hancock, Robert; nsis@ietf.org
Subject: Re: [NSIS] attempted summary of pre-emption thread


At 03:06 PM 4/9/2002 +0100, Hancock, Robert wrote:


I'm confused by your conclusions. Let me quote you, but rearrange what you wrote to show this below.


You stated 2 times that QOS information was necessary in the signaling:
>
>3. QoS signalling has to carry enough information to enable the network to
>make this decision (and that information might have to be authenticated or
>otherwise processed to classify the session securely);


>If this is complete, the implications for NSIS would seem to be:
>A) from (3), the QoS data carried has to include particular information -


and that if preemption does occur, the "network" should tell someone:


>4. if a session is pre-empted, the network might (should?) want to tell
>affected users that their QoS has been degraded.
>==================
>
yet state this information now *doesn't* need to be included here:


>however, this
>information does not need to be visible to the signalling protocol.
>


and conclude with "no new requirement" for preemption:


>but since this is opaque to us anyway, there is no new requirement here.


>So, no new requirements.
>
>I've thought hard in the past but can't think of any new requirements for
>NSIS from this topic. I'd be interested to see any.


Your logic within your email is flawed and poorly written, and doesn't support the conclusion you wrote. Please review what you wrote that I've highlighted above near the top and tell me how you stated that this information "~ ...has to include particular (identifying) information (for preemption to properly be performed)....", yet conclude that it "~...isn't needed....So, no new requirements."


>
>robert h.
>
Robert - you didn't read my email obviously as I stated many networks that have this capability that NSIS *won't* be an appropriate QOS mechanism for interfacing with if this is not included...




*************************************
"People generally demand more respect for their own rights than they are willing to allow for others"


James M. Polk
Consulting Engineer
Office of the CTO

Cisco Systems
2200 East President George Bush Turnpike
Richardson, TX  75082 USA
w) 972.813.5208
f)  972.813.5280
www.cisco.com

------_=_NextPart_001_01C1E001.5BD175CC-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Tue Apr 9 17:03:52 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22478 for ; Tue, 9 Apr 2002 17:03:47 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA20988 for nsis-archive@odin.ietf.org; Tue, 9 Apr 2002 17:03:51 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA19741; Tue, 9 Apr 2002 16:55:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA19678 for ; Tue, 9 Apr 2002 16:55:38 -0400 (EDT) Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22153; Tue, 9 Apr 2002 16:55:33 -0400 (EDT) Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate3.mot.com (motgate3 2.1) with ESMTP id NAA27478; Tue, 9 Apr 2002 13:44:05 -0700 (MST)] Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id NAA18551; Tue, 9 Apr 2002 13:55:35 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2654.52) id <2NG85VCB>; Tue, 9 Apr 2002 15:55:35 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B04650056@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'James Kempf'" , Nakhjiri Madjid-MNAKHJI1 , Rajeev Koodli Cc: nsis@ietf.org, seamoby@ietf.org Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Tue, 9 Apr 2002 15:55:33 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org James, As I said, it depends on how complicated you want the CT to be. I thought we were supposed to see CT as a container and not look into contents. Ideally the two networks communicating with each other have some clue about each other (either part of same admin domain, and hence all capabilities are known, or different admin domain, in which case, roaming agreements might be needed). Why should CT itself care about whether what it is carrying make sense to the newAR or not, it can, like any other signaling protocol (NSIS as an example) carry a lot of opaque info. At the most maybe a notification like what Rajeev proposed. Going further than that you need to be careful not to get into specific feature issues. BR, Madjid -----Original Message----- From: James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Monday, April 08, 2002 10:42 AM To: Nakhjiri Madjid-MNAKHJI1; Rajeev Koodli Cc: Gary Kenward; Hemant.Chaskar@nokia.com; nsis@ietf.org; seamoby@ietf.org Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Madjid, The issue isn't reliability, it is whether the target AR can interpret the context intelligably. If not, the MN may need to recover by actually re-initializing whatever feature the context was being transfered for. But it cannot do this unless it knows that the CT has failed. For some feature contexts, like header compression, this isn't a problem because it will re-initialize automatically, but for AAA or QoS it clearly will be. jak ----- Original Message ----- From: "Nakhjiri Madjid-MNAKHJI1" To: "'James Kempf'" ; "Rajeev Koodli" Cc: "Gary Kenward" ; ; ; Sent: Friday, April 05, 2002 3:00 PM Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > Well, you are opening a can of worm that took seamoby 3 months > to close without any results. People could not agree on the > reliability needs of CT. We added a reliability mechanism to our > CT proposal that covered both retransmission and updates. > > Madjid > > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: Friday, April 05, 2002 12:22 PM > To: Rajeev Koodli > Cc: Gary Kenward; Hemant.Chaskar@nokia.com; nsis@ietf.org; > seamoby@ietf.org > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > Agree. > > But I don't see anything in the CT requirements about handling CT > failure. > > ??? > > jak > > ----- Original Message ----- > From: "Rajeev Koodli" > To: "James Kempf" > Cc: "Gary Kenward" ; > ; ; > Sent: Friday, April 05, 2002 10:02 AM > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > James Kempf wrote: > > > > > Rajeev, > > > > > > I agree, but there is still an issue of how the AR would notify the > MN > > > if CT fails. Is this covered by CT or not? > > > > > > > This notification should be covered by CT. We should offer > > seamless handover to NSIS :-) Seriously, this concerns > > robustness of CT protocol. > > > > -Rajeev > > > > > > > > > > jak > > > > > > ----- Original Message ----- > > > From: "Rajeev Koodli" > > > To: "James Kempf" > > > Cc: "Gary Kenward" ; > > > ; ; > > > Sent: Friday, April 05, 2002 9:19 AM > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > Hello Jim, > > > > > > > > James Kempf wrote: > > > > > > > > > There is an issue if CT fails. In that case, some kind of > > > negotiation > > > > > after handover would be required. > > > > > > > > > > So, I'd say that some indication of CT failure is needed. > > > > > > > > > > > > > Yes, but this is between AR and MN. If CT fails, the AR should > > > > notify the MN to engage in context re-creation. > > > > > > > > My point was specific to signaling _beyond_ AR (i.e., upstream > > > signaling) > > > > independent of failure/success of CT. > > > > > > > > Hope this is clearer.. > > > > > > > > -Rajeev > > > > > > > > > > > > > > > > > > As for CAR, I don't see the relevance for QoS negotiation, > though it > > > may > > > > > be useful for finding a new wireless medium. I also see it > primarily > > > for > > > > > intertechnology handover, or, at best, interprovider handover. > > > > > > > > > > jak > > > > > ----- Original Message ----- > > > > > From: "Rajeev Koodli" > > > > > To: "Gary Kenward" > > > > > Cc: ; ; > > > > > > Sent: Friday, April 05, 2002 9:01 AM > > > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after > handoff. > > > > > > > > > > > > > > > > > Hello, > > > > > > > > > > > > well, if the issue is QoS establishment after handover, > > > > > > > > > > > > - CT is applicable for establishing QoS state at the AR > > > > > > - if further signaling is desired beyond the AR, NSIS may > > > > > > consider it. I don't see how _signaling_ for QoS > establishment > > > > > > beyond AR is relevant for seamoby. > > > > > > > > > > > > CAR _discovery_ could exchange QoS capability as one of the > > > > > > parameters that might then be fed to a selection algorithm. > Any > > > > > > signaling for actually establishing QoS itself beyond the AR > > > > > > should be outside the scope of seamoby.. > > > > > > > > > > > > Regards, > > > > > > > > > > > > -Rajeev > > > > > > > > > > > > > > > > > > Gary Kenward wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > Hemant: > > > > > > > > > > > > > > Just a point of clarification, but as I understand CARD > (and > > > > > > > I don't understand it well), it is not a QoS negotiation > > > > > > > protocol. The main application that you are referring to > > > primarily > > > > > > > arises out of a perceived need to determine at the MN the > best > > > link > > > > > > > layer to handover over to when inter-technology handovers > are > > > > > > > involved. > > > > > > > It can be applied to intra-technology handovers, but the > value > > > in > > > > > > > that situation is highly questionable (e.g. since it is a > > > discovery > > > > > > > protocol, the implication is that the purpose is to > determine > > > the > > > > > > > choice of channels available; for intra-technology > handovers, > > > there > > > > > > > are many, many reasons why this "choice" may not be > available). > > > > > > > > > > > > > > There is a requirement, 5.1.2, which seems to imply NSIS > > > > > involvement > > > > > > > > > > > > > > during/after a handover. John has stated that this is not > the > > > > > > > intention > > > > > > > (please correct me if I have this wrong John), in which case > I > > > think > > > > > > > 5.1.2 needs to be clarified. > > > > > > > > > > > > > > Specifically, is NSIS to be used to negotiated new QoS for > an > > > > > > > existing flow after a handover, or is it specifically for > > > > > establishing > > > > > > > > > > > > > > QoS for a new flow? I don't think the answer is boolean: the > > > role > > > > > > > of NSIS in QoS re-negotiation is still open, I believe, and > > > clearly > > > > > > > handover is a dynamic situation that could cause the QoS > > > provided to > > > > > > > change. > > > > > > > > > > > > > > I have been told there is no issue, but here's a > frightening > > > > > > > scenario: > > > > > > > > > > > > > > - a handover takes place, and context transfer has > been > > > used > > > > > > > to > > > > > > > move the QoS context to the new routers (by the > > > requirements > > > > > > > for > > > > > > > CT this could be intra-, or inter- technology. Some > of us > > > > > > > believe > > > > > > > that for "seamless" handovers, the context will be > > > available > > > > > at > > > > > > > > > > > > > > routers before the first packets need to be > forwarded. > > > This > > > > > > > implies > > > > > > > that there is a relationship, probabilistic perhaps, > > > between > > > > > > > the handover process and the target ARs for CT. > > > > > > > > > > > > > > - CARD is used by the MN to influence the handover > decision > > > (it > > > > > > > is not clear to me how this happens, but it seems > clear > > > that > > > > > > > for a more "seamless" handover, the MN should chose > an AR > > > > > that > > > > > > > has received the appropriate context; if not, then > what? > > > > > > > > > > > > > > - NSIS kicks in and starts re-negotiating QoS because > of > > > > > changes > > > > > > > introduced by the handover; > > > > > > > > > > > > > > How do these three protocols interact to produce > predictable > > > > > > > outcomes? > > > > > > > Or, perhaps, the question is, how do the functional entities > > > > > > > associated > > > > > > > with the three protocols interact before, during and after a > > > > > handover? > > > > > > > > > > > > > > If it the interaction is within the functional entities, the > > > > > > > respective > > > > > > > wg's could declare the issue out of scope, but this approach > > > does > > > > > not > > > > > > > sit well with me, for it seems to defer the problem to the > > > people > > > > > who > > > > > > > have to implement this "stuff". > > > > > > > > > > > > > > Am I imagining things? > > > > > > > > > > > > > > Cheers, > > > > > > > Gary > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Hemant.Chaskar@nokia.com > > > [mailto:Hemant.Chaskar@nokia.com] > > > > > > > > Sent: April 4, 2002 22:33 > > > > > > > > To: nsis@ietf.org > > > > > > > > Subject: RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > > > > > > > > > > > > Hi Sharif: > > > > > > > > > > > > > > > > There is currently a debate going on in Seamoby as to > whether > > > > > > > > this QoS negotiation be covered by NSIS or Seamoby (CAR > > > > > > > > discovery protocol). > > > > > > > > > > > > > > > > IMHO it should be covered by CAR discovery and not NSIS. > CAR > > > > > > > > discovery is supposed to identify candidate access routers > > > > > > > > for handoff and QoS is an important property for > candidacy. > > > > > > > > > > > > > > > > Br, > > > > > > > > Hemant > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: ext Shahrier, Sharif M. > > > > > > > > [mailto:Sharif.Shahrier@InterDigital.com] > > > > > > > > Sent: Thursday, April 04, 2002 3:35 PM > > > > > > > > To: Shahrier, Sharif M. > > > > > > > > Cc: 'nsis@ietf.org' > > > > > > > > Subject: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I have a question for clarification. > > > > > > > > > > > > > > > > I think it was stated that NSIS should only be concerned > with > > > the > > > > > > > > establishment of QoS after handoff. > > > > > > > > > > > > > > > > This is inconvienent with respect to IP-level QoS > > > > > > > > negotiation, which ideally > > > > > > > > should be done before handoff has taken place. > > > > > > > > > > > > > > > > QoS negotiation is in the current requirements draft. > > > > > > > > > > > > > > > > So, NSIS signaling protocol development should be > concerned > > > > > > > > with activity > > > > > > > > before handoff occurs. > > > > > > > > > > > > > > > > Sharif. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > Seamoby mailing list > > > > > > Seamoby@ietf.org > > > > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Seamoby mailing list > > > > Seamoby@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Tue Apr 9 17:21:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23207 for ; Tue, 9 Apr 2002 17:21:07 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA22097 for nsis-archive@odin.ietf.org; Tue, 9 Apr 2002 17:21:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA21430; Tue, 9 Apr 2002 17:09:04 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA21382 for ; Tue, 9 Apr 2002 17:09:01 -0400 (EDT) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22793; Tue, 9 Apr 2002 17:08:56 -0400 (EDT) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id OAA27849; Tue, 9 Apr 2002 14:08:58 -0700 (MST)] Received: [from il75exm04.cig.mot.com ([136.182.110.113]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id OAA05092; Tue, 9 Apr 2002 14:08:58 -0700 (MST)] Received: by IL75EXM04 with Internet Mail Service (5.5.2654.52) id <2NF0LHPR>; Tue, 9 Apr 2002 16:08:58 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B04650058@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'James Kempf'" , Gary Kenward , Nakhjiri Madjid-MNAKHJI1 , Rajeev Koodli Cc: Hemant.Chaskar@nokia.com, nsis@ietf.org, seamoby@ietf.org Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Tue, 9 Apr 2002 16:08:53 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org all you have to do is to add a CT-NACK, please, look at our TEXT proposal. We even have a CT-NACK for each feature. madjid -----Original Message----- From: James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Monday, April 08, 2002 1:32 PM To: Gary Kenward; Nakhjiri Madjid-MNAKHJI1; Rajeev Koodli Cc: Hemant.Chaskar@nokia.com; nsis@ietf.org; seamoby@ietf.org Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Gary, I agree about session establishment, but the fact remains that if failure of a context transfer for some reason leaves the MN without any indication that it should proceed to re-establish the feature, then the MN can't know when it should redo signaling to set up its new state. We faced this issue with BETH/FMIPv6 and the solution we found there was to have routers on the border of a fast handover coverage area inform the MN what handover algorithm was supported by routers in the other coverage area. While I think this could be done for the cases involving router configuration, such as where the next access router can't interpret the context, I am not so sure about failure due to dynamic conditions, such as that the router currently has all its Gold Class service bandwidth allocated (a QoS failure). In any event, I think there is need for some kind of signaling to indicate to the MN that context transfer has failed and that the MN needs to redo signaling to re-establish feature contexts. jak ----- Original Message ----- From: "Gary Kenward" To: "'James Kempf'" ; "Nakhjiri Madjid-MNAKHJI1" ; "Rajeev Koodli" Cc: ; ; Sent: Monday, April 08, 2002 11:08 AM Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > James: > > My main problem with the theme in this discussion is that > CT is a context transfer protocol, not a session management protocol. > In particular, when there are feature context specific issues, it is > best to handle session re-establishment/re-negotiation/maintenance using > the protocol(s) that were designed to set up the services in the first > place. CT should not be stretched into being a general signalling protocol. > > In addition, there is the perhaps greater argument that the most > effective method of correcting handover issues is not through over > the air signalling exchanges. Given the nature of the wireless link, > it will almost always be faster and always be more cost effective, to > correct any problems with signalling within the infrastructure (if it is > needed). > > Gary > > > -----Original Message----- > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > Sent: April 8, 2002 11:42 > > To: Nakhjiri Madjid-MNAKHJI1; Rajeev Koodli > > Cc: Kenward, Gary [WDLN2:AN10:EXCH]; Hemant.Chaskar@nokia.com; > > nsis@ietf.org; seamoby@ietf.org > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > Madjid, > > > > The issue isn't reliability, it is whether the target AR can interpret > > the context intelligably. If not, the MN may need to recover > > by actually > > re-initializing whatever feature the context was being transfered for. > > But it cannot do this unless it knows that the CT has failed. > > > > For some feature contexts, like header compression, this > > isn't a problem > > because it will re-initialize automatically, but for AAA or QoS it > > clearly will be. > > > > jak > > > > ----- Original Message ----- > > From: "Nakhjiri Madjid-MNAKHJI1" > > To: "'James Kempf'" ; "Rajeev Koodli" > > > > Cc: "Gary Kenward" ; > > ; ; > > Sent: Friday, April 05, 2002 3:00 PM > > Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > > Well, you are opening a can of worm that took seamoby 3 months > > > to close without any results. People could not agree on the > > > reliability needs of CT. We added a reliability mechanism to our > > > CT proposal that covered both retransmission and updates. > > > > > > Madjid > > > > > > -----Original Message----- > > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > > Sent: Friday, April 05, 2002 12:22 PM > > > To: Rajeev Koodli > > > Cc: Gary Kenward; Hemant.Chaskar@nokia.com; nsis@ietf.org; > > > seamoby@ietf.org > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > Agree. > > > > > > But I don't see anything in the CT requirements about handling CT > > > failure. > > > > > > ??? > > > > > > jak > > > > > > ----- Original Message ----- > > > From: "Rajeev Koodli" > > > To: "James Kempf" > > > Cc: "Gary Kenward" ; > > > ; ; > > > Sent: Friday, April 05, 2002 10:02 AM > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > > James Kempf wrote: > > > > > > > > > Rajeev, > > > > > > > > > > I agree, but there is still an issue of how the AR would notify > > the > > > MN > > > > > if CT fails. Is this covered by CT or not? > > > > > > > > > > > > > This notification should be covered by CT. We should offer > > > > seamless handover to NSIS :-) Seriously, this concerns > > > > robustness of CT protocol. > > > > > > > > -Rajeev > > > > > > > > > > > > > > > > > > jak > > > > > > > > > > ----- Original Message ----- > > > > > From: "Rajeev Koodli" > > > > > To: "James Kempf" > > > > > Cc: "Gary Kenward" ; > > > > > ; ; > > > > > Sent: Friday, April 05, 2002 9:19 AM > > > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS > > after handoff. > > > > > > > > > > > > > > > > > Hello Jim, > > > > > > > > > > > > James Kempf wrote: > > > > > > > > > > > > > There is an issue if CT fails. In that case, some kind of > > > > > negotiation > > > > > > > after handover would be required. > > > > > > > > > > > > > > So, I'd say that some indication of CT failure is needed. > > > > > > > > > > > > > > > > > > > Yes, but this is between AR and MN. If CT fails, the AR should > > > > > > notify the MN to engage in context re-creation. > > > > > > > > > > > > My point was specific to signaling _beyond_ AR (i.e., upstream > > > > > signaling) > > > > > > independent of failure/success of CT. > > > > > > > > > > > > Hope this is clearer.. > > > > > > > > > > > > -Rajeev > > > > > > > > > > > > > > > > > > > > > > > > > > As for CAR, I don't see the relevance for QoS negotiation, > > > though it > > > > > may > > > > > > > be useful for finding a new wireless medium. I also see it > > > primarily > > > > > for > > > > > > > intertechnology handover, or, at best, > > interprovider handover. > > > > > > > > > > > > > > jak > > > > > > > ----- Original Message ----- > > > > > > > From: "Rajeev Koodli" > > > > > > > To: "Gary Kenward" > > > > > > > Cc: ; ; > > > > > > > > > > Sent: Friday, April 05, 2002 9:01 AM > > > > > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after > > > handoff. > > > > > > > > > > > > > > > > > > > > > > > Hello, > > > > > > > > > > > > > > > > well, if the issue is QoS establishment after handover, > > > > > > > > > > > > > > > > - CT is applicable for establishing QoS state at the AR > > > > > > > > - if further signaling is desired beyond the AR, NSIS may > > > > > > > > consider it. I don't see how _signaling_ for QoS > > > establishment > > > > > > > > beyond AR is relevant for seamoby. > > > > > > > > > > > > > > > > CAR _discovery_ could exchange QoS capability as > > one of the > > > > > > > > parameters that might then be fed to a selection > > algorithm. > > > Any > > > > > > > > signaling for actually establishing QoS itself > > beyond the AR > > > > > > > > should be outside the scope of seamoby.. > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > > > -Rajeev > > > > > > > > > > > > > > > > > > > > > > > > Gary Kenward wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hemant: > > > > > > > > > > > > > > > > > > Just a point of clarification, but as I > > understand CARD > > > (and > > > > > > > > > I don't understand it well), it is not a QoS negotiation > > > > > > > > > protocol. The main application that you are referring to > > > > > primarily > > > > > > > > > arises out of a perceived need to determine at > > the MN the > > > best > > > > > link > > > > > > > > > layer to handover over to when inter-technology > > handovers > > > are > > > > > > > > > involved. > > > > > > > > > It can be applied to intra-technology handovers, but the > > > value > > > > > in > > > > > > > > > that situation is highly questionable (e.g. > > since it is a > > > > > discovery > > > > > > > > > protocol, the implication is that the purpose is to > > > determine > > > > > the > > > > > > > > > choice of channels available; for intra-technology > > > handovers, > > > > > there > > > > > > > > > are many, many reasons why this "choice" may not be > > > available). > > > > > > > > > > > > > > > > > > There is a requirement, 5.1.2, which seems to > > imply NSIS > > > > > > > involvement > > > > > > > > > > > > > > > > > > during/after a handover. John has stated that > > this is not > > > the > > > > > > > > > intention > > > > > > > > > (please correct me if I have this wrong John), in which > > case > > > I > > > > > think > > > > > > > > > 5.1.2 needs to be clarified. > > > > > > > > > > > > > > > > > > Specifically, is NSIS to be used to negotiated new QoS > > for > > > an > > > > > > > > > existing flow after a handover, or is it > > specifically for > > > > > > > establishing > > > > > > > > > > > > > > > > > > QoS for a new flow? I don't think the answer is boolean: > > the > > > > > role > > > > > > > > > of NSIS in QoS re-negotiation is still open, I believe, > > and > > > > > clearly > > > > > > > > > handover is a dynamic situation that could cause the QoS > > > > > provided to > > > > > > > > > change. > > > > > > > > > > > > > > > > > > I have been told there is no issue, but here's a > > > frightening > > > > > > > > > scenario: > > > > > > > > > > > > > > > > > > - a handover takes place, and context > > transfer has > > > been > > > > > used > > > > > > > > > to > > > > > > > > > move the QoS context to the new routers (by the > > > > > requirements > > > > > > > > > for > > > > > > > > > CT this could be intra-, or inter- > > technology. Some > > > of us > > > > > > > > > believe > > > > > > > > > that for "seamless" handovers, the > > context will be > > > > > available > > > > > > > at > > > > > > > > > > > > > > > > > > routers before the first packets need to be > > > forwarded. > > > > > This > > > > > > > > > implies > > > > > > > > > that there is a relationship, probabilistic > > perhaps, > > > > > between > > > > > > > > > the handover process and the target ARs for CT. > > > > > > > > > > > > > > > > > > - CARD is used by the MN to influence the handover > > > decision > > > > > (it > > > > > > > > > is not clear to me how this happens, but it seems > > > clear > > > > > that > > > > > > > > > for a more "seamless" handover, the MN > > should chose > > > an AR > > > > > > > that > > > > > > > > > has received the appropriate context; if > > not, then > > > what? > > > > > > > > > > > > > > > > > > - NSIS kicks in and starts re-negotiating > > QoS because > > > of > > > > > > > changes > > > > > > > > > introduced by the handover; > > > > > > > > > > > > > > > > > > How do these three protocols interact to produce > > > predictable > > > > > > > > > outcomes? > > > > > > > > > Or, perhaps, the question is, how do the functional > > entities > > > > > > > > > associated > > > > > > > > > with the three protocols interact before, > > during and after > > a > > > > > > > handover? > > > > > > > > > > > > > > > > > > If it the interaction is within the functional entities, > > the > > > > > > > > > respective > > > > > > > > > wg's could declare the issue out of scope, but this > > approach > > > > > does > > > > > > > not > > > > > > > > > sit well with me, for it seems to defer the > > problem to the > > > > > people > > > > > > > who > > > > > > > > > have to implement this "stuff". > > > > > > > > > > > > > > > > > > Am I imagining things? > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > Gary > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: Hemant.Chaskar@nokia.com > > > > > [mailto:Hemant.Chaskar@nokia.com] > > > > > > > > > > Sent: April 4, 2002 22:33 > > > > > > > > > > To: nsis@ietf.org > > > > > > > > > > Subject: RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Sharif: > > > > > > > > > > > > > > > > > > > > There is currently a debate going on in Seamoby as to > > > whether > > > > > > > > > > this QoS negotiation be covered by NSIS or > > Seamoby (CAR > > > > > > > > > > discovery protocol). > > > > > > > > > > > > > > > > > > > > IMHO it should be covered by CAR discovery > > and not NSIS. > > > CAR > > > > > > > > > > discovery is supposed to identify candidate access > > routers > > > > > > > > > > for handoff and QoS is an important property for > > > candidacy. > > > > > > > > > > > > > > > > > > > > Br, > > > > > > > > > > Hemant > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: ext Shahrier, Sharif M. > > > > > > > > > > [mailto:Sharif.Shahrier@InterDigital.com] > > > > > > > > > > Sent: Thursday, April 04, 2002 3:35 PM > > > > > > > > > > To: Shahrier, Sharif M. > > > > > > > > > > Cc: 'nsis@ietf.org' > > > > > > > > > > Subject: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I have a question for clarification. > > > > > > > > > > > > > > > > > > > > I think it was stated that NSIS should only > > be concerned > > > with > > > > > the > > > > > > > > > > establishment of QoS after handoff. > > > > > > > > > > > > > > > > > > > > This is inconvienent with respect to IP-level QoS > > > > > > > > > > negotiation, which ideally > > > > > > > > > > should be done before handoff has taken place. > > > > > > > > > > > > > > > > > > > > QoS negotiation is in the current requirements draft. > > > > > > > > > > > > > > > > > > > > So, NSIS signaling protocol development should be > > > concerned > > > > > > > > > > with activity > > > > > > > > > > before handoff occurs. > > > > > > > > > > > > > > > > > > > > Sharif. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > Seamoby mailing list > > > > > > > > Seamoby@ietf.org > > > > > > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > Seamoby mailing list > > > > > > Seamoby@ietf.org > > > > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Seamoby mailing list > > > > Seamoby@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > > > > > _______________________________________________ > > > Seamoby mailing list > > > Seamoby@ietf.org > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > _______________________________________________ > > > Seamoby mailing list > > > Seamoby@ietf.org > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Tue Apr 9 17:23:42 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23327 for ; Tue, 9 Apr 2002 17:23:42 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA22216 for nsis-archive@odin.ietf.org; Tue, 9 Apr 2002 17:23:45 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA21179; Tue, 9 Apr 2002 17:06:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA21091 for ; Tue, 9 Apr 2002 17:06:23 -0400 (EDT) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22643; Tue, 9 Apr 2002 17:06:19 -0400 (EDT) Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate.mot.com (motgate 2.1) with ESMTP id OAA13133; Tue, 9 Apr 2002 14:06:18 -0700 (MST)] Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id NAA17925; Tue, 9 Apr 2002 13:53:56 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2654.52) id <2NG85VMD>; Tue, 9 Apr 2002 16:06:18 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B04650057@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'James Kempf'" , Gary Kenward , "'Rajeev Koodli'" , Nakhjiri Madjid-MNAKHJI1 Cc: nsis@ietf.org, seamoby@ietf.org Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Tue, 9 Apr 2002 16:06:13 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org James, I think if the newAR does not have enough bandwidth for the MN, there should not be a handover (that is why CAR needs to handle capability issues as I said before). I wonder in such a case, would it not be easier to just redo QoS signaling based on some NSIS-like protocol. We are not insisting on absolutely do CT until the end of time, regardless of how many time it fails. The design must be flexible enough to handle handover delays as much as possible. I must say that if you make a simple concept such as context transfer to be handled by a too complicate protocol, people will not use it. So it is your choice. I was not at the last IETF and the meeting minutes have not been posted to the list, can you tell me when and how the CT selection process is going to happen? Regards, Madjid -----Original Message----- From: James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Monday, April 08, 2002 1:26 PM To: Gary Kenward; 'Rajeev Koodli'; Nakhjiri Madjid-MNAKHJI1 Cc: Hemant.Chaskar@nokia.com; nsis@ietf.org; seamoby@ietf.org Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Gary, I don't think the issue is having the MN re-create the context. Is is allowing the MN to recover by re-running the actions that were necessary to create the context in the first place, in the event the AR was unable to interpret it. Thus, for example, suppose that QoS context is transferred from old to new AR, but new AR for some reason can't interpret it, perhaps there is no bandwidth left or perhaps the new AR uses a different representation for QoS context. The MN would need to be informed somehow so that it could re-do its QoS signaling. jak ----- Original Message ----- From: "Gary Kenward" To: "'Rajeev Koodli'" ; "Nakhjiri Madjid-MNAKHJI1" Cc: ; ; Sent: Monday, April 08, 2002 10:54 AM Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > Rajeev: > > In order for the MN to "recreate the context", the MN would > have to understand the semantics of Context transfer, etc., > and, more important, there would have to be a protocol or > protocols that would allow the MN to recreate contexts at an AR. > I doubt that the latter is going to happen (e.g. authentication). > > IF and when a CT fails, the easiest way to "recreate" context > is for the sessions to be dropped. This may seem drastic, > but in reality, what is going to cause CT to fail and > how often will this happen? > > There may be mitigating actions that could be taken to re-establish > certain sessions. But these decisions are must be driven by the policy > of the network administration (explicit or implicity), and comply > with the security, resource management and accounting requirements > for the network. Hopefully, none of these mitigating actions requires > more over-the-air signalling. > > Gary > > > -----Original Message----- > > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] > > Sent: April 5, 2002 17:46 > > To: Nakhjiri Madjid-MNAKHJI1 > > Cc: Kenward, Gary [WDLN2:AN10:EXCH]; Hemant.Chaskar@nokia.com; > > nsis@ietf.org; seamoby@ietf.org > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > > > Hello Madjid, > > > > Nakhjiri Madjid-MNAKHJI1 wrote: > > > > > Hello Rajeev, > > > > > > I agreed with everything you say below, except one thing: > > > CT can only transfer whatever QoS state that is usable at the newAR. > > > If the new network is using a different QoS technology with > > different > > > QoS parameters, then I am not sure if CT by itself can do > > the job, unless > > > you add your own mapping functionality. > > > > > > > This would be an example where the new AR sends a > > notification to the MN so that the MN can take > > appropriate action (for instance, attempt to > > re-create the context). > > > > Regards, > > > > -Rajeev > > > > > > > > > > BR, > > > Madjid > > > > > > -----Original Message----- > > > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] > > > Sent: Friday, April 05, 2002 11:01 AM > > > To: Gary Kenward > > > Cc: Hemant.Chaskar@nokia.com; nsis@ietf.org; seamoby@ietf.org > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > Hello, > > > > > > well, if the issue is QoS establishment after handover, > > > > > > - CT is applicable for establishing QoS state at the AR > > > - if further signaling is desired beyond the AR, NSIS may > > > consider it. I don't see how _signaling_ for QoS establishment > > > beyond AR is relevant for seamoby. > > > > > > CAR _discovery_ could exchange QoS capability as one of the > > > parameters that might then be fed to a selection algorithm. Any > > > signaling for actually establishing QoS itself beyond the AR > > > should be outside the scope of seamoby.. > > > > > > Regards, > > > > > > -Rajeev > > > > > > Gary Kenward wrote: > > > > > > > > > > > > > > > Hemant: > > > > > > > > Just a point of clarification, but as I understand CARD (and > > > > I don't understand it well), it is not a QoS negotiation > > > > protocol. The main application that you are referring to primarily > > > > arises out of a perceived need to determine at the MN the > > best link > > > > layer to handover over to when inter-technology handovers are > > > > involved. > > > > It can be applied to intra-technology handovers, but the value in > > > > that situation is highly questionable (e.g. since it is a > > discovery > > > > protocol, the implication is that the purpose is to determine the > > > > choice of channels available; for intra-technology > > handovers, there > > > > are many, many reasons why this "choice" may not be available). > > > > > > > > There is a requirement, 5.1.2, which seems to imply > > NSIS involvement > > > > > > > > during/after a handover. John has stated that this is not the > > > > intention > > > > (please correct me if I have this wrong John), in which > > case I think > > > > 5.1.2 needs to be clarified. > > > > > > > > Specifically, is NSIS to be used to negotiated new QoS for an > > > > existing flow after a handover, or is it specifically for > > establishing > > > > > > > > QoS for a new flow? I don't think the answer is boolean: the role > > > > of NSIS in QoS re-negotiation is still open, I believe, > > and clearly > > > > handover is a dynamic situation that could cause the QoS > > provided to > > > > change. > > > > > > > > I have been told there is no issue, but here's a frightening > > > > scenario: > > > > > > > > - a handover takes place, and context transfer > > has been used > > > > to > > > > move the QoS context to the new routers (by the > > requirements > > > > for > > > > CT this could be intra-, or inter- technology. Some of us > > > > believe > > > > that for "seamless" handovers, the context will be > > available at > > > > > > > > routers before the first packets need to be forwarded. This > > > > implies > > > > that there is a relationship, probabilistic > > perhaps, between > > > > the handover process and the target ARs for CT. > > > > > > > > - CARD is used by the MN to influence the handover > > decision (it > > > > is not clear to me how this happens, but it seems > > clear that > > > > for a more "seamless" handover, the MN should > > chose an AR that > > > > has received the appropriate context; if not, then what? > > > > > > > > - NSIS kicks in and starts re-negotiating QoS > > because of changes > > > > introduced by the handover; > > > > > > > > How do these three protocols interact to produce predictable > > > > outcomes? > > > > Or, perhaps, the question is, how do the functional entities > > > > associated > > > > with the three protocols interact before, during and > > after a handover? > > > > > > > > If it the interaction is within the functional entities, the > > > > respective > > > > wg's could declare the issue out of scope, but this > > approach does not > > > > sit well with me, for it seems to defer the problem to > > the people who > > > > have to implement this "stuff". > > > > > > > > Am I imagining things? > > > > > > > > Cheers, > > > > Gary > > > > > > > > > -----Original Message----- > > > > > From: Hemant.Chaskar@nokia.com [mailto:Hemant.Chaskar@nokia.com] > > > > > Sent: April 4, 2002 22:33 > > > > > To: nsis@ietf.org > > > > > Subject: RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > > > Hi Sharif: > > > > > > > > > > There is currently a debate going on in Seamoby as to whether > > > > > this QoS negotiation be covered by NSIS or Seamoby (CAR > > > > > discovery protocol). > > > > > > > > > > IMHO it should be covered by CAR discovery and not NSIS. CAR > > > > > discovery is supposed to identify candidate access routers > > > > > for handoff and QoS is an important property for candidacy. > > > > > > > > > > Br, > > > > > Hemant > > > > > > > > > > -----Original Message----- > > > > > From: ext Shahrier, Sharif M. > > > > > [mailto:Sharif.Shahrier@InterDigital.com] > > > > > Sent: Thursday, April 04, 2002 3:35 PM > > > > > To: Shahrier, Sharif M. > > > > > Cc: 'nsis@ietf.org' > > > > > Subject: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > > > > > > > > I have a question for clarification. > > > > > > > > > > I think it was stated that NSIS should only be > > concerned with the > > > > > establishment of QoS after handoff. > > > > > > > > > > This is inconvienent with respect to IP-level QoS > > > > > negotiation, which ideally > > > > > should be done before handoff has taken place. > > > > > > > > > > QoS negotiation is in the current requirements draft. > > > > > > > > > > So, NSIS signaling protocol development should be concerned > > > > > with activity > > > > > before handoff occurs. > > > > > > > > > > Sharif. > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > 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 > > > > > > > > > > > _______________________________________________ > > > Seamoby mailing list > > > Seamoby@ietf.org > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > _______________________________________________ > > > Seamoby mailing list > > > Seamoby@ietf.org > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Tue Apr 9 17:37:21 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23888 for ; Tue, 9 Apr 2002 17:37:21 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA23510 for nsis-archive@odin.ietf.org; Tue, 9 Apr 2002 17:37:25 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA22523; Tue, 9 Apr 2002 17:28:20 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA22390 for ; Tue, 9 Apr 2002 17:28:11 -0400 (EDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23469; Tue, 9 Apr 2002 17:28:06 -0400 (EDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id OAA14442; Tue, 9 Apr 2002 14:27:38 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g39LRbD23390; Tue, 9 Apr 2002 14:27:37 -0700 X-mProtect: <200204092127> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdqatjt3; Tue, 09 Apr 2002 14:27:35 PDT Message-ID: <3CB35CC7.4F017391@iprg.nokia.com> Date: Tue, 09 Apr 2002 14:27:36 -0700 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Nakhjiri Madjid-MNAKHJI1 CC: "'James Kempf'" , Gary Kenward , Hemant.Chaskar@nokia.com, nsis@ietf.org, seamoby@ietf.org Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. References: <35DBB8B7AC89D4118E98009027B1009B04650058@IL27EXM10.cig.mot.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit Nakhjiri Madjid-MNAKHJI1 wrote: > all you have to do is to add a CT-NACK, > please, look at our TEXT proposal. > We even have a CT-NACK for each feature. Right. A simple notification message would suffice. BTW, in our framework we call it CTIN-Ack now (Section 5.2); earlier versions (going back to Pittsburgh IETF) called it SHACK :-) Regards, -Rajeev > > > madjid > > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: Monday, April 08, 2002 1:32 PM > To: Gary Kenward; Nakhjiri Madjid-MNAKHJI1; Rajeev Koodli > Cc: Hemant.Chaskar@nokia.com; nsis@ietf.org; seamoby@ietf.org > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > Gary, > > I agree about session establishment, but the fact remains that if > failure of a context transfer for some reason leaves the MN without any > indication that it should proceed to re-establish the feature, then the > MN can't know when it should redo signaling to set up its new state. We > faced this issue with BETH/FMIPv6 and the solution we found there was to > have routers on the border of a fast handover coverage area inform the > MN what handover algorithm was supported by routers in the other > coverage area. While I think this could be done for the cases involving > router configuration, such as where the next access router can't > interpret the context, I am not so sure about failure due to dynamic > conditions, such as that the router currently has all its Gold Class > service bandwidth allocated (a QoS failure). > > In any event, I think there is need for some kind of signaling to > indicate to the MN that context transfer has failed and that the MN > needs to redo signaling to re-establish feature contexts. > > jak > > ----- Original Message ----- > From: "Gary Kenward" > To: "'James Kempf'" ; "Nakhjiri > Madjid-MNAKHJI1" ; "Rajeev Koodli" > > Cc: ; ; > Sent: Monday, April 08, 2002 11:08 AM > Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > James: > > > > My main problem with the theme in this discussion is that > > CT is a context transfer protocol, not a session management protocol. > > In particular, when there are feature context specific issues, it is > > best to handle session re-establishment/re-negotiation/maintenance > using > > the protocol(s) that were designed to set up the services in the first > > place. CT should not be stretched into being a general signalling > protocol. > > > > In addition, there is the perhaps greater argument that the most > > effective method of correcting handover issues is not through over > > the air signalling exchanges. Given the nature of the wireless link, > > it will almost always be faster and always be more cost effective, to > > correct any problems with signalling within the infrastructure (if it > is > > needed). > > > > Gary > > > > > -----Original Message----- > > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > > Sent: April 8, 2002 11:42 > > > To: Nakhjiri Madjid-MNAKHJI1; Rajeev Koodli > > > Cc: Kenward, Gary [WDLN2:AN10:EXCH]; Hemant.Chaskar@nokia.com; > > > nsis@ietf.org; seamoby@ietf.org > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > Madjid, > > > > > > The issue isn't reliability, it is whether the target AR can > interpret > > > the context intelligably. If not, the MN may need to recover > > > by actually > > > re-initializing whatever feature the context was being transfered > for. > > > But it cannot do this unless it knows that the CT has failed. > > > > > > For some feature contexts, like header compression, this > > > isn't a problem > > > because it will re-initialize automatically, but for AAA or QoS it > > > clearly will be. > > > > > > jak > > > > > > ----- Original Message ----- > > > From: "Nakhjiri Madjid-MNAKHJI1" > > > To: "'James Kempf'" ; "Rajeev Koodli" > > > > > > Cc: "Gary Kenward" ; > > > ; ; > > > Sent: Friday, April 05, 2002 3:00 PM > > > Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > > Well, you are opening a can of worm that took seamoby 3 months > > > > to close without any results. People could not agree on the > > > > reliability needs of CT. We added a reliability mechanism to our > > > > CT proposal that covered both retransmission and updates. > > > > > > > > Madjid > > > > > > > > -----Original Message----- > > > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > > > Sent: Friday, April 05, 2002 12:22 PM > > > > To: Rajeev Koodli > > > > Cc: Gary Kenward; Hemant.Chaskar@nokia.com; nsis@ietf.org; > > > > seamoby@ietf.org > > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > Agree. > > > > > > > > But I don't see anything in the CT requirements about handling CT > > > > failure. > > > > > > > > ??? > > > > > > > > jak > > > > > > > > ----- Original Message ----- > > > > From: "Rajeev Koodli" > > > > To: "James Kempf" > > > > Cc: "Gary Kenward" ; > > > > ; ; > > > > Sent: Friday, April 05, 2002 10:02 AM > > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > James Kempf wrote: > > > > > > > > > > > Rajeev, > > > > > > > > > > > > I agree, but there is still an issue of how the AR would > notify > > > the > > > > MN > > > > > > if CT fails. Is this covered by CT or not? > > > > > > > > > > > > > > > > This notification should be covered by CT. We should offer > > > > > seamless handover to NSIS :-) Seriously, this concerns > > > > > robustness of CT protocol. > > > > > > > > > > -Rajeev > > > > > > > > > > > > > > > > > > > > > > jak > > > > > > > > > > > > ----- Original Message ----- > > > > > > From: "Rajeev Koodli" > > > > > > To: "James Kempf" > > > > > > Cc: "Gary Kenward" ; > > > > > > ; ; > > > > > > > Sent: Friday, April 05, 2002 9:19 AM > > > > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS > > > after handoff. > > > > > > > > > > > > > > > > > > > > Hello Jim, > > > > > > > > > > > > > > James Kempf wrote: > > > > > > > > > > > > > > > There is an issue if CT fails. In that case, some kind of > > > > > > negotiation > > > > > > > > after handover would be required. > > > > > > > > > > > > > > > > So, I'd say that some indication of CT failure is needed. > > > > > > > > > > > > > > > > > > > > > > Yes, but this is between AR and MN. If CT fails, the AR > should > > > > > > > notify the MN to engage in context re-creation. > > > > > > > > > > > > > > My point was specific to signaling _beyond_ AR (i.e., > upstream > > > > > > signaling) > > > > > > > independent of failure/success of CT. > > > > > > > > > > > > > > Hope this is clearer.. > > > > > > > > > > > > > > -Rajeev > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > As for CAR, I don't see the relevance for QoS negotiation, > > > > though it > > > > > > may > > > > > > > > be useful for finding a new wireless medium. I also see it > > > > primarily > > > > > > for > > > > > > > > intertechnology handover, or, at best, > > > interprovider handover. > > > > > > > > > > > > > > > > jak > > > > > > > > ----- Original Message ----- > > > > > > > > From: "Rajeev Koodli" > > > > > > > > To: "Gary Kenward" > > > > > > > > Cc: ; ; > > > > > > > > > > > > Sent: Friday, April 05, 2002 9:01 AM > > > > > > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after > > > > handoff. > > > > > > > > > > > > > > > > > > > > > > > > > > Hello, > > > > > > > > > > > > > > > > > > well, if the issue is QoS establishment after handover, > > > > > > > > > > > > > > > > > > - CT is applicable for establishing QoS state at the AR > > > > > > > > > - if further signaling is desired beyond the AR, NSIS > may > > > > > > > > > consider it. I don't see how _signaling_ for QoS > > > > establishment > > > > > > > > > beyond AR is relevant for seamoby. > > > > > > > > > > > > > > > > > > CAR _discovery_ could exchange QoS capability as > > > one of the > > > > > > > > > parameters that might then be fed to a selection > > > algorithm. > > > > Any > > > > > > > > > signaling for actually establishing QoS itself > > > beyond the AR > > > > > > > > > should be outside the scope of seamoby.. > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > > > > > -Rajeev > > > > > > > > > > > > > > > > > > > > > > > > > > > Gary Kenward wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hemant: > > > > > > > > > > > > > > > > > > > > Just a point of clarification, but as I > > > understand CARD > > > > (and > > > > > > > > > > I don't understand it well), it is not a QoS > negotiation > > > > > > > > > > protocol. The main application that you are referring > to > > > > > > primarily > > > > > > > > > > arises out of a perceived need to determine at > > > the MN the > > > > best > > > > > > link > > > > > > > > > > layer to handover over to when inter-technology > > > handovers > > > > are > > > > > > > > > > involved. > > > > > > > > > > It can be applied to intra-technology handovers, but > the > > > > value > > > > > > in > > > > > > > > > > that situation is highly questionable (e.g. > > > since it is a > > > > > > discovery > > > > > > > > > > protocol, the implication is that the purpose is to > > > > determine > > > > > > the > > > > > > > > > > choice of channels available; for intra-technology > > > > handovers, > > > > > > there > > > > > > > > > > are many, many reasons why this "choice" may not be > > > > available). > > > > > > > > > > > > > > > > > > > > There is a requirement, 5.1.2, which seems to > > > imply NSIS > > > > > > > > involvement > > > > > > > > > > > > > > > > > > > > during/after a handover. John has stated that > > > this is not > > > > the > > > > > > > > > > intention > > > > > > > > > > (please correct me if I have this wrong John), in > which > > > case > > > > I > > > > > > think > > > > > > > > > > 5.1.2 needs to be clarified. > > > > > > > > > > > > > > > > > > > > Specifically, is NSIS to be used to negotiated new > QoS > > > for > > > > an > > > > > > > > > > existing flow after a handover, or is it > > > specifically for > > > > > > > > establishing > > > > > > > > > > > > > > > > > > > > QoS for a new flow? I don't think the answer is > boolean: > > > the > > > > > > role > > > > > > > > > > of NSIS in QoS re-negotiation is still open, I > believe, > > > and > > > > > > clearly > > > > > > > > > > handover is a dynamic situation that could cause the > QoS > > > > > > provided to > > > > > > > > > > change. > > > > > > > > > > > > > > > > > > > > I have been told there is no issue, but here's a > > > > frightening > > > > > > > > > > scenario: > > > > > > > > > > > > > > > > > > > > - a handover takes place, and context > > > transfer has > > > > been > > > > > > used > > > > > > > > > > to > > > > > > > > > > move the QoS context to the new routers (by the > > > > > > requirements > > > > > > > > > > for > > > > > > > > > > CT this could be intra-, or inter- > > > technology. Some > > > > of us > > > > > > > > > > believe > > > > > > > > > > that for "seamless" handovers, the > > > context will be > > > > > > available > > > > > > > > at > > > > > > > > > > > > > > > > > > > > routers before the first packets need to be > > > > forwarded. > > > > > > This > > > > > > > > > > implies > > > > > > > > > > that there is a relationship, probabilistic > > > perhaps, > > > > > > between > > > > > > > > > > the handover process and the target ARs for CT. > > > > > > > > > > > > > > > > > > > > - CARD is used by the MN to influence the > handover > > > > decision > > > > > > (it > > > > > > > > > > is not clear to me how this happens, but it > seems > > > > clear > > > > > > that > > > > > > > > > > for a more "seamless" handover, the MN > > > should chose > > > > an AR > > > > > > > > that > > > > > > > > > > has received the appropriate context; if > > > not, then > > > > what? > > > > > > > > > > > > > > > > > > > > - NSIS kicks in and starts re-negotiating > > > QoS because > > > > of > > > > > > > > changes > > > > > > > > > > introduced by the handover; > > > > > > > > > > > > > > > > > > > > How do these three protocols interact to produce > > > > predictable > > > > > > > > > > outcomes? > > > > > > > > > > Or, perhaps, the question is, how do the functional > > > entities > > > > > > > > > > associated > > > > > > > > > > with the three protocols interact before, > > > during and after > > > a > > > > > > > > handover? > > > > > > > > > > > > > > > > > > > > If it the interaction is within the functional > entities, > > > the > > > > > > > > > > respective > > > > > > > > > > wg's could declare the issue out of scope, but this > > > approach > > > > > > does > > > > > > > > not > > > > > > > > > > sit well with me, for it seems to defer the > > > problem to the > > > > > > people > > > > > > > > who > > > > > > > > > > have to implement this "stuff". > > > > > > > > > > > > > > > > > > > > Am I imagining things? > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > Gary > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > From: Hemant.Chaskar@nokia.com > > > > > > [mailto:Hemant.Chaskar@nokia.com] > > > > > > > > > > > Sent: April 4, 2002 22:33 > > > > > > > > > > > To: nsis@ietf.org > > > > > > > > > > > Subject: RE: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Sharif: > > > > > > > > > > > > > > > > > > > > > > There is currently a debate going on in Seamoby as > to > > > > whether > > > > > > > > > > > this QoS negotiation be covered by NSIS or > > > Seamoby (CAR > > > > > > > > > > > discovery protocol). > > > > > > > > > > > > > > > > > > > > > > IMHO it should be covered by CAR discovery > > > and not NSIS. > > > > CAR > > > > > > > > > > > discovery is supposed to identify candidate access > > > routers > > > > > > > > > > > for handoff and QoS is an important property for > > > > candidacy. > > > > > > > > > > > > > > > > > > > > > > Br, > > > > > > > > > > > Hemant > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > From: ext Shahrier, Sharif M. > > > > > > > > > > > [mailto:Sharif.Shahrier@InterDigital.com] > > > > > > > > > > > Sent: Thursday, April 04, 2002 3:35 PM > > > > > > > > > > > To: Shahrier, Sharif M. > > > > > > > > > > > Cc: 'nsis@ietf.org' > > > > > > > > > > > Subject: [NSIS] Establishing QoS after handoff. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I have a question for clarification. > > > > > > > > > > > > > > > > > > > > > > I think it was stated that NSIS should only > > > be concerned > > > > with > > > > > > the > > > > > > > > > > > establishment of QoS after handoff. > > > > > > > > > > > > > > > > > > > > > > This is inconvienent with respect to IP-level QoS > > > > > > > > > > > negotiation, which ideally > > > > > > > > > > > should be done before handoff has taken place. > > > > > > > > > > > > > > > > > > > > > > QoS negotiation is in the current requirements > draft. > > > > > > > > > > > > > > > > > > > > > > So, NSIS signaling protocol development should be > > > > concerned > > > > > > > > > > > with activity > > > > > > > > > > > before handoff occurs. > > > > > > > > > > > > > > > > > > > > > > Sharif. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > Seamoby mailing list > > > > > > > > > Seamoby@ietf.org > > > > > > > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > Seamoby mailing list > > > > > > > Seamoby@ietf.org > > > > > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Seamoby mailing list > > > > > Seamoby@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Seamoby mailing list > > > > Seamoby@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > _______________________________________________ > > > > Seamoby mailing list > > > > Seamoby@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > > > > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Tue Apr 9 17:57:59 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24266 for ; Tue, 9 Apr 2002 17:57:59 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA24142 for nsis-archive@odin.ietf.org; Tue, 9 Apr 2002 17:58:00 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA23859; Tue, 9 Apr 2002 17:49:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA23798 for ; Tue, 9 Apr 2002 17:49:55 -0400 (EDT) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24116; Tue, 9 Apr 2002 17:49:50 -0400 (EDT) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g39LmLI19600; Tue, 9 Apr 2002 14:48:21 -0700 (PDT) Message-ID: <02c801c1e010$0a7590a0$7e6015ac@T23KEMPF> From: "James Kempf" To: "Gary Kenward" , "'Rajeev Koodli'" , "Nakhjiri Madjid-MNAKHJI1" Cc: , , References: <9FBD322B7824D511B36900508BF93C9C01AA4A0C@zcard031.ca.nortel.com> Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. Date: Tue, 9 Apr 2002 14:46:44 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit Gary, I'd be happy with: o CT is impossible to do with new AR for some reason, perhaps failure of a specific feature context, perhaps new AR is in a different administrative domain, etc. o New AR notifies MN that it must redo network admission to get back up its state, i.e. go back to the initial state before it entered the network. but I would rather have: o CT fails for a specific feature context. o New AR notifies MN that it must redo signaling for that specific feature only. I think 1) is unavoidable for cases such as when an MN goes from one operator's domain to another, and the two have no business agreement allowing CT between them. I think 2) would be nice to have to smooth corner cases, such as new AR runs out of a particular QoS allocation. But I am sensitive that 2) should be handled by the particular feature, i.e. if CT fails to transfer session keys, then the specific AAA feature context code could perform the notification. jak ----- Original Message ----- From: "Gary Kenward" To: "'James Kempf'" ; "'Rajeev Koodli'" ; "Nakhjiri Madjid-MNAKHJI1" Cc: ; ; Sent: Tuesday, April 09, 2002 12:49 PM Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > James: > > > -----Original Message----- > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > Sent: April 9, 2002 15:01 > > To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Rajeev Koodli'; Nakhjiri > > Madjid-MNAKHJI1 > > Cc: Hemant.Chaskar@nokia.com; nsis@ietf.org; seamoby@ietf.org > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff. > > > > > > Gary, > > > > > Sorry, but I am a bit confused (as usual), are you saying > > > then that doing these functions with the CT protocol is less > > > heavyweight, and thus preferable? > > > > > > > No, I'm saying that "dropping the session" is more > > heavyweight. And what > > Agreed. It would be better to try and fix things first. The real > question is at what level. > > > do you mean by a session anyway? > > IP is connectionless. > > Well...sessions do not require connections. But I have a feeling > we both do not want to open up that can-of-worms debate. > > When I say "session", I mean all the collection of services/resources > that have been set up to support an IP flow, QoS, AAA, HC, etc. > If you have a better word, I'll use it. > > > > > I think what you mean is that all feature contexts for the MN > > revert to > > the startup state, namely gone. > > Ok. Except, that it may be only the feature contexts for a given > microflow. E.g just because a new AR cannot support EF PHB, does > not mean that the BE flows need to be dropped. > > > > > > The default action, always, is for the session to be dropped. > > > This will ultimately force the MN to take action (oh, ok, some > > > MNs will simply halt and catch fire). Anything more then dropping > > > the session is simply to improve the handover performance under > > > various conditions. Typically, when one gets into exception > > scenarios, > > > the solutions become too complex or degrade performance too much > > > to be justified against the potential gains. A classic example is > > > run time type/value checking in C/C++. > > > > > > > My point is, if the MN never finds out about this, then it can't take > > any action. > > My points is that this is not a CT protocol function. There are any > number of failure points for a service feature, and it is the responsibility > of the control entity for that service feature to notify the MN. > > > > > > If there are no recovery mechanisms for the potential faults > > > you describe, then does it make sense to build one into CT? > > > On the other hand, if these mechanisms are built into the handover > > > algorithm, or into the session support, then putting it into CT > > > would be redundant, would it not? > > > > > > > I'm not saying that there should be recovery built into CT. What I am > > saying is > > that the MN has got to know when it has to redo signaling in order to > > reestablish > > stuff like it's AAA state or it's QoS state. > > see comment above. > > But, btw: how does the MN re-establish state without dropping the flow? > E.g. authentication? authorization? does re-establishing EF PHB make > any sense (if you cannot do it within a 100 ms, has the service not > been "dropped" anyway?) > > > > > We went through this exact conversation on the MIP list with > > respect to > > BETH. The > > MN doesn't get involved in handover with BETH, so it needs to be > > informed when > > BETH handover fails (in practice, we tell it when BETH > > handover is about > > to fail). > > Then it can do standard MIP signaling in order to get a care > > of address. > > > > I'm willing to grant that having CT do feature by feature failure > > notification doesn't make sense, > > but I still think there needs to be some way to tell the MN that > > seamlessness has failed > > or is about to fail so it can take the right steps to restart the > > original network admission > > procedure. > > > > I think this is needed if for no other reason than when the MN reaches > > the edge of the operator's > > domain, if the operator doesn't have the right business > > agreements with > > the next operator, the MN > > has got to know to redo network entry, i.e. AAA from scratch, QoS from > > scratch, etc. > > We agree on the first part of these two paragraphs. But, I am confused: > I am not aware of any current facilities within QoS/AAA that allows the MN > to repair AAA/QoS state as opposed to "building it from scratch". Certainly, > protocols can be extended, but then, they can also be extended to allow > for notification. > > Consider: > > o CT fails for a specific context > > o CT somehow sends notification that the context for QoS has failed. > > o MN determines (somehow) what this failure message means (again, > consider that > CT can, at best, notify that a particular data chunk failed somehow at the > new AR, > not why). > > o MN initiates a re-negotiation with the appropriate network entity (AAA > server > perhaps? an QoS Controller perhaps?) > > Versus: > > o CT fails for a specific context > > o service feature entity at new AR determines that it is unable to > support > one or more of the MN flows either because it does not have the > context, > or because it cannot support the context > > o new AR determines, perhaps using local policy decisions, what > mitigating > action can to be taken locally (e.g. downgrade an AF flow to a BE flow > to > support forwarding until new negotiations can take place). > > - OR - > > o new AR determines, perhaps using local policy decisions, that the > control > entity for the feature (e.g. the AAA server), needs to be notified > (e.g. > the service lacks proper authorization), the control entity can then > take > direct action (e.g. perhaps by some inter-system authorization > exchange). > > - OR - > > o new AR determines, perhaps using local policy decisions, that the MN is > should fix the problem, and sends a notification. > > Which scenario appears more flexible, more responsive, and more likely to > support seamless handovers? > > Gary > > > > > jak > > > > > > > > _______________________________________________ > > 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 daemon@optimus.ietf.org Tue Apr 9 18:42:42 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24959 for ; Tue, 9 Apr 2002 18:42:42 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA26150 for nsis-archive@odin.ietf.org; Tue, 9 Apr 2002 18:42:44 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA25589; Tue, 9 Apr 2002 18:30:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA25552 for ; Tue, 9 Apr 2002 18:30:28 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24784 for ; Tue, 9 Apr 2002 18:30:25 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g39MTng20396; Tue, 9 Apr 2002 18:29:49 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 9 Apr 2002 18:29:49 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4A12@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'James M. Polk'" Cc: "'nsis@ietf.org'" Subject: RE: [NSIS] attempted summary of pre-emption thread Date: Tue, 9 Apr 2002 18:29:49 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1E015.49F9CDCC" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1E015.49F9CDCC Content-Type: text/plain; charset="iso-8859-1" First of all, it's not "my working group". Second, I can list at least a dozen wg's which someone at the IETF has stated should should not exist or will never be productive. Many have completed their work and the results are being put to practice. Minority opinions abound in the IETF. Second, perhaps you might actually identify the so called "capability" that you refer too instead of throwing petty invectives around. So far, all anyone has heard is a suggestion for a new type of QoS, which is not in the charter. The IETF has at least two wg's looking at QoS, and they do not need another. If pre-emption is so important, why not propose it to the Diff Serv wg? Gary Kenward -----Original Message----- From: James M. Polk [mailto:jmpolk@cisco.com] Sent: April 9, 2002 17:26 To: Kenward, Gary [WDLN2:AN10:EXCH] Subject: RE: [NSIS] attempted summary of pre-emption thread At 04:01 PM 4/9/2002 -0400, you wrote: This is a very different approach from SS7, UNI, SSCPS, GSM, UMTS, .... IP is an internetworking protocol, and must work across many different networks. NSIS should also work across all (predominant) networks. Given the alternative of defining variants of the protocol for every network, it is often more productive to define a generic capability, and leave the network specific stuff to the respective SDOs. Regards, Gary I really have no skin in this game and don't really care if you bury your head in the sand about this -- it'll just force whoever wants this capability to *not* look to NSIS for a solution. I was suggesting that this be an option, not even mandatory to implement, and you shut the suggestion down.... What you are doing is siding with the idealist engineering aspect of this question, and not including any pragmatic or business aspects.... I've heard directly from several people that I respect within the IETF at IETF meetings they themselves don't have a lot of faith in your WG producing anything of substance, if anything at all..... you're proving them right to me now ************************************* "People generally demand more respect for their own rights than they are willing to allow for others" James M. Polk Consulting Engineer Office of the CTO Cisco Systems 2200 East President George Bush Turnpike Richardson, TX 75082 USA w) 972.813.5208 f) 972.813.5280 www.cisco.com ------_=_NextPart_001_01C1E015.49F9CDCC Content-Type: text/html; charset="iso-8859-1"
First of all, it's not "my working group".  Second, I can list at least a dozen wg's which someone at
the IETF has stated should should not exist or will never be productive. Many have
completed their work and the results are being put to practice. Minority opinions abound in the IETF.
 
Second, perhaps you might actually identify the so called "capability" that you refer too instead of
throwing petty invectives around. So far, all anyone has heard is a suggestion for a new type of QoS,
which is not in the charter. The IETF has at least two wg's looking at QoS, and they do not need another.
If pre-emption is so important, why not propose it to the Diff Serv wg?
 
Gary Kenward
-----Original Message-----
From: James M. Polk [mailto:jmpolk@cisco.com]
Sent: April 9, 2002 17:26
To: Kenward, Gary [WDLN2:AN10:EXCH]
Subject: RE: [NSIS] attempted summary of pre-emption thread

At 04:01 PM 4/9/2002 -0400, you wrote:


  This is a very different approach from SS7, UNI, SSCPS, GSM, UMTS, .... IP is an
internetworking protocol, and must work across many different networks. NSIS should
also work across all (predominant) networks. Given the alternative of defining variants
of the protocol for every network, it is often more productive to define a generic capability,
and leave the network specific stuff to the respective SDOs.

Regards,
Gary

I really have no skin in this game and don't really care if you bury your head in the sand about this -- it'll just force whoever wants this capability to *not* look to NSIS for a solution. I was suggesting that this be an option, not even mandatory to implement, and you shut the suggestion down.... What you are doing is siding with the idealist engineering aspect of this question, and not including any pragmatic or business aspects....

I've heard directly from several people that I respect within the IETF at IETF meetings they themselves don't have a lot of faith in your WG producing anything of substance, if anything at all..... you're proving them right to me now

*************************************
"People generally demand more respect for their own rights than they are willing to allow for others"

James M. Polk
Consulting Engineer
Office of the CTO

Cisco Systems
2200 East President George Bush Turnpike
Richardson, TX  75082 USA
w) 972.813.5208
f)  972.813.5280
www.cisco.com
------_=_NextPart_001_01C1E015.49F9CDCC-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Tue Apr 9 19:26:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25620 for ; Tue, 9 Apr 2002 19:26:27 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA28278 for nsis-archive@odin.ietf.org; Tue, 9 Apr 2002 19:26:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA27988; Tue, 9 Apr 2002 19:19:12 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA27955 for ; Tue, 9 Apr 2002 19:19:08 -0400 (EDT) Received: from mailserver.KOM.e-technik.tu-darmstadt.de (drum.kom.e-technik.tu-darmstadt.de [130.83.139.190]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25513 for ; Tue, 9 Apr 2002 19:19:07 -0400 (EDT) Received: from KOM.tu-darmstadt.de by mailserver.KOM.e-technik.tu-darmstadt.de (8.7.5/8.7.5) with ESMTP id BAA13022; Wed, 10 Apr 2002 01:18:32 +0200 (MET DST) From: Martin Karsten Received: from KOM.tu-darmstadt.de by KOM.tu-darmstadt.de (8.11.2/8.7.5) id g39NI2902636; Wed, 10 Apr 2002 01:18:02 +0200 Message-Id: <200204092318.g39NI2902636@KOM.tu-darmstadt.de> Subject: Re: [NSIS] attempted summary of pre-emption thread In-Reply-To: <9FBD322B7824D511B36900508BF93C9C01AA4A0D@zcard031.ca.nortel.com> from Gary Kenward at "Apr 9, 2002 04:01:38 pm" To: Gary Kenward Date: Wed, 10 Apr 2002 01:18:02 +0200 (CEST) CC: "'James M. Polk'" , "Hancock, Robert" , nsis@ietf.org X-Mailer: ELM [version 2.4ME+ PL66 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit > Robert's email was clear to me, and well stated. He was saying that if > there is a requirement for pre-emption, then it can be captured in the > data description (hopefully, an opaque TLV data chunk) for the QoS, and > there is no need for a change in the requirements for NSIS. I have to admit that I did not follow the complete thread, but maybe it helps to distinguish "preemption" from "priority". The "priority" of a request can be encoded in the QoS specification, but "preemption" capability (beyond packet preemption aka "drop" ;-), including informing all participating entities, mandates a certain asynchronous communication pattern, which must be taken into account when designing the signalling protocol and thus, seems to belong to the requirements. Martin _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Tue Apr 9 19:57:32 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26018 for ; Tue, 9 Apr 2002 19:57:32 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA29536 for nsis-archive@odin.ietf.org; Tue, 9 Apr 2002 19:57:32 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA29387; Tue, 9 Apr 2002 19:51:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA29358 for ; Tue, 9 Apr 2002 19:51:41 -0400 (EDT) Received: from arb-exchange1.cetaceannetworks.com ([63.127.199.195]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25918 for ; Tue, 9 Apr 2002 19:51:39 -0400 (EDT) Received: by mail.cetaceannetworks.com with Internet Mail Service (5.5.2653.19) id <2TMYZM2J>; Tue, 9 Apr 2002 19:47:07 -0400 Message-ID: <6D8664171C38D511B5AD0002B325CE66A93074@mail.cetaceannetworks.com> From: "Freytsis, Ilya" To: "'john.loughney@nokia.com'" , "'nsis@ietf.org'" Subject: Re: [NSIS] Interim Meeting Plan Date: Tue, 9 Apr 2002 19:47:06 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="windows-1251" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org John, It works for me. I do not see too many confirmations though. When the final decision will be made? Ilya Freytsis Principal Engineer Cetacean Networks Inc. ph. (603) 766-6065 fax (603) 766-7190 ifreytsis@cetacean.com From: john.loughney@nokia.com charset="iso-8859-1" Date: Fri, 5 Apr 2002 10:29:31 +0300 To: Subject: [NSIS] Interim Meeting Plan Hi all, It seems the most likely candidate for the interim meeting will be: Helsinki, May 21 - 23 Does this work for everybody? Topics would include. 1) Requirements 2) Protocol Comparison 3) Framework Issues 4) Relations to other work thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Tue Apr 9 21:47:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28400 for ; Tue, 9 Apr 2002 21:47:34 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA04835 for nsis-archive@odin.ietf.org; Tue, 9 Apr 2002 21:47:36 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA04553; Tue, 9 Apr 2002 21:37:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA04523 for ; Tue, 9 Apr 2002 21:37:04 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27511 for ; Tue, 9 Apr 2002 21:37:01 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3A1W5q24103; Tue, 9 Apr 2002 21:32:06 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 9 Apr 2002 21:32:07 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4A14@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Martin Karsten'" Cc: "'James M. Polk'" , "Hancock, Robert" , nsis@ietf.org Subject: RE: [NSIS] attempted summary of pre-emption thread Date: Tue, 9 Apr 2002 21:32:06 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1E02F.5DC2DE42" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1E02F.5DC2DE42 Content-Type: text/plain; charset="iso-8859-1" Martin: Could you expand upon your point for me. I do not understand the tight relationship being assigned between (bearer traffic?) pre-emption, and signalling semantics. Gary > -----Original Message----- > From: Martin Karsten [mailto:Martin.Karsten@KOM.tu-darmstadt.de] > Sent: April 9, 2002 19:18 > To: Kenward, Gary [WDLN2:AN10:EXCH] > Cc: 'James M. Polk'; Hancock, Robert; nsis@ietf.org > Subject: Re: [NSIS] attempted summary of pre-emption thread > > > > Robert's email was clear to me, and well stated. He was > saying that if > > there is a requirement for pre-emption, then it can be > captured in the > > data description (hopefully, an opaque TLV data chunk) for > the QoS, and > > there is no need for a change in the requirements for NSIS. > > I have to admit that I did not follow the complete thread, > but maybe it > helps to distinguish "preemption" from "priority". > > The "priority" of a request can be encoded in the QoS > specification, but > "preemption" capability (beyond packet preemption aka "drop" > ;-), including > informing all participating entities, mandates a certain asynchronous > communication pattern, which must be taken into account when > designing the > signalling protocol and thus, seems to belong to the requirements. > > Martin > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > ------_=_NextPart_001_01C1E02F.5DC2DE42 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [NSIS] attempted summary of pre-emption thread

Martin:

 Could you expand upon your point for me. I do = not understand
the tight relationship being assigned between = (bearer traffic?)
pre-emption, and signalling semantics.

Gary

> -----Original Message-----
> From: Martin Karsten [mailto:Martin.Karsten= @KOM.tu-darmstadt.de]
> Sent: April 9, 2002 19:18
> To: Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: 'James M. Polk'; Hancock, Robert; = nsis@ietf.org
> Subject: Re: [NSIS] attempted summary of = pre-emption thread
>
>
> >   Robert's email was clear to = me, and well stated. He was
> saying that if
> > there is a requirement for pre-emption, = then it can be
> captured in the
> > data description (hopefully, an opaque TLV = data chunk) for
> the QoS, and
> > there is no need for a change in the = requirements for NSIS.
>
> I have to admit that I did not follow the = complete thread,
> but maybe it
> helps to distinguish "preemption" = from "priority".
>
> The "priority" of a request can be = encoded in the QoS
> specification, but
> "preemption" capability (beyond = packet preemption aka "drop"
> ;-), including
> informing all participating entities, mandates = a certain asynchronous
> communication pattern, which must be taken into = account when
> designing the
> signalling protocol and thus, seems to belong = to the requirements.
>
> Martin
>
> = _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis=
>

------_=_NextPart_001_01C1E02F.5DC2DE42-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Wed Apr 10 01:58:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03755 for ; Wed, 10 Apr 2002 01:58:28 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA28516 for nsis-archive@odin.ietf.org; Wed, 10 Apr 2002 01:58:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA28144; Wed, 10 Apr 2002 01:51:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA28113 for ; Wed, 10 Apr 2002 01:50:59 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03682 for ; Wed, 10 Apr 2002 01:50:55 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g3A5pC527035 for ; Wed, 10 Apr 2002 08:51:13 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 10 Apr 2002 08:50:55 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 10 Apr 2002 08:50:55 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Wed, 10 Apr 2002 08:50:55 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64E4C@esebe004.NOE.Nokia.com> Thread-Topic: Yet One More Proposal for an Interim Meeting Thread-Index: AcHgU66yPmQA6upkQSi78a91OLtMpw== To: X-OriginalArrivalTime: 10 Apr 2002 05:50:55.0763 (UTC) FILETIME=[AE803630:01C1E053] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id BAA28114 Subject: [NSIS] Yet One More Proposal for an Interim Meeting Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi all, I've been informed that May 21 - 23 is not good for everyone. The other alternative would be to have the meeting June 3rd - 6th in Helsinki. Please let me know if this is a problem for anyone, I hope to finalize the meeting this week. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Wed Apr 10 02:26:09 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12391 for ; Wed, 10 Apr 2002 02:26:09 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA29953 for nsis-archive@odin.ietf.org; Wed, 10 Apr 2002 02:26:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA29786; Wed, 10 Apr 2002 02:21:36 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA29755 for ; Wed, 10 Apr 2002 02:21:34 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12331 for ; Wed, 10 Apr 2002 02:21:29 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g3A6Lm515640 for ; Wed, 10 Apr 2002 09:21:48 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 10 Apr 2002 09:21:24 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 10 Apr 2002 09:21:22 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] attempted summary of pre-emption thread Date: Wed, 10 Apr 2002 09:21:22 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64E4E@esebe004.NOE.Nokia.com> Thread-Topic: [NSIS] attempted summary of pre-emption thread Thread-Index: AcHf/Jx5Eeh4fVQZRR+VxL0L02OavgAWoTiQ To: , X-OriginalArrivalTime: 10 Apr 2002 06:21:22.0576 (UTC) FILETIME=[EF5DC100:01C1E057] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id CAA29756 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit James, > I am involved within the IEPREP WG (spoke at the Minn meeting - > and not about preemption) and preemption has been a topic of > many long threads there. Preemption has been agreed upon to be > optional in many networks, mandatory in others, while not_practiced > or not_allowed in still others. As a result, preemption will be > explicitly mentioned within that WG's Framework and Requirements > IDs in future releases (both are only -00 now). I understand the discussion in IEPREP. The current system in the PSTN uses the priority bits in the SS7 signaling messages to ensure a better call completion rate, it doesn't attempt pre-emption. In many GSM networks, an emergency call (911 or 112) will generally clear a radio channel, if all radio channels are full. However, with regards to NSIS, I am not sure what you asking for. I can see the following possibilities (not that I am saying NSIS should do them): 1) Set a bit in signaling message to indicate priority 2) define a state machine on how to handle this bit 3) define rules for handling this bit 4) define default behaviors 5) nothing What is it that you see is needed? Is this something that should be handled in the requirements, in the framework or in the protocol? How do we handle differing requirements due to local regulation? Does IEPREP have a documented recommendation for this? John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Wed Apr 10 02:38:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12496 for ; Wed, 10 Apr 2002 02:38:02 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA00934 for nsis-archive@odin.ietf.org; Wed, 10 Apr 2002 02:38:05 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA00045; Wed, 10 Apr 2002 02:27:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA00013 for ; Wed, 10 Apr 2002 02:27:14 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12417 for ; Wed, 10 Apr 2002 02:27:10 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g3A6RT518992 for ; Wed, 10 Apr 2002 09:27:29 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 10 Apr 2002 09:27:10 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 10 Apr 2002 09:27:10 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] Establishing QoS after handoff. Date: Wed, 10 Apr 2002 09:27:10 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64E51@esebe004.NOE.Nokia.com> Thread-Topic: [NSIS] Establishing QoS after handoff. Thread-Index: AcHf94nW7+gZjFlGQBmVkx3LhRuLPQAYPBPw To: Cc: X-OriginalArrivalTime: 10 Apr 2002 06:27:10.0386 (UTC) FILETIME=[BEAD5920:01C1E058] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id CAA00014 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Gary, > I don't think it as simple as saying that Seamoby focuses on > handover. I agree that NSIS should not be "handover aware", however, > (and this may be explicitly a seamoby issue), CT/CARD should not, > in my view, be performing service re-negotiation. If for no other > reason then the redundant functionality that is implied (and the > difficulty in maintaining the two negotiation protocols). I don't think that CT/CARD should be involved with service (re)negotiation either. > I will think about a draft, but I suspect it is premature/overkill. > In my mind, the issue is about which entity controls the QoS offered > to the MN, and is responsible for keeping the MN informed and reacting > to it's requests. In my simple view, that's NSIS (and certainly NOT > CT). There may be need for some text about this, when we get into framework issues, so having some text in the form of a draft always helps (its either than picking through emails from the mailing list). > The issue from an NSIS point of view, I guess, is what entity in > the framework corresponds to a new AR that is having difficulty providing > QoS support, and how does it invoke an action that includes notification > of the MN? I think that this could be discussed in the framework, if we go that way. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Wed Apr 10 05:51:20 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14530 for ; Wed, 10 Apr 2002 05:51:20 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA09983 for nsis-archive@odin.ietf.org; Wed, 10 Apr 2002 05:51:24 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA09877; Wed, 10 Apr 2002 05:48:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA09848 for ; Wed, 10 Apr 2002 05:48:04 -0400 (EDT) Received: from yamato.ccrle.nec.de (yamato.ccrle.nec.de [195.37.70.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14500 for ; Wed, 10 Apr 2002 05:47:59 -0400 (EDT) Received: from citadel.mobility.ccrle.nec.de ([192.168.156.1]) by yamato.ccrle.nec.de (8.11.6/8.10.1) with ESMTP id g3A9mtL06479; Wed, 10 Apr 2002 11:48:55 +0200 (CEST) Received: from [192.168.102.79] (madrid.heidelberg.ccrle.nec.de [192.168.102.79]) by citadel.mobility.ccrle.nec.de (Postfix on SuSE eMail Server 2.0) with ESMTP id B656AC051; Wed, 10 Apr 2002 11:46:49 +0200 (CEST) Date: Wed, 10 Apr 2002 11:56:27 +0200 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de To: "Shahrier, Sharif M." Cc: nsis@ietf.org Subject: Re: [NSIS] Establishment of RSVP parameters for RSVP Message-ID: <5545754.1018439787@[192.168.102.79]> In-Reply-To: References: X-Mailer: Mulberry/2.1.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit --On Tuesday, April 09, 2002 10:00 AM -0400 "Shahrier, Sharif M." wrote: > The determination of RSVP parameters to achieve the requested QoS is the > task of the QoS control devices. It is my impression that how these > parameters are derived are out of scope for NSIS? Is this true? > yes, I see QoS paramters (service definitions out of scope for NSIS) > Also, can someone please explain where the entities QoS Controller and QoS > Initiator are located with respect to RSVP protocol. I.e. are they only at > the edge of the network, or are they to be present at every RSVP node > along the transmission path? we require that the placment of QoS controllers and Initiators MUST be possible where ever you want. Marcus > > Sharif. > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ personal home page: http://www.brubers.org/marcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Wed Apr 10 07:08:35 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15243 for ; Wed, 10 Apr 2002 07:08:35 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA13749 for nsis-archive@odin.ietf.org; Wed, 10 Apr 2002 07:08:38 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA13660; Wed, 10 Apr 2002 07:05:05 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA13581 for ; Wed, 10 Apr 2002 07:04:52 -0400 (EDT) Received: from mailserver.KOM.e-technik.tu-darmstadt.de (drum.kom.e-technik.tu-darmstadt.de [130.83.139.190]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15154 for ; Wed, 10 Apr 2002 07:04:48 -0400 (EDT) Received: from KOM.tu-darmstadt.de by mailserver.KOM.e-technik.tu-darmstadt.de (8.7.5/8.7.5) with ESMTP id NAA08718; Wed, 10 Apr 2002 13:04:16 +0200 (MET DST) From: Martin Karsten Received: from KOM.tu-darmstadt.de by KOM.tu-darmstadt.de (8.11.2/8.7.5) id g3AB3ll04418; Wed, 10 Apr 2002 13:03:47 +0200 Message-Id: <200204101103.g3AB3ll04418@KOM.tu-darmstadt.de> Subject: Re: [NSIS] attempted summary of pre-emption thread In-Reply-To: <9FBD322B7824D511B36900508BF93C9C01AA4A14@zcard031.ca.nortel.com> from Gary Kenward at "Apr 9, 2002 09:32:06 pm" To: Gary Kenward Date: Wed, 10 Apr 2002 13:03:47 +0200 (CEST) CC: jmpolk@cisco.com, robert.hancock@roke.co.uk, nsis@ietf.org X-Mailer: ELM [version 2.4ME+ PL66 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit It might be obivous not to do, but someone could have the idea to design e.g. the following signalling protocol: 1) initiator sends QoS request and waits for confirmation (or reject) 2a) a network entity rejects the request and sends reject towards initiatior 2b) all network entities accept the request, so it arrives at remote end 3) remote end sends confirmation 4) transmission time (maybe including periodic state refresh) 5) initiator sends teardown (maybe through state timeout) 6) (optional) remote end sends tear confirmation Then the initiator would never be prepared to handle an asynchronous tear notification. If preemption capability shall be supported properly, however, the initiator must be prepared to receive such a notification. This is the most simple example that comes to my mind, of how preemption capability might influence the communication pattern. There might be other and more complex examples, depending on the rest of the requirements. Maybe James can jump in clarify whether this captures his view. Martin > Could you expand upon your point for me. I do not understand > the tight relationship being assigned between (bearer traffic?) > pre-emption, and signalling semantics. > > Gary > > > -----Original Message----- > > From: Martin Karsten [mailto:Martin.Karsten@KOM.tu-darmstadt.de] > > Sent: April 9, 2002 19:18 > > To: Kenward, Gary [WDLN2:AN10:EXCH] > > Cc: 'James M. Polk'; Hancock, Robert; nsis@ietf.org > > Subject: Re: [NSIS] attempted summary of pre-emption thread > > > > > > > Robert's email was clear to me, and well stated. He was saying that > > > if there is a requirement for pre-emption, then it can be captured in > > > the data description (hopefully, an opaque TLV data chunk) for the > > > QoS, and there is no need for a change in the requirements for NSIS. > > > > I have to admit that I did not follow the complete thread, but maybe it > > helps to distinguish "preemption" from "priority". > > > > The "priority" of a request can be encoded in the QoS specification, but > > "preemption" capability (beyond packet preemption aka "drop" ;-), > > including informing all participating entities, mandates a certain > > asynchronous communication pattern, which must be taken into account > > when designing the signalling protocol and thus, seems to belong to the > > requirements. > > > > Martin > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Wed Apr 10 07:52:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15775 for ; Wed, 10 Apr 2002 07:52:46 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA15595 for nsis-archive@odin.ietf.org; Wed, 10 Apr 2002 07:52:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA15417; Wed, 10 Apr 2002 07:47:53 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA15385 for ; Wed, 10 Apr 2002 07:47:50 -0400 (EDT) Received: from yamato.ccrle.nec.de (yamato.ccrle.nec.de [195.37.70.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15661 for ; Wed, 10 Apr 2002 07:47:45 -0400 (EDT) Received: from citadel.mobility.ccrle.nec.de ([192.168.156.1]) by yamato.ccrle.nec.de (8.11.6/8.10.1) with ESMTP id g3ABmSL08435; Wed, 10 Apr 2002 13:48:28 +0200 (CEST) Received: from [192.168.102.79] (madrid.heidelberg.ccrle.nec.de [192.168.102.79]) by citadel.mobility.ccrle.nec.de (Postfix on SuSE eMail Server 2.0) with ESMTP id 76298C051; Wed, 10 Apr 2002 13:46:29 +0200 (CEST) Date: Wed, 10 Apr 2002 13:56:07 +0200 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de To: Martin Karsten , Gary Kenward Cc: "'James M. Polk'" , "Hancock, Robert" , nsis@ietf.org Subject: Re: [NSIS] attempted summary of pre-emption thread Message-ID: <12725948.1018446967@[192.168.102.79]> In-Reply-To: <200204092318.g39NI2902636@KOM.tu-darmstadt.de> References: <200204092318.g39NI2902636@KOM.tu-darmstadt.de> X-Mailer: Mulberry/2.1.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit Martin, then you think a requirement for the support of asynchronous feedback is the way to go? Marcus --On Wednesday, April 10, 2002 1:18 AM +0200 Martin Karsten wrote: >> Robert's email was clear to me, and well stated. He was saying that if >> there is a requirement for pre-emption, then it can be captured in the >> data description (hopefully, an opaque TLV data chunk) for the QoS, and >> there is no need for a change in the requirements for NSIS. > > I have to admit that I did not follow the complete thread, but maybe it > helps to distinguish "preemption" from "priority". > > The "priority" of a request can be encoded in the QoS specification, but > "preemption" capability (beyond packet preemption aka "drop" ;-), > including informing all participating entities, mandates a certain > asynchronous communication pattern, which must be taken into account when > designing the signalling protocol and thus, seems to belong to the > requirements. > > Martin > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ personal home page: http://www.brubers.org/marcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Wed Apr 10 07:59:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15848 for ; Wed, 10 Apr 2002 07:59:49 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA15956 for nsis-archive@odin.ietf.org; Wed, 10 Apr 2002 07:59:52 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA15734; Wed, 10 Apr 2002 07:54:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA15701 for ; Wed, 10 Apr 2002 07:54:57 -0400 (EDT) Received: from yamato.ccrle.nec.de (yamato.ccrle.nec.de [195.37.70.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15808 for ; Wed, 10 Apr 2002 07:54:52 -0400 (EDT) Received: from citadel.mobility.ccrle.nec.de ([192.168.156.1]) by yamato.ccrle.nec.de (8.11.6/8.10.1) with ESMTP id g3ABtiL09001; Wed, 10 Apr 2002 13:55:44 +0200 (CEST) Received: from [192.168.102.79] (madrid.heidelberg.ccrle.nec.de [192.168.102.79]) by citadel.mobility.ccrle.nec.de (Postfix on SuSE eMail Server 2.0) with ESMTP id 56253C051; Wed, 10 Apr 2002 13:53:41 +0200 (CEST) Date: Wed, 10 Apr 2002 14:03:19 +0200 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de To: Anders.P.Bergsten@telia.se, john.loughney@nokia.com Cc: nsis@ietf.org Subject: RE: pre-emption (was RE: [NSIS] proposals related to NSIS WGdraf t) Message-ID: <13157910.1018447399@[192.168.102.79]> In-Reply-To: <1BF8A5964E4EFA41A094B835FCA7129110CC07@TMS041MB.tcad.telia.se> References: <1BF8A5964E4EFA41A094B835FCA7129110CC07@TMS041MB.tcad.telia.se> X-Mailer: Mulberry/2.1.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit Anders, John, I agree with you that it is a network issue, and that on a user to network interface pre-emption might not make sense. But does this hold as well for network oriented scenarios? E.g., we plane to add a scenario where Voice gateways signal for QoS (in an intra-domain case -> same administrative domain). Does this also mean that pre-emption is not a signaling protocol issue? Or did we forgot about it? Marcus --On Monday, April 08, 2002 11:14 AM +0200 Anders.P.Bergsten@telia.se wrote: >> >> Hi Anders, >> >> > not sure I understand, requesting resources for something is >> > in charter, I persume. What I stated was: there is one >> > instance where I see a need for pre-emption in signaling and >> > this is related to emergency calls. >> >> Should the protocol support pre-emption or should the network? >> >> My opinion is that it is network policy to determine how to >> do pre-emption, not a protocol issue. > > Thanks - you are correct, pre-emption is not a protocol issue but a > "network" issue (I also read the latest emails on the topic). Thus, I am > in favour of not having this as a (signaling) requirement. > > Anders > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ personal home page: http://www.brubers.org/marcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Wed Apr 10 08:03:09 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15894 for ; Wed, 10 Apr 2002 08:03:09 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA16487 for nsis-archive@odin.ietf.org; Wed, 10 Apr 2002 08:03:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA15880; Wed, 10 Apr 2002 07:58:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA15851 for ; Wed, 10 Apr 2002 07:58:21 -0400 (EDT) Received: from mailserver.KOM.e-technik.tu-darmstadt.de (drum.kom.e-technik.tu-darmstadt.de [130.83.139.190]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15841 for ; Wed, 10 Apr 2002 07:58:17 -0400 (EDT) Received: from KOM.tu-darmstadt.de by mailserver.KOM.e-technik.tu-darmstadt.de (8.7.5/8.7.5) with ESMTP id NAA19487; Wed, 10 Apr 2002 13:57:48 +0200 (MET DST) From: Martin Karsten Received: from KOM.tu-darmstadt.de by KOM.tu-darmstadt.de (8.11.2/8.7.5) id g3ABvI304981; Wed, 10 Apr 2002 13:57:18 +0200 Message-Id: <200204101157.g3ABvI304981@KOM.tu-darmstadt.de> Subject: Re: [NSIS] attempted summary of pre-emption thread In-Reply-To: <12725948.1018446967@[192.168.102.79]> from Marcus Brunner at "Apr 10, 2002 01:56:07 pm" To: brunner@ccrle.nec.de Date: Wed, 10 Apr 2002 13:57:18 +0200 (CEST) CC: gkenward@nortelnetworks.com, jmpolk@cisco.com, robert.hancock@roke.co.uk, nsis@ietf.org X-Mailer: ELM [version 2.4ME+ PL66 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit Maybe. I have no definite opinion about whether preemption capability may have further implications. I just noticed that there seemed to be confusion in the discussion because of overloaded terminology and wanted to help sorting this out. Martin > then you think a requirement for the support of asynchronous feedback is > the way to go? > > Marcus > > --On Wednesday, April 10, 2002 1:18 AM +0200 Martin Karsten > wrote: > > >> Robert's email was clear to me, and well stated. He was saying that if > >> there is a requirement for pre-emption, then it can be captured in the > >> data description (hopefully, an opaque TLV data chunk) for the QoS, and > >> there is no need for a change in the requirements for NSIS. > > > > I have to admit that I did not follow the complete thread, but maybe it > > helps to distinguish "preemption" from "priority". > > > > The "priority" of a request can be encoded in the QoS specification, but > > "preemption" capability (beyond packet preemption aka "drop" ;-), > > including informing all participating entities, mandates a certain > > asynchronous communication pattern, which must be taken into account when > > designing the signalling protocol and thus, seems to belong to the > > requirements. > > > > Martin > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > > -------------------------------------- > Dr. Marcus Brunner > Network Laboratories > NEC Europe Ltd. > > E-Mail: brunner@ccrle.nec.de > WWW: http://www.ccrle.nec.de/ > personal home page: http://www.brubers.org/marcus > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Wed Apr 10 08:09:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15973 for ; Wed, 10 Apr 2002 08:09:08 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA16886 for nsis-archive@odin.ietf.org; Wed, 10 Apr 2002 08:09:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA16823; Wed, 10 Apr 2002 08:07:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA16720 for ; Wed, 10 Apr 2002 08:07:04 -0400 (EDT) Received: from rsys000a.roke.co.uk (rsys000a.roke.co.uk [193.118.201.102]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA15960 for ; Wed, 10 Apr 2002 08:06:59 -0400 (EDT) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id <2488PTFX>; Wed, 10 Apr 2002 12:55:06 +0100 Message-ID: <76C92FBBFB58D411AE760090271ED4181EA239@rsys002a.roke.co.uk> From: "Hancock, Robert" To: "'Martin Karsten'" , Gary Kenward Cc: jmpolk@cisco.com, nsis@ietf.org Subject: RE: [NSIS] attempted summary of pre-emption thread Date: Wed, 10 Apr 2002 12:55:01 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; charset="iso-8859-1" Martin, You capture the point quite well: the type of QoS information being signalled has implications for the message sequences that the protocol needs to support, and these are then requirements for NSIS. We already tried (in minneapolis) to capture the basic request/response case (anders has written something on this i think), the intended essence of points (4) and (B) of the summary was that pre-emption implies some support for asynchronous notification as well, for the reasons you state. (does the summary miss something here or is it just not clear enough?) I think there is currently a working assumption in (some parts of) the group that defining QoS classes/parameters is not part of the work of NSIS, but deciding how to signal them is. But I don't think that this is really captured as a concrete point anywhere (it is discussed in the #53 minutes, but on the other hand contradicts the charter, so it's not totally surprising that there might be some confusion). I'm currently trying to write something that states this division and the implications more precisely. Actually, it relates to more than just message sequences (although that is the main point). Robert H. > -----Original Message----- > From: Martin Karsten [mailto:Martin.Karsten@KOM.tu-darmstadt.de] > Sent: 10 April 2002 12:04 > To: Gary Kenward > Cc: jmpolk@cisco.com; Hancock, Robert; nsis@ietf.org > Subject: Re: [NSIS] attempted summary of pre-emption thread > > > It might be obivous not to do, but someone could have the > idea to design > e.g. the following signalling protocol: > > 1) initiator sends QoS request and waits for confirmation (or reject) > 2a) a network entity rejects the request and sends reject > towards initiatior > 2b) all network entities accept the request, so it arrives at > remote end > 3) remote end sends confirmation > 4) transmission time (maybe including periodic state refresh) > 5) initiator sends teardown (maybe through state timeout) > 6) (optional) remote end sends tear confirmation > > Then the initiator would never be prepared to handle an > asynchronous tear > notification. If preemption capability shall be supported > properly, however, > the initiator must be prepared to receive such a notification. > > This is the most simple example that comes to my mind, of how > preemption > capability might influence the communication pattern. There > might be other > and more complex examples, depending on the rest of the > requirements. Maybe > James can jump in clarify whether this captures his view. > > Martin > > > Could you expand upon your point for me. I do not understand > > the tight relationship being assigned between (bearer traffic?) > > pre-emption, and signalling semantics. > > > > Gary > > > > > -----Original Message----- > > > From: Martin Karsten [mailto:Martin.Karsten@KOM.tu-darmstadt.de] > > > Sent: April 9, 2002 19:18 > > > To: Kenward, Gary [WDLN2:AN10:EXCH] > > > Cc: 'James M. Polk'; Hancock, Robert; nsis@ietf.org > > > Subject: Re: [NSIS] attempted summary of pre-emption thread > > > > > > > > > > Robert's email was clear to me, and well stated. He > was saying that > > > > if there is a requirement for pre-emption, then it can > be captured in > > > > the data description (hopefully, an opaque TLV data > chunk) for the > > > > QoS, and there is no need for a change in the > requirements for NSIS. > > > > > > I have to admit that I did not follow the complete > thread, but maybe it > > > helps to distinguish "preemption" from "priority". > > > > > > The "priority" of a request can be encoded in the QoS > specification, but > > > "preemption" capability (beyond packet preemption aka "drop" ;-), > > > including informing all participating entities, mandates a certain > > > asynchronous communication pattern, which must be taken > into account > > > when designing the signalling protocol and thus, seems to > belong to the > > > requirements. > > > > > > Martin > > > > > > _______________________________________________ > > > nsis mailing list > > > nsis@ietf.org > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; name="RMRL-Disclaimer.txt" Content-Disposition: attachment; filename="RMRL-Disclaimer.txt" Content-Transfer-Encoding: 7bit The information contained in this e-mail and any attachments is confidential to Roke Manor Research Ltd and must not be passed to any third party without permission. This communication is for information only and shall not create or change any contractual relationship. --------------InterScan_NT_MIME_Boundary-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Wed Apr 10 10:40:18 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21046 for ; Wed, 10 Apr 2002 10:40:17 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA26138 for nsis-archive@odin.ietf.org; Wed, 10 Apr 2002 10:40:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA25801; Wed, 10 Apr 2002 10:33:25 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA25770 for ; Wed, 10 Apr 2002 10:33:22 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20924 for ; Wed, 10 Apr 2002 10:33:17 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3AEOcZ22848; Wed, 10 Apr 2002 10:24:38 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 10 Apr 2002 10:24:39 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4A16@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Martin Karsten'" Cc: jmpolk@cisco.com, robert.hancock@roke.co.uk, nsis@ietf.org Subject: RE: [NSIS] attempted summary of pre-emption thread Date: Wed, 10 Apr 2002 10:24:40 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1E09B.3CD5D466" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1E09B.3CD5D466 Content-Type: text/plain; charset="iso-8859-1" Martin: If I understand this example correctly, the issue is the relationship between the state of the initiator and the arrival of asynchronous messages that should change that state? Gary > -----Original Message----- > From: Martin Karsten [mailto:Martin.Karsten@KOM.tu-darmstadt.de] > Sent: April 10, 2002 07:04 > To: Kenward, Gary [WDLN2:AN10:EXCH] > Cc: jmpolk@cisco.com; robert.hancock@roke.co.uk; nsis@ietf.org > Subject: Re: [NSIS] attempted summary of pre-emption thread > > > It might be obivous not to do, but someone could have the > idea to design > e.g. the following signalling protocol: > > 1) initiator sends QoS request and waits for confirmation (or reject) > 2a) a network entity rejects the request and sends reject > towards initiatior > 2b) all network entities accept the request, so it arrives at > remote end > 3) remote end sends confirmation > 4) transmission time (maybe including periodic state refresh) > 5) initiator sends teardown (maybe through state timeout) > 6) (optional) remote end sends tear confirmation > > Then the initiator would never be prepared to handle an > asynchronous tear > notification. If preemption capability shall be supported > properly, however, > the initiator must be prepared to receive such a notification. > > This is the most simple example that comes to my mind, of how > preemption > capability might influence the communication pattern. There > might be other > and more complex examples, depending on the rest of the > requirements. Maybe > James can jump in clarify whether this captures his view. > > Martin > > > Could you expand upon your point for me. I do not understand > > the tight relationship being assigned between (bearer traffic?) > > pre-emption, and signalling semantics. > > > > Gary > > > > > -----Original Message----- > > > From: Martin Karsten [mailto:Martin.Karsten@KOM.tu-darmstadt.de] > > > Sent: April 9, 2002 19:18 > > > To: Kenward, Gary [WDLN2:AN10:EXCH] > > > Cc: 'James M. Polk'; Hancock, Robert; nsis@ietf.org > > > Subject: Re: [NSIS] attempted summary of pre-emption thread > > > > > > > > > > Robert's email was clear to me, and well stated. He > was saying that > > > > if there is a requirement for pre-emption, then it can > be captured in > > > > the data description (hopefully, an opaque TLV data > chunk) for the > > > > QoS, and there is no need for a change in the > requirements for NSIS. > > > > > > I have to admit that I did not follow the complete > thread, but maybe it > > > helps to distinguish "preemption" from "priority". > > > > > > The "priority" of a request can be encoded in the QoS > specification, but > > > "preemption" capability (beyond packet preemption aka "drop" ;-), > > > including informing all participating entities, mandates a certain > > > asynchronous communication pattern, which must be taken > into account > > > when designing the signalling protocol and thus, seems to > belong to the > > > requirements. > > > > > > Martin > > > > > > _______________________________________________ > > > nsis mailing list > > > nsis@ietf.org > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > ------_=_NextPart_001_01C1E09B.3CD5D466 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [NSIS] attempted summary of pre-emption thread

Martin:

  If I understand this example correctly, the = issue is the relationship
between the state of the initiator and the arrival = of asynchronous messages
that should change that state?

Gary

> -----Original Message-----
> From: Martin Karsten [mailto:Martin.Karsten= @KOM.tu-darmstadt.de]
> Sent: April 10, 2002 07:04
> To: Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: jmpolk@cisco.com; = robert.hancock@roke.co.uk; nsis@ietf.org
> Subject: Re: [NSIS] attempted summary of = pre-emption thread
>
>
> It might be obivous not to do, but someone = could have the
> idea to design
> e.g. the following signalling protocol:
>
> 1) initiator sends QoS request and waits for = confirmation (or reject)
> 2a) a network entity rejects the request and = sends reject
> towards initiatior
> 2b) all network entities accept the request, so = it arrives at
> remote end
> 3) remote end sends confirmation
> 4) transmission time (maybe including periodic = state refresh)
> 5) initiator sends teardown (maybe through = state timeout)
> 6) (optional) remote end sends tear = confirmation
>
> Then the initiator would never be prepared to = handle an
> asynchronous tear
> notification. If preemption capability shall be = supported
> properly, however,
> the initiator must be prepared to receive such = a notification.
>
> This is the most simple example that comes to = my mind, of how
> preemption
> capability might influence the communication = pattern. There
> might be other
> and more complex examples, depending on the = rest of the
> requirements. Maybe
> James can jump in clarify whether this captures = his view.
>
> Martin
>
> >  Could you expand upon your point for = me. I do not understand
> > the tight relationship being assigned = between (bearer traffic?)
> > pre-emption, and signalling = semantics.
> >
> > Gary
> >
> > > -----Original Message-----
> > > From: Martin Karsten [mailto:Martin.Karsten= @KOM.tu-darmstadt.de]
> > > Sent: April 9, 2002 19:18
> > > To: Kenward, Gary = [WDLN2:AN10:EXCH]
> > > Cc: 'James M. Polk'; Hancock, Robert; = nsis@ietf.org
> > > Subject: Re: [NSIS] attempted summary = of pre-emption thread
> > >
> > >
> > > >   Robert's email was = clear to me, and well stated. He
> was saying that
> > > > if there is a requirement for = pre-emption, then it can
> be captured in
> > > > the data description (hopefully, = an opaque TLV data
> chunk) for the
> > > > QoS, and there is no need for a = change in the
> requirements for NSIS.
> > >
> > > I have to admit that I did not follow = the complete
> thread, but maybe it
> > > helps to distinguish = "preemption" from "priority".
> > >
> > > The "priority" of a request = can be encoded in the QoS
> specification, but
> > > "preemption" capability = (beyond packet preemption aka "drop" ;-),
> > > including informing all participating = entities, mandates a certain
> > > asynchronous communication pattern, = which must be taken
> into account
> > > when designing the signalling = protocol and thus, seems to
> belong to the
> > > requirements.
> > >
> > > Martin
> > >
> > > = _______________________________________________
> > > nsis mailing list
> > > nsis@ietf.org
> > > https://www1.ietf.org/mailman/listinfo/nsis=
> > >
>
>

------_=_NextPart_001_01C1E09B.3CD5D466-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Wed Apr 10 13:25:03 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25925 for ; Wed, 10 Apr 2002 13:25:03 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA06878 for nsis-archive@odin.ietf.org; Wed, 10 Apr 2002 13:25:05 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA06716; Wed, 10 Apr 2002 13:19:44 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA06684 for ; Wed, 10 Apr 2002 13:19:41 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25786 for ; Wed, 10 Apr 2002 13:19:32 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3AHJ3Z06269 for ; Wed, 10 Apr 2002 13:19:03 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 10 Apr 2002 13:19:02 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4A1A@zcard031.ca.nortel.com> From: "Gary Kenward" Cc: "'nsis@ietf.org'" Subject: RE: [NSIS] attempted summary of pre-emption thread Date: Wed, 10 Apr 2002 13:19:02 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1E0B3.B4B024D8" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1E0B3.B4B024D8 Content-Type: text/plain; charset="iso-8859-1" Martin: Getting clearer to me. This would seem to be a state machine design issue. One could define requirements that certain protocol events were asynchronous, thus distinguishing them from the synchronous protocol events, and require certain behaviours on the part of the communicating entities. In general, the normal assumption for the Internet is asynchronous message, as ensuring synchronization (implying assured delivery, ordering, and no duplication) is often more complex (this is my perception, I am open to correction on this). There are not many precedents for signalling in the Internet. The other observation I would make is that the IETF does not specify state machine behaviour, but rather protocol behaviour. Thus, the requirement for a message arrival at a node is usually an outcome at the node, and a (possible) response to the message. How the node effects the outcome and generates the response is left to the node designer. Thus, in general, one would not require that a state-machine be pre-empted by a protocol event. Marcus was correct in his posting that there is confusion over the topic here. Perhaps the confusion was mine, but my recollection is that this thread started with a discussion of "pre-emption" bits in NSIS to specify flow treatment. This issue with the protocol state machine is very different. My view, and this is just my view, is that specifying state-machine pre-emption is not the right requirement (in the IETF context). Rather, we should focus on the expected outcome of a protocol exchange and the dependence or independence of the sequencing of messages. Otherwise, I agree that it must be (and usually, btw, is) accounted for in the protocol definition. Regards, Gary > -----Original Message----- > From: Martin Karsten [mailto:Martin.Karsten@KOM.tu-darmstadt.de] > Sent: April 10, 2002 10:35 > To: Kenward, Gary [WDLN2:AN10:EXCH] > Subject: Re: [NSIS] attempted summary of pre-emption thread > > > Yep, for this example, one might express it that way. > > Martin > > > Martin: > > > > If I understand this example correctly, the issue is the > relationship > > between the state of the initiator and the arrival of > asynchronous messages > > that should change that state? > > > > Gary > > *snip* > > > > > > > > > > Martin > > > > > > > > > > _______________________________________________ > > > > > nsis mailing list > > > > > nsis@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > > > > ------_=_NextPart_001_01C1E0B3.B4B024D8 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [NSIS] attempted summary of pre-emption thread

Martin:

  Getting clearer to me. This would seem to be a = state machine design
issue. One could define requirements that certain = protocol events
were asynchronous, thus distinguishing them from the = synchronous protocol
events, and require certain behaviours on the part = of the communicating
entities. In general, the normal assumption for the = Internet is asynchronous
message, as ensuring synchronization (implying = assured delivery, ordering,
and no duplication) is often more complex (this is = my perception, I am open
to correction on this). There are not many = precedents for signalling in the
Internet.

  The other observation I would make is that the = IETF does not specify
state machine behaviour, but rather protocol = behaviour. Thus, the requirement
for a message arrival at a node is usually an = outcome at the node, and
a (possible) response to the message. How the node = effects the outcome and
generates the response is left to the node designer. = Thus, in general,
one would not require that a state-machine be = pre-empted by a protocol event.

  Marcus was correct in his posting that there = is confusion over the topic
here. Perhaps the confusion was mine, but my = recollection is that this
thread started with a discussion of = "pre-emption" bits in NSIS to specify flow
treatment. This issue with the protocol state = machine is very different.

  My view, and this is just my view, is that = specifying state-machine pre-emption
is not the right requirement (in the IETF context). = Rather, we should focus on
the expected outcome of a protocol exchange and the = dependence or independence
of the sequencing of messages.

  Otherwise, I agree that it must be (and = usually, btw, is) accounted for in
the protocol definition.

Regards,
Gary



> -----Original Message-----
> From: Martin Karsten [mailto:Martin.Karsten= @KOM.tu-darmstadt.de]
> Sent: April 10, 2002 10:35
> To: Kenward, Gary [WDLN2:AN10:EXCH]
> Subject: Re: [NSIS] attempted summary of = pre-emption thread
>
>
> Yep, for this example, one might express it = that way.
>
> Martin
>
> > Martin:
> >
> >   If I understand this example = correctly, the issue is the
> relationship
> > between the state of the initiator and the = arrival of
> asynchronous messages
> > that should change that state?
> >
> > Gary
> >

*snip*

> > > > >
> > > > > Martin
> > > > >
> > > > > = _______________________________________________
> > > > > nsis mailing list
> > > > > nsis@ietf.org
> > > > > https://www1.ietf.org/mailman/listinfo/nsis=
> > > > >
> > >
> > >
>
>

------_=_NextPart_001_01C1E0B3.B4B024D8-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Wed Apr 10 14:37:21 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28921 for ; Wed, 10 Apr 2002 14:37:21 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA12173 for nsis-archive@odin.ietf.org; Wed, 10 Apr 2002 14:37:24 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA11984; Wed, 10 Apr 2002 14:32:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA11953 for ; Wed, 10 Apr 2002 14:32:07 -0400 (EDT) Received: from auds952.usa.alcatel.com (auds952.usa.alcatel.com [143.209.238.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28648 for ; Wed, 10 Apr 2002 14:32:04 -0400 (EDT) Received: from alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g3AIVax22736 for ; Wed, 10 Apr 2002 13:31:36 -0500 (CDT) Message-ID: <3CB48506.7090406@alcatel.com> Date: Wed, 10 Apr 2002 13:31:34 -0500 From: Behcet Sarikaya Organization: Alcatel USA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: nsis@ietf.org Subject: Re: [NSIS] attempted summary of pre-emption thread References: <9FBD322B7824D511B36900508BF93C9C01AA4A1A@zcard031.ca.nortel.com> Content-Type: multipart/alternative; boundary="------------020905040304050208090707" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org --------------020905040304050208090707 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Gary Kenward wrote: > Martin: > > Getting clearer to me. This would seem to be a state machine design > issue. One could define requirements that certain protocol events > were asynchronous, thus distinguishing them from the synchronous protocol > events, and require certain behaviours on the part of the communicating > entities. In general, the normal assumption for the Internet is > asynchronous > message, as ensuring synchronization (implying assured delivery, > ordering, > and no duplication) is often more complex (this is my perception, I am > open > to correction on this). There are not many precedents for signalling > in the > Internet. > > The other observation I would make is that the IETF does not specify > state machine behaviour, but rather protocol behaviour. > Gary, what makes you say this? The state machine behaviour is part of protocol behavior. Protocol RFCs specify the behavior informally which makes it rather difficult to fully specify the state machine behavior more difficult than if the specs were in SDL. But that does not mean the state machine behavior is not or can not be specified. > Thus, the requirement > for a message arrival at a node is usually an outcome at the node, and > a (possible) response to the message. How the node effects the outcome and > generates the response is left to the node designer. Thus, in general, > one would not require that a state-machine be pre-empted by a protocol > event. > > Marcus was correct in his posting that there is confusion over the topic > here. Perhaps the confusion was mine, but my recollection is that this > thread started with a discussion of "pre-emption" bits in NSIS to > specify flow > treatment. This issue with the protocol state machine is very different. > > My view, and this is just my view, is that specifying state-machine > pre-emption > is not the right requirement (in the IETF context). Rather, we should > focus on > the expected outcome of a protocol exchange and the dependence or > independence > of the sequencing of messages. > > Otherwise, I agree that it must be (and usually, btw, is) accounted > for in > the protocol definition. > > Regards, > Gary > > > --behcet --------------020905040304050208090707 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit

Gary Kenward wrote:
RE: [NSIS] attempted summary of pre-emption thread

Martin:

  Getting clearer to me. This would seem to be a state machine design
issue. One could define requirements that certain protocol events
were asynchronous, thus distinguishing them from the synchronous protocol
events, and require certain behaviours on the part of the communicating
entities. In general, the normal assumption for the Internet is asynchronous
message, as ensuring synchronization (implying assured delivery, ordering,
and no duplication) is often more complex (this is my perception, I am open
to correction on this). There are not many precedents for signalling in the
Internet.

  The other observation I would make is that the IETF does not specify
state machine behaviour, but rather protocol behaviour.

Gary, what makes you say this? The state machine behaviour is part of protocol behavior. Protocol RFCs specify the behavior informally which makes it rather difficult to fully specify the state machine behavior more difficult than if the specs were in SDL. But that does not mean the state machine behavior is not or can not be specified.

Thus, the requirement
for a message arrival at a node is usually an outcome at the node, and
a (possible) response to the message. How the node effects the outcome and
generates the response is left to the node designer. Thus, in general,
one would not require that a state-machine be pre-empted by a protocol event.

  Marcus was correct in his posting that there is confusion over the topic
here. Perhaps the confusion was mine, but my recollection is that this
thread started with a discussion of "pre-emption" bits in NSIS to specify flow
treatment. This issue with the protocol state machine is very different.

  My view, and this is just my view, is that specifying state-machine pre-emption
is not the right requirement (in the IETF context). Rather, we should focus on
the expected outcome of a protocol exchange and the dependence or independence
of the sequencing of messages.

  Otherwise, I agree that it must be (and usually, btw, is) accounted for in
the protocol definition.

Regards,
Gary



--behcet

--------------020905040304050208090707-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Wed Apr 10 15:21:23 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00148 for ; Wed, 10 Apr 2002 15:21:22 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA14370 for nsis-archive@odin.ietf.org; Wed, 10 Apr 2002 15:21:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA14200; Wed, 10 Apr 2002 15:15:53 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA14166 for ; Wed, 10 Apr 2002 15:15:50 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00081 for ; Wed, 10 Apr 2002 15:15:46 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3AJFGI28745; Wed, 10 Apr 2002 15:15:16 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 10 Apr 2002 15:15:16 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4A1D@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Behcet Sarikaya'" , nsis@ietf.org Subject: RE: [NSIS] attempted summary of pre-emption thread Date: Wed, 10 Apr 2002 15:15:14 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1E0C4.0A690592" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1E0C4.0A690592 Content-Type: text/plain; charset="iso-8859-1" Behcet: Can or should, the IETF does not specify state machine behaviours. Certainly not to the level that details such as pre-emption of that state machine can be identified. Regardless, I may have focussed on the wrong model to make my point. There have been two debates raging here. To attempt to close the second debate, the one concerning asynchronous pre-emption of the signalling itself, how about we agree that some messages will pre-empt ongoing operations, but that this outcome is an implicit result of the semantics of the message sequences, not dependent upon the existence of a pre-emption bit or field in a message (note: I may be tying two different proposals together here, but somehow one morphed into another, and I'm not clear where one ends and the other begins). As far as I am concerned, the above is normal operation for most protocols, including IETF protocols, and do not need to be expressed in an explicit requirement (e.g. many of the behaviours of TCP could be defined as being pre-emptive). Gary -----Original Message----- From: Behcet Sarikaya [mailto:behcet.sarikaya@alcatel.com] Sent: April 10, 2002 14:32 To: nsis@ietf.org Subject: Re: [NSIS] attempted summary of pre-emption thread Gary Kenward wrote: Martin: Getting clearer to me. This would seem to be a state machine design issue. One could define requirements that certain protocol events were asynchronous, thus distinguishing them from the synchronous protocol events, and require certain behaviours on the part of the communicating entities. In general, the normal assumption for the Internet is asynchronous message, as ensuring synchronization (implying assured delivery, ordering, and no duplication) is often more complex (this is my perception, I am open to correction on this). There are not many precedents for signalling in the Internet. The other observation I would make is that the IETF does not specify state machine behaviour, but rather protocol behaviour. Gary, what makes you say this? The state machine behaviour is part of protocol behavior. Protocol RFCs specify the behavior informally which makes it rather difficult to fully specify the state machine behavior more difficult than if the specs were in SDL. But that does not mean the state machine behavior is not or can not be specified. Thus, the requirement for a message arrival at a node is usually an outcome at the node, and a (possible) response to the message. How the node effects the outcome and generates the response is left to the node designer. Thus, in general, one would not require that a state-machine be pre-empted by a protocol event. Marcus was correct in his posting that there is confusion over the topic here. Perhaps the confusion was mine, but my recollection is that this thread started with a discussion of "pre-emption" bits in NSIS to specify flow treatment. This issue with the protocol state machine is very different. My view, and this is just my view, is that specifying state-machine pre-emption is not the right requirement (in the IETF context). Rather, we should focus on the expected outcome of a protocol exchange and the dependence or independence of the sequencing of messages. Otherwise, I agree that it must be (and usually, btw, is) accounted for in the protocol definition. Regards, Gary --behcet ------_=_NextPart_001_01C1E0C4.0A690592 Content-Type: text/html; charset="iso-8859-1" RE: [NSIS] attempted summary of pre-emption thread
Behcet:
  
   Can or should, the IETF does not specify state machine
behaviours. Certainly not to the level that details such as
pre-emption of that state machine can be identified. Regardless,
I may have focussed on the wrong model to make my point.
 
   There have been two debates raging here. To attempt to close
the second debate, the one concerning asynchronous
pre-emption of the signalling itself, how about we agree that
some messages will pre-empt ongoing operations, but that this
outcome is an implicit result of the semantics of the message sequences,
not dependent upon the existence of a pre-emption bit or field in a message
(note: I may be tying two different proposals together here,
but somehow one morphed into another, and I'm not clear where
one ends and the other begins).
 
  As far as I am concerned, the above is normal operation for
most protocols, including IETF protocols, and do not need to
be expressed in an explicit requirement (e.g. many of the behaviours
of TCP could be defined as being pre-emptive).
 
Gary
-----Original Message-----
From: Behcet Sarikaya [mailto:behcet.sarikaya@alcatel.com]
Sent: April 10, 2002 14:32
To: nsis@ietf.org
Subject: Re: [NSIS] attempted summary of pre-emption thread



Gary Kenward wrote:

Martin:

  Getting clearer to me. This would seem to be a state machine design
issue. One could define requirements that certain protocol events
were asynchronous, thus distinguishing them from the synchronous protocol
events, and require certain behaviours on the part of the communicating
entities. In general, the normal assumption for the Internet is asynchronous
message, as ensuring synchronization (implying assured delivery, ordering,
and no duplication) is often more complex (this is my perception, I am open
to correction on this). There are not many precedents for signalling in the
Internet.

  The other observation I would make is that the IETF does not specify
state machine behaviour, but rather protocol behaviour.

Gary, what makes you say this? The state machine behaviour is part of protocol behavior. Protocol RFCs specify the behavior informally which makes it rather difficult to fully specify the state machine behavior more difficult than if the specs were in SDL. But that does not mean the state machine behavior is not or can not be specified.

Thus, the requirement
for a message arrival at a node is usually an outcome at the node, and
a (possible) response to the message. How the node effects the outcome and
generates the response is left to the node designer. Thus, in general,
one would not require that a state-machine be pre-empted by a protocol event.

  Marcus was correct in his posting that there is confusion over the topic
here. Perhaps the confusion was mine, but my recollection is that this
thread started with a discussion of "pre-emption" bits in NSIS to specify flow
treatment. This issue with the protocol state machine is very different.

  My view, and this is just my view, is that specifying state-machine pre-emption
is not the right requirement (in the IETF context). Rather, we should focus on
the expected outcome of a protocol exchange and the dependence or independence
of the sequencing of messages.

  Otherwise, I agree that it must be (and usually, btw, is) accounted for in
the protocol definition.

Regards,
Gary



--behcet

------_=_NextPart_001_01C1E0C4.0A690592-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Wed Apr 10 17:59:23 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03655 for ; Wed, 10 Apr 2002 17:59:21 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA23330 for nsis-archive@odin.ietf.org; Wed, 10 Apr 2002 17:59:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA23170; Wed, 10 Apr 2002 17:53:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA23090 for ; Wed, 10 Apr 2002 17:53:43 -0400 (EDT) Received: from relay1.alcatel.be (alc119.alcatel.be [195.207.101.119]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03539 for ; Wed, 10 Apr 2002 17:53:37 -0400 (EDT) From: sven.van_den_bosch@alcatel.be Received: from bemail04.net.alcatel.be (localhost [127.0.0.1]) by relay1.alcatel.be (8.10.1/8.10.1) with ESMTP id g3ALr4M10142; Wed, 10 Apr 2002 23:53:04 +0200 (MET DST) Subject: RE: [NSIS] proposals related to NSIS WG draft To: "Georgios Karagiannis (ELN)" Cc: "'Sven Van den Bosch'" , nsis@ietf.org X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Wed, 10 Apr 2002 23:53:00 +0200 X-MIMETrack: Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 04/10/2002 23:53:03 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi Georgios, I am not against it, although I think the wording although covers the case of an end-host. Let's change it for clarity though. Sven. "Georgios Karagiannis (ELN)" on 09/04/2002 12:46:39 To: "'Sven Van den Bosch'" , nsis@ietf.org cc: (bcc: Sven VAN DEN BOSCH/BE/ALCATEL) Subject RE: [NSIS] proposals related to NSIS WG draft : Hi Sven I agree with you, on introducing the term "QoS Receiver", however, I would very much appreciate if the sentence: "QoS Receiver: Network entity, located at the edge of or inside a QoS ..." is changed into: ""QoS Receiver: Network entity, located at an end host, an edge of or inside a QoS ..." Best Regards, Georgios -----Original Message----- From: Sven Van den Bosch [mailto:svenvandenbosch@hotmail.com] Sent: dinsdag 19 maart 2002 23:44 To: nsis@ietf.org Subject: [NSIS] proposals related to NSIS WG draft Hi all, As an outcome of this morning's NSIS meeting, we propose the following detailed additions to the WG draft. 1. Terminology - QoS Controller: Network entity responsible for interpreting and implementing the signaled QoS in the network. Failure to do so implies an admission control decision. It can only be triggered by another NSIS entity of the same instance (a QoS Initiator or another QoS Controller). - QoS Receiver: Network entity, located at the edge of or inside a QoS domain, responsible for terminating an instance of an NSIS protocol. It has the additional functionality that it may initiate an acknowledgment towards the QI and that it may trigger another NSIS entity (QoS Initiator or QoS Controller of another instance of the NSIS protocol) - QoS Initiator: Network entity, located at the edge of or inside a QoS domain, responsible for initiating an instance of an NSIS QoS signaling protocol. It may be triggered by the application layer, by the termination of a local QoS signaling mechanism (possibly another instance of NSIS signaling) or by a QoS Controller of another of a client instance of an NSIS protocol. It provides a mapping between the QoS parameters contained in the trigger and the QoS parameters in the instance of the NSIS protocol for which is serves as QoS Initiator. 2. Use cases/scenarios: 2 are available from the draft-buchli (sections 4.1 and 4.2) 3. Requirements * New requirements - in section MUST support priority The priority of a flow is essentially decoupled from its QoS requirements. Therefore the protocol MUST support priority. As a consequence, it MUST support preemption of traffic flows in case of congestion or failure. A preemption action MAY trigger an attempt to resetup the request by means of another instance of an NSIS signaling protocol. - in section 5.3: MAY support grouping of microflows (possibly only for feedback) As a consequence of the optimization for the interactive multimedia services, the signaling should allow one unique request for several micro flows having the same origination and destination IP addresses. This is usually the case for multimedia SIP calls where the voice and video micro flows follow the same path. This grouping of requests allows optimization of the QoS processing. Note that this may be detrimental for the call setup time. The use of grouping for microflows may be restricted to teardown and/or notification messages when call setup time is a concern. - in section 5.5: Protocol content The per-flow QoS requests are mapped onto the bandwidth pipe, which is specified by an SLS. These pipes may provide statistical guarantees such as delay and packet loss bounds (depending on the QoS class). In order to invoke per-flow QoS services the only parameter needed is a required rate, a means to identify the data path (mapping on SLS) and eventually a reservation identifier. 1) Microflow/reservation description The signaling should allow the request to describe the microflow whose QoS would be guaranteed by giving at least the source and destination IP addresses of the media flow. In case the QC is stateful (per microflow) there may be a need to include a unique reservation identifier (e.g. QI identifier+counter) such that in case of e.g. a tear down message the reservation can be easily identified in the QC. 2) Traffic descriptor The required peak rate must be signaled. Optionally the traffic parameters may be expressed in terms of token bucket parameters (similar to the TSpec in RSVP). - in section 5.10: Interworking with provisioning * Requirements for which to change priority or formulation - MUST support signalling to entities outside the data path (reformulation) - MUST NOT be adversely impacted by mobility aspects (applicable for end-to-end) A QoS controller in an end-to-end instance of an NSIS protocol MUST NOT be adversely affected by mobility issues. Any mobility scenario should be tackled by other uses of an NSIS protocol and is outside the realm of an end-to-end application of the NSIS protocol. _________________________________________________________________ Download MSN Explorer gratis van http://explorer.msn.nl/intl.asp. _______________________________________________ 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 daemon@optimus.ietf.org Wed Apr 10 23:53:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA10974 for ; Wed, 10 Apr 2002 23:53:58 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id XAA09420 for nsis-archive@odin.ietf.org; Wed, 10 Apr 2002 23:53:59 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA07823; Wed, 10 Apr 2002 23:17:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA07789 for ; Wed, 10 Apr 2002 23:17:52 -0400 (EDT) Received: from howler.tri.sbc.com (howler.tri.sbc.com [205.173.58.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA10046 for ; Wed, 10 Apr 2002 23:17:47 -0400 (EDT) Received: from sbctri.tri.sbc.com (sbctri [144.60.1.10]) by howler.tri.sbc.com (8.11.6+Sun/8.11.0) with ESMTP id g3B3KcN08570; Wed, 10 Apr 2002 22:20:38 -0500 (CDT) Received: from TRIMAIL2.ad.tri.sbc.com (localhost [127.0.0.1]) by sbctri.tri.sbc.com (8.11.6+Sun/8.9.3) with ESMTP id g3B3H5p14328; Wed, 10 Apr 2002 22:17:06 -0500 (CDT) Received: by TRIMAIL2.ad.tri.sbc.com with Internet Mail Service (5.5.2653.19) id <2P7CA9DD>; Wed, 10 Apr 2002 22:17:48 -0500 Message-ID: <905A1C4ABF353F4C8CC16FA9F53DD0D638BA77@TRIMAIL2.ad.tri.sbc.com> From: "Schneider, Marco" To: "'john.loughney@nokia.com'" , Anders.P.Bergsten@telia.se Cc: nsis@ietf.org Subject: RE: pre-emption (was RE: [NSIS] proposals related to NSIS WGdraf t) Date: Wed, 10 Apr 2002 22:17:47 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Related to the issue of preemption, a group of us discussed the issue of reservation lifetime while in Minneapolis. Our conclusion was that this could be done transparently by building it into the service description which is carried by, but not visible to, NSIS. Reservation lifetime would only be seen in a service specific field which is part of the service description and transparent to NSIS. It seems to me that while pre-emption is a different concern than reservation lifetime, it still can be supported in the same way. The only requirement that seems necessary is that NSIS must support the ability of a QOS controller to release an existing connection. Specific cause codes would be specific to the service and are out of scope and transparent to NSIS. Comments? Marco > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: Monday, April 08, 2002 3:53 AM > To: Anders.P.Bergsten@telia.se > Cc: nsis@ietf.org > Subject: RE: pre-emption (was RE: [NSIS] proposals related to NSIS > WGdraf t) > > > Hi Anders, > > > not sure I understand, requesting resources for something is > > in charter, I persume. What I stated was: there is one > > instance where I see a need for pre-emption in signaling and > > this is related to emergency calls. > > Should the protocol support pre-emption or should the network? > > My opinion is that it is network policy to determine how to > do pre-emption, not a protocol issue. > > John > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu Apr 11 00:04:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11108 for ; Thu, 11 Apr 2002 00:04:15 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id AAA10206 for nsis-archive@odin.ietf.org; Thu, 11 Apr 2002 00:04:16 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA08977; Wed, 10 Apr 2002 23:41:36 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA08944 for ; Wed, 10 Apr 2002 23:41:31 -0400 (EDT) Received: from howler.tri.sbc.com (howler.tri.sbc.com [205.173.58.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA10716 for ; Wed, 10 Apr 2002 23:41:26 -0400 (EDT) Received: from sbctri.tri.sbc.com (sbctri [144.60.1.10]) by howler.tri.sbc.com (8.11.6+Sun/8.11.0) with ESMTP id g3B3iIN08602; Wed, 10 Apr 2002 22:44:19 -0500 (CDT) Received: from TRIMAIL2.ad.tri.sbc.com (localhost [127.0.0.1]) by sbctri.tri.sbc.com (8.11.6+Sun/8.9.3) with ESMTP id g3B3ekG14768; Wed, 10 Apr 2002 22:40:46 -0500 (CDT) Received: by TRIMAIL2.ad.tri.sbc.com with Internet Mail Service (5.5.2653.19) id <2P7CA91B>; Wed, 10 Apr 2002 22:41:29 -0500 Message-ID: <905A1C4ABF353F4C8CC16FA9F53DD0D638BA78@TRIMAIL2.ad.tri.sbc.com> From: "Schneider, Marco" To: "'Hancock, Robert'" , nsis@ietf.org Subject: RE: [NSIS] attempted summary of pre-emption thread Date: Wed, 10 Apr 2002 22:41:25 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Robert, I am in complete agreement with what you say below and in particular I think that we document these non-requirements in an ongoing basis to show how the NSIS protocol transparently supports them. Marco > -----Original Message----- > From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] > Sent: Tuesday, April 09, 2002 9:06 AM > To: nsis@ietf.org > Subject: [NSIS] attempted summary of pre-emption thread > > > dear all, > > well, this is quite a thread to come back from a short holiday to. > I attempt to make a summary (partly for my own benefit): > > ================== > 1. pre-emption (let's call it 'session pre-emption'?) is a > useful and sometimes mandatory capability within networks > (examples: emergency call handling; operation after capacity > loss e.g. due to partial network failure). > > 2. only the network can decide what sessions to pre-empt in > favour of what other sessions. > > 3. QoS signalling has to carry enough information to enable > the network to make this decision (and that information might > have to be authenticated or otherwise processed to classify > the session securely); however, this information does not > need to be visible to the signalling protocol. > > 4. if a session is pre-empted, the network might (should?) > want to tell affected users that their QoS has been degraded. > ================== > > If this is complete, the implications for NSIS would seem to be: > A) from (3), the QoS data carried has to include particular > information - but since this is opaque to us anyway, there is > no new requirement here. > B) in support of (4), the signalling protocol has to be able > to send an asynchronous message about a QoS change - but I > think we also have this already (for other reasons). > > So, no new requirements. But maybe some more pointers about > how important (B) is and where in the network. (But note: (B) > isn't needed to support pre-emption, it's just a side effect > of doing pre-emption, so maybe the added significance is not great.) > > I've thought hard in the past but can't think of any new > requirements for NSIS from this topic. I'd be interested to see any. > If this method of reasoning is useful, maybe it is helpful to > capture it in the requirements appendix as a scenario > ("here's how a pre-emption event is handled and what NSIS > capabilities are used to do so"), or is that a framework issue? > > robert h. > now to the handover one ... > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu Apr 11 00:10:03 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11153 for ; Thu, 11 Apr 2002 00:10:03 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id AAA10528 for nsis-archive@odin.ietf.org; Thu, 11 Apr 2002 00:10:04 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA09271; Wed, 10 Apr 2002 23:50:46 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA09238 for ; Wed, 10 Apr 2002 23:50:42 -0400 (EDT) Received: from howler.tri.sbc.com (howler.tri.sbc.com [205.173.58.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA10934 for ; Wed, 10 Apr 2002 23:50:37 -0400 (EDT) Received: from sbctri.tri.sbc.com (sbctri [144.60.1.10]) by howler.tri.sbc.com (8.11.6+Sun/8.11.0) with ESMTP id g3B3rTN08626; Wed, 10 Apr 2002 22:53:29 -0500 (CDT) Received: from TRIMAIL2.ad.tri.sbc.com (localhost [127.0.0.1]) by sbctri.tri.sbc.com (8.11.6+Sun/8.9.3) with ESMTP id g3B3nuE14941; Wed, 10 Apr 2002 22:49:56 -0500 (CDT) Received: by TRIMAIL2.ad.tri.sbc.com with Internet Mail Service (5.5.2653.19) id <2P7CA91N>; Wed, 10 Apr 2002 22:50:39 -0500 Message-ID: <905A1C4ABF353F4C8CC16FA9F53DD0D638BA79@TRIMAIL2.ad.tri.sbc.com> From: "Schneider, Marco" To: "'Freytsis, Ilya'" , "'john.loughney@nokia.com'" , "'nsis@ietf.org'" Subject: RE: [NSIS] Interim Meeting Plan Date: Wed, 10 Apr 2002 22:50:30 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="windows-1251" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org John, Ilya: This time works for me and I have privately expressed to John, the alternatively proposed date in June does not. Marco > -----Original Message----- > From: Freytsis, Ilya [mailto:ifreytsis@cetacean.com] > Sent: Tuesday, April 09, 2002 6:47 PM > To: 'john.loughney@nokia.com'; 'nsis@ietf.org' > Subject: Re: [NSIS] Interim Meeting Plan > > > John, > > It works for me. I do not see too many confirmations though. > When the final > decision will be made? > > Ilya Freytsis > Principal Engineer > Cetacean Networks Inc. > ph. (603) 766-6065 > fax (603) 766-7190 > ifreytsis@cetacean.com > > > From: john.loughney@nokia.com > charset="iso-8859-1" > Date: Fri, 5 Apr 2002 10:29:31 +0300 > To: > Subject: [NSIS] Interim Meeting Plan > > Hi all, > > It seems the most likely candidate for the interim meeting will be: > > Helsinki, May 21 - 23 > > Does this work for everybody? > > Topics would include. > > 1) Requirements > 2) Protocol Comparison > 3) Framework Issues > 4) Relations to other work > > thanks, > John > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu Apr 11 00:11:43 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11191 for ; Thu, 11 Apr 2002 00:11:43 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id AAA10646 for nsis-archive@odin.ietf.org; Thu, 11 Apr 2002 00:11:44 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA09394; Wed, 10 Apr 2002 23:53:25 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA09360 for ; Wed, 10 Apr 2002 23:53:21 -0400 (EDT) Received: from howler.tri.sbc.com (howler.tri.sbc.com [205.173.58.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA10964 for ; Wed, 10 Apr 2002 23:53:16 -0400 (EDT) Received: from sbctri.tri.sbc.com (sbctri [144.60.1.10]) by howler.tri.sbc.com (8.11.6+Sun/8.11.0) with ESMTP id g3B3u9N08642; Wed, 10 Apr 2002 22:56:09 -0500 (CDT) Received: from TRIMAIL2.ad.tri.sbc.com (localhost [127.0.0.1]) by sbctri.tri.sbc.com (8.11.6+Sun/8.9.3) with ESMTP id g3B3qaM14985; Wed, 10 Apr 2002 22:52:36 -0500 (CDT) Received: by TRIMAIL2.ad.tri.sbc.com with Internet Mail Service (5.5.2653.19) id <2P7CA91R>; Wed, 10 Apr 2002 22:53:19 -0500 Message-ID: <905A1C4ABF353F4C8CC16FA9F53DD0D638BA7A@TRIMAIL2.ad.tri.sbc.com> From: "Schneider, Marco" To: "'john.loughney@nokia.com'" , nsis@ietf.org Subject: RE: [NSIS] Yet One More Proposal for an Interim Meeting Date: Wed, 10 Apr 2002 22:53:17 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Since we planned all along for a May date, I hope we will stick with what you proposed. I made other committments for June in anticipation of attending in May. Marco > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: Wednesday, April 10, 2002 12:51 AM > To: nsis@ietf.org > Subject: [NSIS] Yet One More Proposal for an Interim Meeting > > > Hi all, > > I've been informed that May 21 - 23 is not good for everyone. > The other > alternative would be to have the meeting June 3rd - 6th in Helsinki. > > Please let me know if this is a problem for anyone, I hope to > finalize the > meeting this week. > > John > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu Apr 11 02:57:53 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21015 for ; Thu, 11 Apr 2002 02:57:53 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA27700 for nsis-archive@odin.ietf.org; Thu, 11 Apr 2002 02:57:56 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA27004; Thu, 11 Apr 2002 02:37:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA26964 for ; Thu, 11 Apr 2002 02:36:58 -0400 (EDT) Received: from mail1.telekom.de (mail1.telekom.de [62.225.183.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20818 for ; Thu, 11 Apr 2002 02:36:54 -0400 (EDT) Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP for nsis@ietf.org; Thu, 11 Apr 2002 08:35:02 +0200 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Thu, 11 Apr 2002 08:36:20 +0200 Message-Id: From: "Geib, Ruediger" To: nsis@ietf.org Subject: RE: [NSIS] attempted summary of pre-emption thread Date: Thu, 11 Apr 2002 08:36:17 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id CAA26965 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hello Martin, > 1) initiator sends QoS request and waits for confirmation (or reject) > 2a) a network entity rejects the request and sends reject > towards initiatior > 2b) all network entities accept the request, so it arrives at > remote end > 3) remote end sends confirmation > 4) transmission time (maybe including periodic state refresh) > 5) initiator sends teardown (maybe through state timeout) > 6) (optional) remote end sends tear confirmation For my clarification: the initiator signals to all units in parallel? If no, then sequential signaling is applied. In the case of sequential signaling, a tear down of one network entity ends the reservation (tear down is propagated uplink, no further action downlink, all messages are synchronus). If your scenario only holds for parallel signaling, then it's a special case, not a general requirement. I'd have more comments on parallel signalling (which are not related to pre-emption) and would like to ask for confirmation that that's what you are suggesting. Regards, Rüdiger _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu Apr 11 04:51:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22459 for ; Thu, 11 Apr 2002 04:51:30 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA04002 for nsis-archive@odin.ietf.org; Thu, 11 Apr 2002 04:51:32 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA03204; Thu, 11 Apr 2002 04:34:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA03165 for ; Thu, 11 Apr 2002 04:34:27 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22272 for ; Thu, 11 Apr 2002 04:34:24 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g3B8Yg507894 for ; Thu, 11 Apr 2002 11:34:42 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 11 Apr 2002 11:34:25 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Thu, 11 Apr 2002 11:34:25 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: pre-emption (was RE: [NSIS] proposals related to NSIS WGdraf t) Date: Thu, 11 Apr 2002 11:34:16 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD38D9C@esebe004.NOE.Nokia.com> Thread-Topic: pre-emption (was RE: [NSIS] proposals related to NSIS WGdraf t) Thread-Index: AcHgho5JMzTh9OLQSPe+jOmeTCnkhgArGhBA To: , Cc: X-OriginalArrivalTime: 11 Apr 2002 08:34:25.0589 (UTC) FILETIME=[B0069E50:01C1E133] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id EAA03166 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Marcus, > I agree with you that it is a network issue, and that on a > user to network interface pre-emption might not make sense. But > does this hold as well for network oriented scenarios? E.g., we > plane to add a scenario where Voice gateways signal for QoS > (in an intra-domain case -> same administrative > domain). > > Does this also mean that pre-emption is not a signaling > protocol issue? Or did we forgot about it? Do you see a case for it? I think that it is a network / service issue actually. For a provider who is providing mostly secure data transport & selling extra capacity for voice, the provider may wish to protect the data traffic (imagine some sort of financial services data) and the voice is secondary .... In my opinion, the service should be able to mark traffic and set policy. I'm not sure if this is a direct signaling protocol issue, but more about how the services is provisioned / provided. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu Apr 11 06:43:43 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23673 for ; Thu, 11 Apr 2002 06:43:43 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA08905 for nsis-archive@odin.ietf.org; Thu, 11 Apr 2002 06:43:44 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA07951; Thu, 11 Apr 2002 06:27:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA07920 for ; Thu, 11 Apr 2002 06:27:56 -0400 (EDT) Received: from iraun2.uka.de (iraun2.uka.de [129.13.10.91]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23549 for ; Thu, 11 Apr 2002 06:27:54 -0400 (EDT) Received: from irams1.ira.uka.de ([129.13.10.5]) by iraun2.uka.de with esmtp (Exim 3.30 #7 (Debian)) id 16vbo2-0006nr-00; Thu, 11 Apr 2002 12:27:54 +0200 Received: from i72pc127.tm.uni-karlsruhe.de ([141.3.70.78] helo=i72pc127.tm.uka.de) by irams1.ira.uka.de with esmtp (Exim 3.30 #7 (Debian)) id 16vbo1-0001iP-00; Thu, 11 Apr 2002 12:27:53 +0200 Received: from tpce10.ipv6.tm.uka.de (localhost [127.0.0.1]) by i72pc127.tm.uka.de (8.11.6/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id g3BARqf32333; Thu, 11 Apr 2002 12:27:52 +0200 Message-Id: <200204111027.g3BARqf32333@i72pc127.tm.uka.de> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4+dev To: john.loughney@nokia.com cc: nsis@ietf.org Subject: Re: [NSIS] Yet One More Proposal for an Interim Meeting In-Reply-To: Message from john.loughney@nokia.com of "Wed, 10 Apr 2002 08:50:55 +0300." <0C1353ABB1DEB74DB067ADFF749C4EEFC64E4C@esebe004.NOE.Nokia.com> References: <0C1353ABB1DEB74DB067ADFF749C4EEFC64E4C@esebe004.NOE.Nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 11 Apr 2002 12:27:52 +0200 From: Roland Bless Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org > Hi all, > > I've been informed that May 21 - 23 is not good for everyone. The other > alternative would be to have the meeting June 3rd - 6th in Helsinki. > > Please let me know if this is a problem for anyone, I hope to finalize the > meeting this week. I would prefer a meeting in May. Regards, Roland -- Roland Bless -- e-Mail: bless@tm.uka.de Institute of Telematics, University of Karlsruhe, Germany Zirkel 2, D-76128 Karlsruhe -- Office: Bld. 20.20, 3rd floor, R 358 Phone: +49 721 608-6413 Fax: +49 721 388097 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu Apr 11 06:44:20 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23690 for ; Thu, 11 Apr 2002 06:44:20 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA08920 for nsis-archive@odin.ietf.org; Thu, 11 Apr 2002 06:44:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA08614; Thu, 11 Apr 2002 06:31:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA08585 for ; Thu, 11 Apr 2002 06:31:36 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23604 for ; Thu, 11 Apr 2002 06:31:34 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g3BAVo528246 for ; Thu, 11 Apr 2002 13:31:51 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 11 Apr 2002 13:31:34 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Thu, 11 Apr 2002 13:31:33 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Thu, 11 Apr 2002 13:31:33 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64E88@esebe004.NOE.Nokia.com> Thread-Topic: [NSIS] Yet One More Proposal for an Interim Meeting Thread-Index: AcHhQ5G3JSSKKJ2nTvWth8BOZ37CSgAACTmg To: Cc: X-OriginalArrivalTime: 11 Apr 2002 10:31:33.0955 (UTC) FILETIME=[0D422930:01C1E144] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id GAA08586 Subject: [NSIS] Final Date for Interim Meeting Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi all, It seems that the best choice of dates for the interim meeting are: DATE: May 21 - 23 Place: Helsinki, Finland I will start checking into local hotels, to see if we can get a special rate. thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu Apr 11 10:26:19 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28108 for ; Thu, 11 Apr 2002 10:26:19 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA18903 for nsis-archive@odin.ietf.org; Thu, 11 Apr 2002 10:26:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA17428; Thu, 11 Apr 2002 09:59:31 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA17395 for ; Thu, 11 Apr 2002 09:59:29 -0400 (EDT) Received: from arb-exchange1.cetaceannetworks.com ([63.127.199.195]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27425 for ; Thu, 11 Apr 2002 09:59:25 -0400 (EDT) Received: by mail.cetaceannetworks.com with Internet Mail Service (5.5.2653.19) id <2TMYZ3M9>; Thu, 11 Apr 2002 09:54:47 -0400 Message-ID: <6D8664171C38D511B5AD0002B325CE66A93082@mail.cetaceannetworks.com> From: "Freytsis, Ilya" To: "'schneider@tri.sbc.com'" Cc: "'nsis@ietf.org'" Subject: RE: pre-emption (was RE: [NSIS] proposals related to NSIS WGdraf t) Date: Thu, 11 Apr 2002 09:54:46 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="windows-1251" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Marco, I fully support your position. Honestly, I was a little bit surprised by the intensity of this discussion and how much time it has taken. I still do not understand what exactly James (Polk) wanted to see included in NSIS requirements. Ilya Related to the issue of preemption, a group of us discussed the issue of reservation lifetime while in Minneapolis. Our conclusion was that this could be done transparently by building it into the service description which is carried by, but not visible to, NSIS. Reservation lifetime would only be seen in a service specific field which is part of the service description and transparent to NSIS. It seems to me that while pre-emption is a different concern than reservation lifetime, it still can be supported in the same way. The only requirement that seems necessary is that NSIS must support the ability of a QOS controller to release an existing connection. Specific cause codes would be specific to the service and are out of scope and transparent to NSIS. Comments? Marco _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu Apr 11 10:59:43 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29107 for ; Thu, 11 Apr 2002 10:59:43 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA21554 for nsis-archive@odin.ietf.org; Thu, 11 Apr 2002 10:59:47 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA20423; Thu, 11 Apr 2002 10:48:45 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA20389 for ; Thu, 11 Apr 2002 10:48:43 -0400 (EDT) Received: from idcpa4.pa.interdigital.com (idcmail.interdigital.com [12.32.197.142]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28626 for ; Thu, 11 Apr 2002 10:48:39 -0400 (EDT) Received: by idcpa4.interdigital.com with Internet Mail Service (5.5.2653.19) id <2S831L4G>; Thu, 11 Apr 2002 10:46:57 -0400 Message-ID: From: "Shahrier, Sharif M." To: "'john.loughney@nokia.com'" Cc: nsis@ietf.org Subject: RE: [NSIS] Final Date for Interim Meeting Date: Thu, 11 Apr 2002 10:46:51 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org John, Could you please post what the format of the interim meeting is to be. I have an I-D hoping to submit next week, and would like to present slides on it at the meeting. Thanks. Sharif. -----Original Message----- From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] Sent: Thursday, April 11, 2002 6:32 AM To: bless@tm.uka.de Cc: nsis@ietf.org Subject: [NSIS] Final Date for Interim Meeting Hi all, It seems that the best choice of dates for the interim meeting are: DATE: May 21 - 23 Place: Helsinki, Finland I will start checking into local hotels, to see if we can get a special rate. thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu Apr 11 11:05:54 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29350 for ; Thu, 11 Apr 2002 11:05:54 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA22293 for nsis-archive@odin.ietf.org; Thu, 11 Apr 2002 11:04:44 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA20589; Thu, 11 Apr 2002 10:51:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA20557 for ; Thu, 11 Apr 2002 10:51:56 -0400 (EDT) Received: from mailserver.KOM.e-technik.tu-darmstadt.de (drum.kom.e-technik.tu-darmstadt.de [130.83.139.190]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28759 for ; Thu, 11 Apr 2002 10:51:48 -0400 (EDT) Received: from KOM.tu-darmstadt.de by mailserver.KOM.e-technik.tu-darmstadt.de (8.7.5/8.7.5) with ESMTP id QAA04965; Thu, 11 Apr 2002 16:51:14 +0200 (MET DST) From: Martin Karsten Received: from KOM.tu-darmstadt.de by KOM.tu-darmstadt.de (8.11.2/8.7.5) id g3BEoik10478; Thu, 11 Apr 2002 16:50:44 +0200 Message-Id: <200204111450.g3BEoik10478@KOM.tu-darmstadt.de> Subject: Re: [NSIS] attempted summary of pre-emption thread In-Reply-To: from "Geib, Ruediger" at "Apr 11, 2002 08:35:37 am" To: "Geib, Ruediger" Date: Thu, 11 Apr 2002 16:50:44 +0200 (CEST) CC: nsis@ietf.org X-Mailer: ELM [version 2.4ME+ PL66 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit > > 1) initiator sends QoS request and waits for confirmation (or reject) > > 2a) a network entity rejects the request and sends reject > > towards initiatior > > 2b) all network entities accept the request, so it arrives at > > remote end > > 3) remote end sends confirmation > > 4) transmission time (maybe including periodic state refresh) > > 5) initiator sends teardown (maybe through state timeout) > > 6) (optional) remote end sends tear confirmation > > For my clarification: the initiator signals to all units in parallel? > If no, then sequential signaling is applied. In the case of > sequential signaling, a tear down of one network entity ends the > reservation (tear down is propagated uplink, no further action > downlink, all messages are synchronus). > If your scenario only holds for parallel signaling, then it's a > special case, not a general requirement. I'd have more comments on > parallel signalling (which are not related to pre-emption) and would > like to ask for confirmation that that's what you are suggesting. The dummy protocol above was not meant as suggestion at all, but just as a very simplified (and probably unrealistic) example for illustration only. I don't think that it makes sense to further discuss it. Martin _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu Apr 11 17:34:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15764 for ; Thu, 11 Apr 2002 17:34:01 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA14999 for nsis-archive@odin.ietf.org; Thu, 11 Apr 2002 17:34:04 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA14209; Thu, 11 Apr 2002 17:26:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA14180 for ; Thu, 11 Apr 2002 17:26:53 -0400 (EDT) Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15449 for ; Thu, 11 Apr 2002 17:26:47 -0400 (EDT) Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate3.mot.com (motgate3 2.1) with ESMTP id OAA06251 for ; Thu, 11 Apr 2002 14:15:16 -0700 (MST)] Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id OAA22908 for ; Thu, 11 Apr 2002 14:26:48 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2654.52) id <2NGDG5B5>; Thu, 11 Apr 2002 16:26:48 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B04650067@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'Freytsis, Ilya'" , schneider@tri.sbc.com Cc: nsis@ietf.org Subject: RE: pre-emption (was RE: [NSIS] proposals related to NSIS WGdraf t) Date: Thu, 11 Apr 2002 16:26:47 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain; charset="Windows-1251" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi, I have not been following this discussion closely, so sorry if this has been brought up. My question is, if NSIS does not intend to use refreshes and just add reservation lifetime as opaque info to the NSIS messages, then inherent reliability mechanism that RSVP was getting from refreshes is gone?? Did I miss something? Regards, Madjid -----Original Message----- From: Freytsis, Ilya [mailto:ifreytsis@cetacean.com] Sent: Thursday, April 11, 2002 8:55 AM To: schneider@tri.sbc.com Cc: nsis@ietf.org Subject: RE: pre-emption (was RE: [NSIS] proposals related to NSIS WGdraf t) Marco, I fully support your position. Honestly, I was a little bit surprised by the intensity of this discussion and how much time it has taken. I still do not understand what exactly James (Polk) wanted to see included in NSIS requirements. Ilya Related to the issue of preemption, a group of us discussed the issue of reservation lifetime while in Minneapolis. Our conclusion was that this could be done transparently by building it into the service description which is carried by, but not visible to, NSIS. Reservation lifetime would only be seen in a service specific field which is part of the service description and transparent to NSIS. It seems to me that while pre-emption is a different concern than reservation lifetime, it still can be supported in the same way. The only requirement that seems necessary is that NSIS must support the ability of a QOS controller to release an existing connection. Specific cause codes would be specific to the service and are out of scope and transparent to NSIS. Comments? Marco _______________________________________________ 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 daemon@optimus.ietf.org Fri Apr 12 00:09:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15753 for ; Fri, 12 Apr 2002 00:09:55 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id AAA08304 for nsis-archive@odin.ietf.org; Fri, 12 Apr 2002 00:09:56 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA07440; Thu, 11 Apr 2002 23:58:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA07411 for ; Thu, 11 Apr 2002 23:58:20 -0400 (EDT) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14217 for ; Thu, 11 Apr 2002 23:58:16 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g3C3vQu16433 for ; Fri, 12 Apr 2002 06:57:26 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 12 Apr 2002 06:58:18 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Fri, 12 Apr 2002 06:58:18 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] Final Date for Interim Meeting Date: Fri, 12 Apr 2002 06:58:17 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64EA2@esebe004.NOE.Nokia.com> Thread-Topic: [NSIS] Final Date for Interim Meeting Thread-Index: AcHhZ+jeS6XwvjqjRlKNWXQ50+sxGgAbhoXw To: Cc: X-OriginalArrivalTime: 12 Apr 2002 03:58:18.0388 (UTC) FILETIME=[479E1D40:01C1E1D6] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id XAA07413 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Sharif, > Could you please post what the format of the interim > meeting is to be. I have an I-D hoping to submit next week, and would like > to present slides on it at the meeting. I think we need to work on these 3 topics: 1) Requirements 2) Signaling Comparison 3) Framework If people want to prepare some introductory material on the above subjects (the more specific, the better) then that would be good. Additionally, if anyone things that there is something that we should also cover, then please suggest it. thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Apr 12 00:29:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18342 for ; Fri, 12 Apr 2002 00:29:47 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id AAA08947 for nsis-archive@odin.ietf.org; Fri, 12 Apr 2002 00:29:48 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA08607; Fri, 12 Apr 2002 00:19:20 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA08580 for ; Fri, 12 Apr 2002 00:19:18 -0400 (EDT) Received: from arb-exchange1.cetaceannetworks.com ([63.127.199.195]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17006 for ; Fri, 12 Apr 2002 00:19:13 -0400 (EDT) Received: by mail.cetaceannetworks.com with Internet Mail Service (5.5.2653.19) id <2TMYZPWV>; Fri, 12 Apr 2002 00:14:36 -0400 Message-ID: <6D8664171C38D511B5AD0002B325CE66A9308A@mail.cetaceannetworks.com> From: "Freytsis, Ilya" To: "'Nakhjiri Madjid-MNAKHJI1'" , "Freytsis, Ilya" , schneider@tri.sbc.com Cc: nsis@ietf.org Subject: RE: pre-emption (was RE: [NSIS] proposals related to NSIS WGdraf t) Date: Fri, 12 Apr 2002 00:14:26 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="windows-1251" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Madjid, Reservation lifetime (applicable for soft reservations as well as hard reservations) is not meant to replace the refreshes that are needed for the soft state based reservations. Ilya -----Original Message----- From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] Sent: Thursday, April 11, 2002 5:27 PM To: 'Freytsis, Ilya'; schneider@tri.sbc.com Cc: nsis@ietf.org Subject: RE: pre-emption (was RE: [NSIS] proposals related to NSIS WGdraf t) Hi, I have not been following this discussion closely, so sorry if this has been brought up. My question is, if NSIS does not intend to use refreshes and just add reservation lifetime as opaque info to the NSIS messages, then inherent reliability mechanism that RSVP was getting from refreshes is gone?? Did I miss something? Regards, Madjid -----Original Message----- From: Freytsis, Ilya [mailto:ifreytsis@cetacean.com] Sent: Thursday, April 11, 2002 8:55 AM To: schneider@tri.sbc.com Cc: nsis@ietf.org Subject: RE: pre-emption (was RE: [NSIS] proposals related to NSIS WGdraf t) Marco, I fully support your position. Honestly, I was a little bit surprised by the intensity of this discussion and how much time it has taken. I still do not understand what exactly James (Polk) wanted to see included in NSIS requirements. Ilya Related to the issue of preemption, a group of us discussed the issue of reservation lifetime while in Minneapolis. Our conclusion was that this could be done transparently by building it into the service description which is carried by, but not visible to, NSIS. Reservation lifetime would only be seen in a service specific field which is part of the service description and transparent to NSIS. It seems to me that while pre-emption is a different concern than reservation lifetime, it still can be supported in the same way. The only requirement that seems necessary is that NSIS must support the ability of a QOS controller to release an existing connection. Specific cause codes would be specific to the service and are out of scope and transparent to NSIS. Comments? Marco _______________________________________________ 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 daemon@optimus.ietf.org Fri Apr 12 09:54:51 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25172 for ; Fri, 12 Apr 2002 09:54:51 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA16821 for nsis-archive@odin.ietf.org; Fri, 12 Apr 2002 09:54:53 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA16481; Fri, 12 Apr 2002 09:45:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA16452 for ; Fri, 12 Apr 2002 09:45:05 -0400 (EDT) Received: from idcpa4.pa.interdigital.com (idcmail.interdigital.com [12.32.197.142]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23634 for ; Fri, 12 Apr 2002 09:44:57 -0400 (EDT) Received: by idcpa4.interdigital.com with Internet Mail Service (5.5.2653.19) id <2S8313T8>; Fri, 12 Apr 2002 09:42:48 -0400 Message-ID: From: "Shahrier, Sharif M." To: "'john.loughney@nokia.com'" Cc: "'nsis@ietf.org'" Subject: RE: [NSIS] Final Date for Interim Meeting Date: Fri, 12 Apr 2002 09:42:43 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org John, I actually have a solution for the signaling protocol. I wanted to present it to the people, and get some feedback. I am planning to start simulations about now, so I was hoping to incorporate changes based to suggestions I get back. I will let you know the title of the topic next week. Sharif. -----Original Message----- From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] Sent: Thursday, April 11, 2002 11:58 PM To: Sharif.Shahrier@interdigital.com Cc: nsis@ietf.org Subject: RE: [NSIS] Final Date for Interim Meeting Hi Sharif, > Could you please post what the format of the interim > meeting is to be. I have an I-D hoping to submit next week, and would like > to present slides on it at the meeting. I think we need to work on these 3 topics: 1) Requirements 2) Signaling Comparison 3) Framework If people want to prepare some introductory material on the above subjects (the more specific, the better) then that would be good. Additionally, if anyone things that there is something that we should also cover, then please suggest it. thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Fri Apr 12 10:15:11 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27695 for ; Fri, 12 Apr 2002 10:15:10 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA18121 for nsis-archive@odin.ietf.org; Fri, 12 Apr 2002 10:15:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA16980; Fri, 12 Apr 2002 09:58:53 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA16949 for ; Fri, 12 Apr 2002 09:58:51 -0400 (EDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25573 for ; Fri, 12 Apr 2002 09:58:46 -0400 (EDT) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g3CDwm3G012030 for ; Fri, 12 Apr 2002 15:58:48 +0200 (MEST) Received: FROM esealnt747.al.sw.ericsson.se BY esealnt461 ; Fri Apr 12 15:48:15 2002 +0200 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id <2281XG6S>; Fri, 12 Apr 2002 15:48:16 +0200 Message-ID: From: "Georgios Karagiannis (ELN)" To: "'Schneider, Marco'" , "'john.loughney@nokia.com'" , Anders.P.Bergsten@telia.se Cc: nsis@ietf.org Subject: RE: pre-emption (was RE: [NSIS] proposals related to NSIS WGdraf t) Date: Fri, 12 Apr 2002 15:43:58 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi Marco I agree with your proposal! Best regards, georgios -----Original Message----- From: Schneider, Marco [mailto:schneider@tri.sbc.com] Sent: donderdag 11 april 2002 5:18 To: 'john.loughney@nokia.com'; Anders.P.Bergsten@telia.se Cc: nsis@ietf.org Subject: RE: pre-emption (was RE: [NSIS] proposals related to NSIS WGdraf t) Related to the issue of preemption, a group of us discussed the issue of reservation lifetime while in Minneapolis. Our conclusion was that this could be done transparently by building it into the service description which is carried by, but not visible to, NSIS. Reservation lifetime would only be seen in a service specific field which is part of the service description and transparent to NSIS. It seems to me that while pre-emption is a different concern than reservation lifetime, it still can be supported in the same way. The only requirement that seems necessary is that NSIS must support the ability of a QOS controller to release an existing connection. Specific cause codes would be specific to the service and are out of scope and transparent to NSIS. Comments? Marco > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: Monday, April 08, 2002 3:53 AM > To: Anders.P.Bergsten@telia.se > Cc: nsis@ietf.org > Subject: RE: pre-emption (was RE: [NSIS] proposals related to NSIS > WGdraf t) > > > Hi Anders, > > > not sure I understand, requesting resources for something is > > in charter, I persume. What I stated was: there is one > > instance where I see a need for pre-emption in signaling and > > this is related to emergency calls. > > Should the protocol support pre-emption or should the network? > > My opinion is that it is network policy to determine how to > do pre-emption, not a protocol issue. > > John > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Fri Apr 12 13:21:04 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22097 for ; Fri, 12 Apr 2002 13:21:03 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA29257 for nsis-archive@odin.ietf.org; Fri, 12 Apr 2002 13:21:03 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27729; Fri, 12 Apr 2002 12:45:45 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27697 for ; Fri, 12 Apr 2002 12:45:43 -0400 (EDT) Received: from yamato.ccrle.nec.de (yamato.ccrle.nec.de [195.37.70.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17426 for ; Fri, 12 Apr 2002 12:45:39 -0400 (EDT) Received: from citadel.mobility.ccrle.nec.de ([192.168.156.1]) by yamato.ccrle.nec.de (8.11.6/8.10.1) with ESMTP id g3CGkWL40124 for ; Fri, 12 Apr 2002 18:46:32 +0200 (CEST) Received: from [192.168.102.79] (madrid.heidelberg.ccrle.nec.de [192.168.102.79]) by citadel.mobility.ccrle.nec.de (Postfix on SuSE eMail Server 2.0) with ESMTP id 6124DC051 for ; Fri, 12 Apr 2002 18:44:26 +0200 (CEST) Date: Fri, 12 Apr 2002 18:54:16 +0200 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de To: nsis@ietf.org Message-ID: <30949302.1018637656@[192.168.102.79]> X-Mailer: Mulberry/2.1.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Subject: [NSIS] new version of draft (-01) submitted Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit Dear NSIS WG, I have just now submitted a new version of the reqirements draft. It is meant to be an intermediate version to give you an impression of what has been going on in the last weeks. Major changes include - restructured the draft - added an extensive list of open and closed isues, coming from various places. -please check them whether is something miosssing from the issues side -some have volunteered to help with some of the issue (see the mail "home work" addressed to those) -some of the closed issues can be used as a change log - I currently see the following three areas, which are not covered - interaction with mobility and running signaling in mobile environements - security issues - fault handling issues - I am sorry, I am not able to put the thing on a web-page for those, which can not wait and want to work over the weekend :-) Marcus -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ personal home page: http://www.brubers.org/marcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Mon Apr 15 03:46:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08935 for ; Mon, 15 Apr 2002 03:46:02 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA23383 for nsis-archive@odin.ietf.org; Mon, 15 Apr 2002 03:46:05 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA23123; Mon, 15 Apr 2002 03:33:40 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA23080 for ; Mon, 15 Apr 2002 03:33:37 -0400 (EDT) Received: from DESKTOP (h00207818a19b.ne.client2.attbi.com [24.60.238.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA08857 for ; Mon, 15 Apr 2002 03:33:34 -0400 (EDT) Message-Id: <200204150733.DAA08857@ietf.org> From: "Adam Erickson" To: Mime-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Date: Mon, 15 Apr 2002 03:34:02 -0400 Subject: [NSIS] Resume Writing and Distribution Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Dear Job Seeker,


How can we help you find your DREAM JOB?

Resume Author.com is an established resume writing and distribution firm that specializes in custom-tailored career development. We have a dedicated staff of resume writers and an Opt-In E-mail Distribution Network of over 19,000 recruiters and employers (We can have your professional resume in their hands in a matter of minutes).

We're so confident in the effectiveness of our services that we guarantee job interviews!!!

Learn more about the most effective career marketing services available.

Resume Writing & Editing Services Click Here
Starting at only 79.95

E-mail Resume Distribution Services Click Here
Starting at only 29.95


Best Regards,

Adam Erickson
Client Development,
Resume Author


Would you like to test our quality? We provide a FREE Resume Critique for all interested parties.




CONCERNED ABOUT JUNK MAIL? SO ARE WE.

As a ResumeAuthor.com Sales Representative, I believe you meet the criteria we look for in a resume writing and distribution customer. If, however, you feel that you have received this email in error, I apologize. We will comply with all removal requests. To be removed type "remove" in the subject line and MAIL TO:aerickson@resumeauthor.com this is the only way to be removed. Hitting reply will NOT remove you.

This message is sent in compliance of the new email bill section 301.Per Section 301, Paragraph (a)(2)(C) of S. 1618. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Mon Apr 15 04:24:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09924 for ; Mon, 15 Apr 2002 04:24:46 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA27236 for nsis-archive@odin.ietf.org; Mon, 15 Apr 2002 04:24:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA26658; Mon, 15 Apr 2002 04:16:46 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA26626 for ; Mon, 15 Apr 2002 04:16:43 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09780 for ; Mon, 15 Apr 2002 04:16:35 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g3F8Gp523892 for ; Mon, 15 Apr 2002 11:16:51 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 15 Apr 2002 11:16:33 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Mon, 15 Apr 2002 11:16:32 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] Final Date for Interim Meeting Date: Mon, 15 Apr 2002 11:16:30 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD38DA2@esebe004.NOE.Nokia.com> Thread-Topic: [NSIS] Final Date for Interim Meeting Thread-Index: AcHiKCzXYs2vzsNnQ9eH8cr3C3x4jACLXrgw To: Cc: X-OriginalArrivalTime: 15 Apr 2002 08:16:32.0972 (UTC) FILETIME=[DA5940C0:01C1E455] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id EAA26628 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Sharif, > I actually have a solution for the signaling protocol. > I wanted to present it to the people, and get some feedback. I am > planning to start simulations about now, so I was hoping to incorporate > changes based to suggestions I get back. I will let you know the title > of the topic next week. First, the interim meeting will be for discussing current drafts, so if you want to discuss this, then it needs to be documented in a draft. Second, I'm a little hesitant to start discussing solutions. It is too early, as we are still discussing requirements. best regards, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Mon Apr 15 07:37:39 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13324 for ; Mon, 15 Apr 2002 07:37:38 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA06782 for nsis-archive@odin.ietf.org; Mon, 15 Apr 2002 07:37:37 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA06033; Mon, 15 Apr 2002 07:29:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA05996 for ; Mon, 15 Apr 2002 07:29:52 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13127; Mon, 15 Apr 2002 07:29:49 -0400 (EDT) Message-Id: <200204151129.HAA13127@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: nsis@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Mon, 15 Apr 2002 07:29:49 -0400 Subject: [NSIS] I-D ACTION:draft-ietf-nsis-req-01.txt Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Next Steps in Signaling Working Group of the IETF. Title : Requirements for QoS Signaling Protocols Author(s) : M. Brunner Filename : draft-ietf-nsis-req-01.txt Pages : 47 Date : 12-Apr-02 This document defines requirements for signaling QoS across different network environments. To achieve wide applicability of the requirements, the starting point is a diverse set of scenarios/use cases concerning various types of networks and application interactions. We also provide an outline structure for the problem, including QoS related terminology. Taken with the scenarios, this allows us to focus more precisely on which parts of the overall QoS problem needs to be solved. We present the assumptions and the aspects not considered within scope before listing the requirements grouped according to areas such as architecture and design goals, signaling flows, layering, performance, flexibility, security, and mobility. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nsis-req-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-nsis-req-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-nsis-req-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020412140701.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nsis-req-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nsis-req-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020412140701.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Mon Apr 15 08:14:34 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14292 for ; Mon, 15 Apr 2002 08:14:34 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA08382 for nsis-archive@odin.ietf.org; Mon, 15 Apr 2002 08:14:37 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA08185; Mon, 15 Apr 2002 08:08:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA08159 for ; Mon, 15 Apr 2002 08:08:56 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14210 for ; Mon, 15 Apr 2002 08:08:52 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g3FC9A514607 for ; Mon, 15 Apr 2002 15:09:10 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 15 Apr 2002 15:08:52 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Mon, 15 Apr 2002 15:08:52 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] new version of draft (-01) submitted Date: Mon, 15 Apr 2002 15:08:52 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64EFA@esebe004.NOE.Nokia.com> Thread-Topic: [NSIS] new version of draft (-01) submitted Thread-Index: AcHiQfEwNs1ka6JcTZydNCqxCaPATwCNEhMQ To: , X-OriginalArrivalTime: 15 Apr 2002 12:08:52.0493 (UTC) FILETIME=[4EF35BD0:01C1E476] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id IAA08160 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Marcus, Thanks for getting this out, but the formatting is off. If you can re-format it & send me a copy, I can provide webspace for it. John > -----Original Message----- > From: ext Marcus Brunner [mailto:brunner@ccrle.nec.de] > Sent: 12 April, 2002 19:54 > To: nsis@ietf.org > Subject: [NSIS] new version of draft (-01) submitted > > > Dear NSIS WG, > > I have just now submitted a new version of the reqirements draft. > It is meant to be an intermediate version to give you an > impression of what > has been going on in the last weeks. > > Major changes include > - restructured the draft > - added an extensive list of open and closed isues, coming from > various places. > -please check them whether is something miosssing from > the issues side > -some have volunteered to help with some of the issue > (see the mail > "home work" addressed to those) > -some of the closed issues can be used as a change log > - I currently see the following three areas, which are not covered > - interaction with mobility and running signaling > in mobile environements > - security issues > - fault handling issues > > - I am sorry, I am not able to put the thing on a web-page > for those, which > can not wait and want to work over the weekend :-) > > Marcus > > -------------------------------------- > Dr. Marcus Brunner > Network Laboratories > NEC Europe Ltd. > > E-Mail: brunner@ccrle.nec.de > WWW: http://www.ccrle.nec.de/ > personal home page: http://www.brubers.org/marcus > > > > _______________________________________________ > 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 daemon@ns.ietf.org Mon Apr 15 10:19:47 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18509 for ; Mon, 15 Apr 2002 10:19:47 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA15628 for nsis-archive@odin.ietf.org; Mon, 15 Apr 2002 10:19:50 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA14512; Mon, 15 Apr 2002 10:05:29 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA14481 for ; Mon, 15 Apr 2002 10:05:26 -0400 (EDT) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18009; Mon, 15 Apr 2002 10:05:21 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g3FE4Su14528; Mon, 15 Apr 2002 17:04:29 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 15 Apr 2002 17:05:22 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Mon, 15 Apr 2002 17:05:21 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Mon, 15 Apr 2002 17:05:20 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64F05@esebe004.NOE.Nokia.com> Thread-Topic: NSIS Interim Meeting Thread-Index: AcHkhpR6XFVdIuc4S5e0nGYTs/T39g== To: , Cc: , X-OriginalArrivalTime: 15 Apr 2002 14:05:21.0316 (UTC) FILETIME=[949D1E40:01C1E486] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id KAA14482 Subject: [NSIS] NSIS Interim Meeting Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi all, NSIS will be having an Interim Meeting from May 21st through May 23rd, in Helsinki, Finland. Meeting location is tentatively planned to be at the Nokia Research Center facilities, at Itämerenkatu 11-13 in Helsinki. On a map, the location is here: http://kartta.hel.fi/kktesti/osoitehakuen/bigmap.asp?SearchOp=katunumero2&Desc=ITÄMERENKATU%2011%20HELSINKI%20&XValue=51042&YValue=72829 A good overview of Helsinki can be found here: http://www.explore-helsinki.com/ There are 2 hotels with special room rates, mention that you are Nokia guests when booking/paying a hotel room, so you can get the Nokia price. Seaside hotel: single room 90EUR, double room 112EUR Address: Ruoholahdenranta 3 FIN-00180 Helsinki, Finland Tel. +358 (0)9 693 60 Sales: +358 (0)9 6936 1016 Fax: +358 (0)9 6932 123 e-mail: seaside@seasidehotel.fi Web: www.seasidehotel.fi Toll free: 9800 2010 Best Western Worldwide Radisson SAS Royal hotel: single and double room 110EUR Address: Runeberginkatu, 2 SF-00100 Helsinki, Finland Phone: +358 9 695 80 Email: sales.royal.helsinki@radissonsas.com http://www.radisson.com/helsinkifi Helsinki is served by most major airlines. Busses are available from the Helsinki-Vanta Airport to the center of Helsinki, where there the hotels are located. Taxi service is available as well. It takes about 20 to 30 minutes to get to the center from the airport. The rough agenda is as follows: Tuesday May 21st 10 AM to 4 PM Wednesday May 22nd 9 AM to 4 PM Thursday May 23rd 9 AM to 12 Noon Topics are (dependent on draft submissions): Signaling Requirements. Analysis of existing signaling protocols. Framework Signaling Architecture Please indicate your attendance Wed ___ Thurs ___ Fri ___ Thank you, John Loughney _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Mon Apr 15 10:30:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18938 for ; Mon, 15 Apr 2002 10:30:31 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA16528 for nsis-archive@odin.ietf.org; Mon, 15 Apr 2002 10:30:35 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA14714; Mon, 15 Apr 2002 10:09:53 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA14684 for ; Mon, 15 Apr 2002 10:09:50 -0400 (EDT) Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18158 for ; Mon, 15 Apr 2002 10:09:45 -0400 (EDT) Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g3FE9H859261 for ; Mon, 15 Apr 2002 16:09:17 +0200 (CEST) (envelope-from brunner@ccrle.nec.de) Received: from imap.heidelberg.ccrle.nec.de (imap.heidelberg.ccrle.nec.de [192.168.102.11]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA06280 for ; Mon, 15 Apr 2002 16:08:23 +0200 Received: by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0, from userid 30) id 713B93D3B9; Mon, 15 Apr 2002 16:08:22 +0200 (CEST) X-Accept-Language: de, en X-Priority: 3 (Normal) X-Mailer: SKYRiXgreen From: Marcus Brunner MIME-Version: 1.0 To: Organization: NEC Europe Ltd. Content-type: text/plain; charset= "iso-8859-1" Date: Mon, 15 Apr 2002 16:08:22 +0200 Content-transfer-encoding: 7bit Message-Id: <20020415140822.713B93D3B9@imap.heidelberg.ccrle.nec.de> Content-Transfer-Encoding: 7bit Subject: [NSIS] acknowledgement Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit I have to publicly appologize that I forgot to acknowledge the work of a set of people. I just forgot it in a hurry. Mainly, Sven and his draft authors (draft-bucheli-...) I forgot. Sorry again and I will include you in the next version. Marcus ------- Marcus Brunner Network Labs NEC Europe Ltd Heidelberg, Germany E-Mail: brunner@ccrle.nec.de WWW: www.brubers.org/marcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Thu Apr 18 11:08:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09671 for ; Thu, 18 Apr 2002 11:08:07 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA03608 for nsis-archive@odin.ietf.org; Thu, 18 Apr 2002 11:08:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA02339; Thu, 18 Apr 2002 10:53:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA02310 for ; Thu, 18 Apr 2002 10:53:35 -0400 (EDT) Received: from idcpa4.pa.interdigital.com ([12.32.197.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09056 for ; Thu, 18 Apr 2002 10:53:30 -0400 (EDT) Received: by idcpa4.interdigital.com with Internet Mail Service (5.5.2653.19) id ; Thu, 18 Apr 2002 10:51:17 -0400 Message-ID: From: "Shahrier, Sharif M." To: "'john.loughney@nokia.com'" , nsis@ietf.org Subject: RE: [NSIS] Framework document Date: Thu, 18 Apr 2002 10:51:16 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Topics are (dependent on draft submissions): Signaling Requirements. Analysis of existing signaling protocols. Framework Signaling Architecture I was wondering if there was an I-D on the framework signaling architecture at this time? Sharif. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Fri Apr 19 00:26:06 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01941 for ; Fri, 19 Apr 2002 00:26:04 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id AAA27066 for nsis-archive@odin.ietf.org; Fri, 19 Apr 2002 00:26:04 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA26719; Fri, 19 Apr 2002 00:18:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA26687 for ; Fri, 19 Apr 2002 00:18:00 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01647 for ; Fri, 19 Apr 2002 00:17:58 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g3J4IGF13254 for ; Fri, 19 Apr 2002 07:18:16 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 19 Apr 2002 07:17:58 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Fri, 19 Apr 2002 07:17:57 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] Framework document Date: Fri, 19 Apr 2002 07:17:57 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64F76@esebe004.NOE.Nokia.com> Thread-Topic: [NSIS] Framework document Thread-Index: AcHm6MBwc27W7cGwQLujYw0Rw/s0kwAcFR8Q To: , X-OriginalArrivalTime: 19 Apr 2002 04:17:58.0106 (UTC) FILETIME=[2FAD0BA0:01C1E759] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id AAA26688 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Sharif, There are some individual submissions. I'd like (at least) in the interim meeting to discuss these & see how to move forward on the draft. John > -----Original Message----- > From: ext Shahrier, Sharif M. > [mailto:Sharif.Shahrier@InterDigital.com] > Sent: 18 April, 2002 17:51 > To: Loughney John (NRC/Helsinki); nsis@ietf.org > Subject: RE: [NSIS] Framework document > > > > > Topics are (dependent on draft submissions): > Signaling Requirements. > Analysis of existing signaling protocols. > Framework Signaling Architecture > > I was wondering if there was an I-D on the framework > signaling architecture > at this time? > > Sharif. > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Fri Apr 19 09:57:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20168 for ; Fri, 19 Apr 2002 09:57:12 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA11003 for nsis-archive@odin.ietf.org; Fri, 19 Apr 2002 09:57:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA10431; Fri, 19 Apr 2002 09:50:31 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA10399 for ; Fri, 19 Apr 2002 09:50:28 -0400 (EDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19920 for ; Fri, 19 Apr 2002 09:50:23 -0400 (EDT) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g3JDoK3G015311 for ; Fri, 19 Apr 2002 15:50:20 +0200 (MEST) Received: FROM esealnt746.al.sw.ericsson.se BY esealnt461 ; Fri Apr 19 15:47:36 2002 +0200 Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 19 Apr 2002 15:47:41 +0200 Message-ID: From: "Georgios Karagiannis (ELN)" To: "'brunner@ccrle.nec.de'" Cc: "'nsis@ietf.org'" Date: Fri, 19 Apr 2002 15:48:57 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [NSIS] about the text related to scalability! Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi Marcus Some time ago I have sent a comment on the text related to scalability. It relates to the Open issue (11) that has been proposed by Anders Bergsten to replace the scalability requirements. In that e-mail I proposed to replace the sentence: " to constrain the load (CPU load, memory space, signaling bandwidth consumption and signaling intensity) on devices .." into: " to constrain the load (CPU load, memory space, signaling bandwidth consumption and signaling intensity) and the number of reservation states on devices .." This is not shown in the current version of the NSIS WG draft. In my opinion the number of reservation states impacts much more severely the network performance compared to the impact of the load (on a node) on network performance! Best Regards, Georgios -----Original Message----- From: Georgios Karagiannis (ELN) Sent: dinsdag 9 april 2002 12:59 To: 'Anders.P.Bergsten@telia.se'; nsis@ietf.org Cc: brunner@ccrle.nec.de Subject: RE: [NSIS] proposal to add requirement text Hi Anders Sorry for the delay on sending this reply. Regarding your proposal on scalability. Actually I agree, but I would very much appreciate if you could change the following sentence: " to constrain the load (CPU load, memory space, signaling bandwidth consumption and signaling intensity) on devices .." into: " to constrain the load (CPU load, memory space, signaling bandwidth consumption and signaling intensity) and the number of reservation states on devices .." Best Regards, Georgios -----Original Message----- From: Anders.P.Bergsten@telia.se [mailto:Anders.P.Bergsten@telia.se] Sent: donderdag 21 maart 2002 23:52 To: nsis@ietf.org Cc: brunner@ccrle.nec.de Subject: [NSIS] proposal to add requirement text All, off line discussions revealed that the scalability sections (5.6) could be slightly updated. I suggest wording along these lines: The nsis architecture should give the ability to constrain the load (CPU load, memory space, signaling bandwidth consumption and signaling intensity) on devices where it is needed. This can be achieved by many different methods, for example message aggregation, by ignoring signaling message, header compression or minimizing functionality. The architecture may choose any of these methods as long as the requirement is met. (the reasoning behind the words are the following, if I have the ability to control the load the protocol(s) generate in a singel device, the protocol will "scale". And the words does not mandate any particular solution) A related requirement that was discussed was transport quality for the signaling protocol where I propose the following text. The nsis architecture should allow the network operator to assign the nsis protocol messages a certain transport quality. As signaling opens up for possible denial-of-service attacks, this requirement gives the network operator a mean, but also the obligation, to trade-off between signaling latency and the impact (from the signaling messages) on devices within his/her network. From protocol design this requirement states that the protocol messages should be detectable, at least where the control and assignment of the messages priority is done. Anders _______________________________________________ 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 daemon@ns.ietf.org Fri Apr 19 17:00:19 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02980 for ; Fri, 19 Apr 2002 17:00:18 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA10032 for nsis-archive@odin.ietf.org; Fri, 19 Apr 2002 17:00:21 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA09406; Fri, 19 Apr 2002 16:55:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA09377 for ; Fri, 19 Apr 2002 16:55:06 -0400 (EDT) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02288 for ; Fri, 19 Apr 2002 16:55:02 -0400 (EDT) Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate.mot.com (motgate 2.1) with ESMTP id NAA19413 for ; Fri, 19 Apr 2002 13:55:04 -0700 (MST)] Received: [from il75exm04.cig.mot.com ([136.182.110.113]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id NAA27269 for ; Fri, 19 Apr 2002 13:42:32 -0700 (MST)] Received: by IL75EXM04 with Internet Mail Service (5.5.2654.52) id ; Fri, 19 Apr 2002 15:54:17 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B046500BB@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'Freytsis, Ilya'" , Nakhjiri Madjid-MNAKHJI1 , schneider@tri.sbc.com Cc: nsis@ietf.org Date: Fri, 19 Apr 2002 15:54:17 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain; charset="windows-1251" Subject: [NSIS] refreshes Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Ilya, Thanks for the respone and sorry for the delay. Are refreshes required then? I must have missed it in the requirements? BR, Madjid -----Original Message----- From: Freytsis, Ilya [mailto:ifreytsis@Cetacean.com] Sent: Thursday, April 11, 2002 11:14 PM To: 'Nakhjiri Madjid-MNAKHJI1'; Freytsis, Ilya; schneider@tri.sbc.com Cc: nsis@ietf.org Subject: RE: pre-emption (was RE: [NSIS] proposals related to NSIS WGdraf t) Madjid, Reservation lifetime (applicable for soft reservations as well as hard reservations) is not meant to replace the refreshes that are needed for the soft state based reservations. Ilya -----Original Message----- From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] Sent: Thursday, April 11, 2002 5:27 PM To: 'Freytsis, Ilya'; schneider@tri.sbc.com Cc: nsis@ietf.org Subject: RE: pre-emption (was RE: [NSIS] proposals related to NSIS WGdraf t) Hi, I have not been following this discussion closely, so sorry if this has been brought up. My question is, if NSIS does not intend to use refreshes and just add reservation lifetime as opaque info to the NSIS messages, then inherent reliability mechanism that RSVP was getting from refreshes is gone?? Did I miss something? Regards, Madjid -----Original Message----- From: Freytsis, Ilya [mailto:ifreytsis@cetacean.com] Sent: Thursday, April 11, 2002 8:55 AM To: schneider@tri.sbc.com Cc: nsis@ietf.org Subject: RE: pre-emption (was RE: [NSIS] proposals related to NSIS WGdraf t) Marco, I fully support your position. Honestly, I was a little bit surprised by the intensity of this discussion and how much time it has taken. I still do not understand what exactly James (Polk) wanted to see included in NSIS requirements. Ilya Related to the issue of preemption, a group of us discussed the issue of reservation lifetime while in Minneapolis. Our conclusion was that this could be done transparently by building it into the service description which is carried by, but not visible to, NSIS. Reservation lifetime would only be seen in a service specific field which is part of the service description and transparent to NSIS. It seems to me that while pre-emption is a different concern than reservation lifetime, it still can be supported in the same way. The only requirement that seems necessary is that NSIS must support the ability of a QOS controller to release an existing connection. Specific cause codes would be specific to the service and are out of scope and transparent to NSIS. Comments? Marco _______________________________________________ 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 daemon@ns.ietf.org Sat Apr 20 20:50:47 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08994 for ; Sat, 20 Apr 2002 20:50:46 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA22576 for nsis-archive@odin.ietf.org; Sat, 20 Apr 2002 20:50:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA22388; Sat, 20 Apr 2002 20:37:47 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA22357 for ; Sat, 20 Apr 2002 20:37:45 -0400 (EDT) From: owner-nsis@ns.ietf.org Received: from brandon.hosting.tlrg.com (relay-ext.hosting.tlrg.com [167.68.16.11] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08941 for ; Sat, 20 Apr 2002 20:37:41 -0400 (EDT) Received: from accountantwebs.com ([167.68.235.4]) by brandon.hosting.tlrg.com (8.12.2/8.12.2) with SMTP id g3L0bCUM028844 for ; Sat, 20 Apr 2002 19:37:13 -0500 Received: from smtp0732.mail.yahoo.com ([167.68.224.13]) by accountantwebs.com ; Sat, 20 Apr 2002 19:32:03 -0500 Date: Sun, 21 Apr 2002 08:37:24 +0800 X-Priority: 3 To: nsis@ietf.org CC: nsis@key-net.net, nsis@mindspring.com, nsis@the-saudi.net, nsis@well.com Mime-Version: 1.0 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit X-Rcpt-To: Message-ID: <101934912401@accountantwebs.com> Content-Transfer-Encoding: 7bit Subject: [NSIS] Ultimate HGH: Make you look and feel 20 YEARS YOUNGER! Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit


Hello, nsis@ietf.org,

As seen on NBC, CBS, CNN, and even Oprah! The health discovery that actually reverses aging while burning fat, without dieting or exercise! This proven discovery has even been reported on by the New England Journal of Medicine. Forget aging and dieting forever! And it's Guaranteed!


Click here

Would you like to lose weight while you sleep!
No dieting!
No hunger pains!
No Cravings!
No strenuous exercise!
Change your life forever!

1.Body Fat Loss 82% improvement.
2.Wrinkle Reduction 61% improvement.
3.Energy Level 84% improvement.
4.Muscle Strength 88% improvement.
5.Sexual Potency 75% improvement.
6.Emotional Stability 67% improvement.
7.Memory 62% improvement.

100% GUARANTEED!

 

You are receiving this email as a subscriber
to the Opt-In America Mailing List.
To remove yourself from all related maillists,
just Click Here

_______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon Apr 22 03:26:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18302 for ; Mon, 22 Apr 2002 03:26:07 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA23862 for nsis-archive@odin.ietf.org; Mon, 22 Apr 2002 03:26:08 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA22932; Mon, 22 Apr 2002 03:12:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA22728 for ; Mon, 22 Apr 2002 03:09:24 -0400 (EDT) Received: from nero.informatik.uni-wuerzburg.de (root@wi3x05.informatik.uni-wuerzburg.de [132.187.106.5]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18070; Mon, 22 Apr 2002 03:08:45 -0400 (EDT) Received: from PROMETHEUS (prometheus.informatik.uni-wuerzburg.de [132.187.106.139]) by nero.informatik.uni-wuerzburg.de (8.11.3/8.11.3/SuSE Linux 8.11.1-0.5) with SMTP id g3M786P07465; Mon, 22 Apr 2002 09:08:06 +0200 Message-ID: <003a01c1e9cd$66769720$8b6abb84@PROMETHEUS> From: "Kurt Tutschku" To: "mpls \(ietf\)" , "sigtran \(ietf\)" , "end2end \(irtf\)" , "ITC list" , "nsis \(ietf\)" , "cost 279" , "ppvpn \(ietf\)" , "ITG Fachtagung Messung, Modellierung und Bewertung" , "ITG 524" , "ITG 523" , "ITG 521" , "cost 257" , "Onno Boxma" , "Joachim Charzinski" , "Jon Crowcroft" , "Christophe Diot" , "Serge Fdida" , "Anja Feldmann" , "Markus Fiedler" , "Richard Harris" , "Gunnar Karlsson" , "Konosuke Kawashima" , "Edward Knightly" , "Udo Krieger" , =?iso-8859-1?Q?Paul_K=FChn?= , "Guy Latouche" , "Ralf Lehnert" , "Debasis Mitra" , "Sandor Molnar" , "Ilkka Norros" , "Vern Paxson" , "Michal Pioro" , "Jennifer Rexford" , "James Roberts" , "Hideaki Takagi" , "Don Townsley" , "Jorma Virtamo" , "Patricia Wirth" , "ipo \(ietf\)" , "tewg \(ietf\)" , "ippm \(ietf\)" , "mobileip \(ietf\)" , "manet \(ietf\)" , "nmrg \(irtf\)" , "rr \(irtf\)" , "ccamp \(ietf\)" , "ipv6 \(ietf\)" , "disman \(ietf\)" , =?iso-8859-1?Q?Paul_Schl=FCter?= , "Notker Gerlich" , "Hans Schwefel" , "Thomas Reim" , "Stefan Schneeberger" , "Michael Schopp" , "Franz Hartleb" , "Klaus Dolzer" , "Bart Sanders" , =?iso-8859-1?Q?Michael_S=F6llner?= , "Wolfgang Wagner" , "Walter Leonhardt" , "Norbert Rauh" , =?iso-8859-1?Q?Silvia_Sch=E4ffler?= , "Wolfgang Stegmann" , "Andreas Lamsa" , "Karl Heinz Allgeyer" , "Lothar Lux" , =?iso-8859-1?Q?Bernd_Schr=F6der?= , "Albert Weller" , =?iso-8859-1?Q?J=FCrgen_Tenckhoff?= , "Norbert Schultze" , =?iso-8859-1?Q?Norbert_Schl=FCter?= , "Laslo Slawitschka" , "Gabriel Zgunea" , "Bernhard Liesenfeld" , =?iso-8859-1?Q?J=FCrgen_Beyer?= , "Zhongrong Liu" , "Bernd Pfeiffer" , "Hans Barth" , "Wolf Mende" , "Wolfgang Urmoneit" , "Dieter Marger" , "Charles E. Perkins" , "Ake Arvidsson" , =?iso-8859-1?Q?Angelika_M=FCller?= , "Armin Heindl" , "Bo Friis Nielsen" , "Holger Hermanns" , "Jacques Resing" , "Jose Brazio" , "Stephen Hanly" , "Matthew Roughan" , "Reinhard German" , "Rudolf Mathar" , "Ulrich Herzog" , "Dieter Baum" , "Lothar Breuer" , "Marie-Ange Remiche" , "Markus Siegle" , "Nikhil Jain" , "Peter Taylor" , "Sem Borst" , "Ute Kohlhaas" Date: Mon, 22 Apr 2002 09:14:29 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0037_01C1E9DE.1B8754F0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: [NSIS] ITC Specialist seminar: full paper submission deadline extended Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0037_01C1E9DE.1B8754F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear colleagues, due to multiple requests, the full paper submission deadline was = extended to Friday, April 26th. Late papers can still be submitted at: http://vitus.informatik.uni-wuerzburg.de:8080/submit.html. For more information about the 15th ITC Specialist Seminar, please visit = our homepage at http://www.itcspecialistseminar.com Best Regards Phuoc Tran-Gia (Seminar Co-Chair) Jim Roberts (Seminar Co-Chair) Kurt Tutschku (Organizing Committee Chair) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D Phuoc Tran-Gia Professor, Chair, Distributed Systems Computer Science, University of Wuerzburg Am Hubland, D-97074 Wuerzburg, Germany Tel.: +49-931-8886630 , Fax.: +49-931-8886632 mailto:trangia@informatik.uni-wuerzburg.de www: http://www-info3.informatik.uni-wuerzburg.de Phuoc Tran-Gia CEO, infosim Networking Solutions AG Sedanstr. 27, D-97082 Wuerzburg, Germany mailto:trangia@infosim.net www: http://www.infosim.net ------=_NextPart_000_0037_01C1E9DE.1B8754F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dear colleagues,
 
due to multiple requests, the full = paper=20 submission deadline was extended to Friday, April 26th. Late papers can = still be=20 submitted at:
 
http://vitus.informatik.uni-wuerzburg.de:8080/submit.html= .
 
 
For more information about the 15th = ITC=20 Specialist Seminar, please visit our homepage at
 
 
 
Best Regards
Phuoc Tran-Gia = (Seminar=20 Co-Chair)
Jim Roberts    (Seminar Co-Chair)
Kurt=20 Tutschku  (Organizing Committee=20 Chair)


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D
Phuoc=20 Tran-Gia
Professor, Chair, Distributed Systems
Computer Science,=20 University of Wuerzburg
Am Hubland, D-97074 Wuerzburg, = Germany
Tel.:=20 +49-931-8886630 , Fax.: +49-931-8886632
mailto:trangia@informatik.uni-wuerzburg.de
www: http://www-info3.informatik.uni-wuerzburg.de
Phuoc Tran-Gia
CEO, infosim Networking = Solutions=20 AG
Sedanstr. 27, D-97082 Wuerzburg, Germany
mailto:trangia@infosim.net
www:=20 http://www.infosim.net
------=_NextPart_000_0037_01C1E9DE.1B8754F0-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon Apr 22 04:15:06 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18902 for ; Mon, 22 Apr 2002 04:15:06 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA26359 for nsis-archive@odin.ietf.org; Mon, 22 Apr 2002 04:15:08 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA26019; Mon, 22 Apr 2002 04:03:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA25988 for ; Mon, 22 Apr 2002 04:02:59 -0400 (EDT) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18747 for ; Mon, 22 Apr 2002 04:02:55 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g3M81wu29483 for ; Mon, 22 Apr 2002 11:01:58 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 22 Apr 2002 11:02:54 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Mon, 22 Apr 2002 11:02:54 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1251" Subject: RE: [NSIS] refreshes Date: Mon, 22 Apr 2002 11:02:53 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64FA3@esebe004.NOE.Nokia.com> Thread-Topic: [NSIS] refreshes Thread-Index: AcHn5JHtCFQBp2LaRSynw1c6ZC6oLAB73QhA To: Cc: X-OriginalArrivalTime: 22 Apr 2002 08:02:54.0281 (UTC) FILETIME=[1B432B90:01C1E9D4] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id EAA25989 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Madjid, > Thanks for the respone and sorry for the delay. Are refreshes > required then? I must have missed it in the requirements? Refreshes, in my opinion, are much more of a solution, than a requirement. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon Apr 22 04:36:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19164 for ; Mon, 22 Apr 2002 04:36:46 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA28227 for nsis-archive@odin.ietf.org; Mon, 22 Apr 2002 04:36:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA26983; Mon, 22 Apr 2002 04:27:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA26951 for ; Mon, 22 Apr 2002 04:27:01 -0400 (EDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19062 for ; Mon, 22 Apr 2002 04:26:53 -0400 (EDT) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g3M8Qt0E026390 for ; Mon, 22 Apr 2002 10:26:55 +0200 (MEST) Received: FROM esealnt747.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Mon Apr 22 10:23:53 2002 +0200 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id <2281YQGY>; Mon, 22 Apr 2002 10:26:39 +0200 Message-ID: From: "Georgios Karagiannis (ELN)" To: "'Marcus Brunner'" Cc: nsis@ietf.org Date: Mon, 22 Apr 2002 10:25:00 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [NSIS] comments Issue (1) included in draft-ietf-nsis-req-01.txt Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi Marcus Please receive my comments on Issue (1) included in the NSIS WG draft: draft-ietf-nsis-req-01.txt Comment on Issue (1): ------------ > 1) (OPEN) add Scenarios > Do we need to add, remove, or change the scenarios? > - added scenario on QoS signalling between PSTN gateways and > backbone routers > - added: Application request end-to-end QoS path from the network > We can what ever scenario we want. The more the better to understand > the issues. Nevertheless, we have to take care that we are future > prove as well. [GK] Agree with these additions. I would very much appreciate if you could [GK] add also the following scenario (Section 3.4 of [GK] draft-partain-nsis-requirements-00.txt): "QoS for Virtual Private Networks There are two types of L3 VPNs, distinguished by where the endpoints of the tunnels exist. The endpoints of the tunnels may either be on the customer (CPE), or the provider equipment or provider edge (PE). Virtual Private networks are also likely to request bandwidth for Assured Forwarding style services in addition to the Expedited Forwarding services the PSTN GW are likely to use." ------------ Best regards, Georgios _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon Apr 22 04:37:52 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19194 for ; Mon, 22 Apr 2002 04:37:52 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA28379 for nsis-archive@odin.ietf.org; Mon, 22 Apr 2002 04:37:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA27164; Mon, 22 Apr 2002 04:29:04 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA27128 for ; Mon, 22 Apr 2002 04:29:02 -0400 (EDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19097 for ; Mon, 22 Apr 2002 04:28:58 -0400 (EDT) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g3M8T00E027924 for ; Mon, 22 Apr 2002 10:29:00 +0200 (MEST) Received: FROM esealnt747.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Mon Apr 22 10:26:12 2002 +0200 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id <2281YQHV>; Mon, 22 Apr 2002 10:28:58 +0200 Message-ID: From: "Georgios Karagiannis (ELN)" To: "'Marcus Brunner'" Cc: "'nsis@ietf.org'" Date: Mon, 22 Apr 2002 10:27:20 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [NSIS] comments Issue (2) included in draft-ietf-nsis-req-01.txt Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi Marcus Please receive my comments on Issue (2) included in the NSIS WG draft: draft-ietf-nsis-req-01.txt Comment on Issue (2): > 2) (OPEN) Sender/receiver initiation > What is the requirement concerning data sender or data receiver or > both to initiate a QoS request. > - does it matter who pays? > - terminology text added > open issue, what is a potential req (currently we say "both must be > possible") [GK] both should be possible but it should be optimized for sender initiated; -------------- Best regards, Georgios _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon Apr 22 04:44:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19310 for ; Mon, 22 Apr 2002 04:44:54 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA28704 for nsis-archive@odin.ietf.org; Mon, 22 Apr 2002 04:44:57 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA27901; Mon, 22 Apr 2002 04:32:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA27869 for ; Mon, 22 Apr 2002 04:32:35 -0400 (EDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19132 for ; Mon, 22 Apr 2002 04:32:31 -0400 (EDT) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g3M8WXs7008289 for ; Mon, 22 Apr 2002 10:32:33 +0200 (MEST) Received: FROM esealnt747.al.sw.ericsson.se BY esealnt461 ; Mon Apr 22 10:32:29 2002 +0200 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id <2281YQ29>; Mon, 22 Apr 2002 10:32:29 +0200 Message-ID: From: "Georgios Karagiannis (ELN)" To: "'Marcus Brunner'" Cc: "'nsis@ietf.org'" Date: Mon, 22 Apr 2002 10:30:50 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [NSIS] comments Issue (8) included in draft-ietf-nsis-req-01 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi Marcus Please receive my comments on Issue (8) included in the NSIS WG draft: draft-ietf-nsis-req-01.txt Comment on Issue (8): > 8) (OPEN) bi-directional data path setup with one QoS request > I have not seen consensus on whether to require bi-directional data > path setup with QoS. > - How can we actually perform bi-directional reservations when the > forward and reverse paths are not reciprocal, with respect to > routing topology and routing policy of network domains between > sender and receiver? > - The need to ensure that the return path is the same as the > forwarding path is one of the problems with RSVP, particularly in a > mobile environment. [GK] The bi-directional data path setup does not need to use the same [GK] return path as the forwarding path. The only requirement to achieve [GK] a bi-directional reservation is that the sender for the forwarding path [GK] is also the receiver for the return path and that the receiver for the [GK] forwarding path is also the sender for the return path. [GK] Therefore, I think that the bi-directional option should not be mandatory [GK] but at least optional; -------------- Best regards, Georgios _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon Apr 22 04:46:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19345 for ; Mon, 22 Apr 2002 04:46:46 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA28939 for nsis-archive@odin.ietf.org; Mon, 22 Apr 2002 04:46:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA28095; Mon, 22 Apr 2002 04:34:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA28064 for ; Mon, 22 Apr 2002 04:34:55 -0400 (EDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19148 for ; Mon, 22 Apr 2002 04:34:51 -0400 (EDT) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g3M8Yos7009867 for ; Mon, 22 Apr 2002 10:34:50 +0200 (MEST) Received: FROM esealnt747.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Mon Apr 22 10:31:56 2002 +0200 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id <2281YQJ0>; Mon, 22 Apr 2002 10:34:42 +0200 Message-ID: From: "Georgios Karagiannis (ELN)" To: "'Marcus Brunner'" Cc: "'nsis@ietf.org'" Date: Mon, 22 Apr 2002 10:33:03 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [NSIS] comments Issue (12) included in draft-ietf-nsis-req-01 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi Marcus Please receive my comments on Issue (12) included in the NSIS WG draft: draft-ietf-nsis-req-01.txt Comment on Issue (12): > 12) (CLOSED) text replacing scalability reqs > "The nsis architecture should give the ability to constrain the load > (CPU load, memory space, signaling bandwidth consumption and > signaling intensity) on devices where it is needed. This can be > achieved by many different methods, for example message aggregation, > by ignoring signaling message, header compression or minimizing > functionality. The architecture may choose any of these methods as > long as the requirement is met." > Editor: added the above text, but did not remove scalability reqs [GK] If the text will have to replace the scalability requirements, [GK] then in my opinion it should be slightly modified by adding the words [GK] "and the number of reservation states". The text becomes then: "The nsis architecture should give the ability to constrain the load (CPU load, memory space, signaling bandwidth consumption and signaling intensity) and the number of reservation states on devices where it is needed. This can be achieved by many different methods, for example message aggregation, by ignoring signaling message, header compression or minimizing functionality. The architecture may choose any of these methods as long as the requirement is met." -------------- Best regards, Georgios _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon Apr 22 04:49:39 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19428 for ; Mon, 22 Apr 2002 04:49:39 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA29117 for nsis-archive@odin.ietf.org; Mon, 22 Apr 2002 04:49:42 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA28475; Mon, 22 Apr 2002 04:40:23 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA28445 for ; Mon, 22 Apr 2002 04:40:20 -0400 (EDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19237 for ; Mon, 22 Apr 2002 04:40:17 -0400 (EDT) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g3M8eJs7012743 for ; Mon, 22 Apr 2002 10:40:19 +0200 (MEST) Received: FROM esealnt746.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Mon Apr 22 10:37:32 2002 +0200 Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 22 Apr 2002 10:40:03 +0200 Message-ID: From: "Georgios Karagiannis (ELN)" To: "'Marcus Brunner'" Cc: "'nsis@ietf.org'" Date: Mon, 22 Apr 2002 10:38:38 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [NSIS] comments Issue (34) included in draft-ietf-nsis-req-01 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi Marcus Please receive my comments on Issue (34) included in the NSIS WG draft: draft-ietf-nsis-req-01.txt Comment on Issue (34): > 34) (OPEN)difference between "UMTS access scenario" "cellular > network scenario", and "Wired part of wireless network" (Section > 8.2, 8.3, and 8.4) [GK] The only common point between the three scenarios is that they are [GK] related to cellular networks. Section 8.4 is introducing the scenario used [GK] in the radio access network of cellular networks. Sections 8.2 and Section [GK] 8.3 are discussing other parts of the cellular network. [GK] Therefore, I propose that all scenarios should be kept! Best regards, Georgios _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon Apr 22 04:49:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19452 for ; Mon, 22 Apr 2002 04:49:55 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA29159 for nsis-archive@odin.ietf.org; Mon, 22 Apr 2002 04:49:58 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA28309; Mon, 22 Apr 2002 04:37:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA28274 for ; Mon, 22 Apr 2002 04:37:40 -0400 (EDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19185 for ; Mon, 22 Apr 2002 04:37:36 -0400 (EDT) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g3M8bas7011192 for ; Mon, 22 Apr 2002 10:37:36 +0200 (MEST) Received: FROM esealnt746.al.sw.ericsson.se BY esealnt461 ; Mon Apr 22 10:36:54 2002 +0200 Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 22 Apr 2002 10:36:39 +0200 Message-ID: From: "Georgios Karagiannis (ELN)" To: "'Marcus Brunner'" Cc: "'nsis@ietf.org'" Date: Mon, 22 Apr 2002 10:35:13 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [NSIS] comments Issue (14) included in draft-ietf-nsis-req-01 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi Marcus Please receive my comments on Issue (14) included in the NSIS WG draft: draft-ietf-nsis-req-01.txt Comment on Issue (14): > 14) (OPEN, dependend on resolution of bi-directional) proposal to > add "support grouping of microflows (possibly only for feedback)" > "As a consequence of the optimization for the interactive multimedia > services, the signaling should allow one unique request for several > micro flows having the same origination and destination IP > addresses. This is usually the case for multimedia SIP calls where > the voice and video micro flows follow the same path. This grouping > of requests allows optimization of the QoS processing. Note that > this may be detrimental for the call setup time. The use of grouping > for microflows may be restricted to teardown and/or notification > messages when call setup time is a concern." > open issue: first resolve the bi-directional issue which is somewhat > related, because it seams to be an optimization as well [GK] I think that this requirement is useful in some scenarios. [GK] I would not restrict it to teardown and/or notification, it might be [GK] useful also for the procedure that refreshes reservation states. -------------- Best regards, Georgios _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon Apr 22 04:50:05 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19468 for ; Mon, 22 Apr 2002 04:50:05 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA29173 for nsis-archive@odin.ietf.org; Mon, 22 Apr 2002 04:50:08 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA28566; Mon, 22 Apr 2002 04:41:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA28529 for ; Mon, 22 Apr 2002 04:41:04 -0400 (EDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19270 for ; Mon, 22 Apr 2002 04:41:00 -0400 (EDT) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g3M8f2s7013025 for ; Mon, 22 Apr 2002 10:41:02 +0200 (MEST) Received: FROM esealnt747.al.sw.ericsson.se BY esealnt461 ; Mon Apr 22 10:38:41 2002 +0200 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id <2281YQLY>; Mon, 22 Apr 2002 10:38:41 +0200 Message-ID: From: "Georgios Karagiannis (ELN)" To: "'Marcus Brunner'" Cc: "'nsis@ietf.org'" Date: Mon, 22 Apr 2002 10:37:03 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [NSIS] comments Issue (33) included in draft-ietf-nsis-req-01 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi Marcus Please receive my comments on Issue (33) included in the NSIS WG draft: draft-ietf-nsis-req-01.txt Comment on Issue (33): > 33) (OPEN) add req " highest possible network utilization" > "There are networking environments that require high network > utilization for various reasons, and the signaling protocol should > to its best ability support high resource utilization while > maintaining appropriate QoS. > In networks where resources are very expensive (as is the case for > many wireless networks), efficient network utilization is of > critical financial importance. On the other hand there are other > parts of the network where high utilization is not required. > " [GK] agree to be added! Best regards, Georgios _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon Apr 22 04:56:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19531 for ; Mon, 22 Apr 2002 04:56:07 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA29485 for nsis-archive@odin.ietf.org; Mon, 22 Apr 2002 04:56:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA28660; Mon, 22 Apr 2002 04:44:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA28629 for ; Mon, 22 Apr 2002 04:44:11 -0400 (EDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19298 for ; Mon, 22 Apr 2002 04:44:07 -0400 (EDT) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g3M8i90E008256 for ; Mon, 22 Apr 2002 10:44:09 +0200 (MEST) Received: FROM esealnt746.al.sw.ericsson.se BY esealnt461 ; Mon Apr 22 10:42:27 2002 +0200 Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 22 Apr 2002 10:42:12 +0200 Message-ID: From: "Georgios Karagiannis (ELN)" To: "'Marcus Brunner'" Cc: "'nsis@ietf.org'" Date: Mon, 22 Apr 2002 10:40:47 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [NSIS] comments Issue (35) included in draft-ietf-nsis-req-01 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi Marcus Please receive my comments on Issue (35) included in the NSIS WG draft: draft-ietf-nsis-req-01.txt Comment on Issue (35): > 35) (OPEN) difference between the two PSTN gateway scenarios > (Section 8.8 and 8.9) > currently both are included > what are the essential issues? [GK] From what I understood Section 8.9 is discussing a specific PSTN gateway [GK] scenario that uses Media Gateway Controllers. Section 8.8 does not do that. [GK] Therefore, I propose that both scenarios should be kept! Best regards, Georgios _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon Apr 22 04:57:10 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19551 for ; Mon, 22 Apr 2002 04:57:10 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA29522 for nsis-archive@odin.ietf.org; Mon, 22 Apr 2002 04:57:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA28818; Mon, 22 Apr 2002 04:45:12 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA28767 for ; Mon, 22 Apr 2002 04:45:09 -0400 (EDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19328 for ; Mon, 22 Apr 2002 04:45:04 -0400 (EDT) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g3M8ig0E008906 for ; Mon, 22 Apr 2002 10:44:42 +0200 (MEST) Received: FROM esealnt746.al.sw.ericsson.se BY esealnt461 ; Mon Apr 22 10:43:49 2002 +0200 Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 22 Apr 2002 10:43:34 +0200 Message-ID: From: "Georgios Karagiannis (ELN)" To: "'Marcus Brunner'" Cc: "'nsis@ietf.org'" Date: Mon, 22 Apr 2002 10:43:49 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [NSIS] comments Issue (51) included in draft-ietf-nsis-req-01 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi Marcus Please receive my comments on Issue (51) included in the NSIS WG draft: draft-ietf-nsis-req-01.txt Comment on Issue (51): -------------- > 51) (OPEN) remove 5.1.6 Avoid duplication of [sub]domain signaling > functions > we might to use the text somewhere else [GK] Agree, please remove Section 5.1.6; Best regards, Georgios _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon Apr 22 04:58:06 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19576 for ; Mon, 22 Apr 2002 04:58:06 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA29577 for nsis-archive@odin.ietf.org; Mon, 22 Apr 2002 04:58:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA28909; Mon, 22 Apr 2002 04:46:04 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA28874 for ; Mon, 22 Apr 2002 04:46:01 -0400 (EDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19338 for ; Mon, 22 Apr 2002 04:45:57 -0400 (EDT) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g3M8jxs7016154 for ; Mon, 22 Apr 2002 10:45:59 +0200 (MEST) Received: FROM esealnt746.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Mon Apr 22 10:42:51 2002 +0200 Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 22 Apr 2002 10:45:22 +0200 Message-ID: From: "Georgios Karagiannis (ELN)" To: "'Marcus Brunner'" Cc: "'nsis@ietf.org'" Date: Mon, 22 Apr 2002 10:45:37 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [NSIS] comments Issue (53) included in draft-ietf-nsis-req-01 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi Marcus Please receive my comments on Issue (53) included in the NSIS WG draft: draft-ietf-nsis-req-01.txt Comment on Issue (53): > 53) (OPEN) add req 5.1.16. of draft-partain-...-00 Error handling > and redundancy considerations > Border nodes should be able to notify the users if there is an error > inside the network. There are two types of network errors: > - Recoverable errors: this type error can be locally repaired > by the network nodes. The network nodes do not have to > notify the users of the error immediately. > - Unrecoverable errors: the network nodes cannot handle this > type of error, and have to notify the users as soon as > possible. > Comments: > 1) notification of user in case of unrecoverable errors (has been > done by notification req, or will be done by asynch notification > 2) recoverable error (might need to be added) req 5.3.4 is going > into this direction [GK] I propose that both types of errors (recoverable, unrecoverable) [GK] should be explained and included in Section 5.3.4. > 3) what does this mean for different parts of the network > in different parts of the network) [GK] Any QoS Controller should be able to notify these errors to the QoS [GK] Initiator. > 4) hop-by-hop? OR right to the end? [GK] It is not hop by hop, but QoS controller to QoS initiator; Best regards, Georgios _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon Apr 22 04:59:52 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19611 for ; Mon, 22 Apr 2002 04:59:52 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA29731 for nsis-archive@odin.ietf.org; Mon, 22 Apr 2002 04:59:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA29026; Mon, 22 Apr 2002 04:47:53 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA28997 for ; Mon, 22 Apr 2002 04:47:51 -0400 (EDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19381 for ; Mon, 22 Apr 2002 04:47:47 -0400 (EDT) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g3M8ln0E011086 for ; Mon, 22 Apr 2002 10:47:49 +0200 (MEST) Received: FROM esealnt747.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Mon Apr 22 10:44:47 2002 +0200 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id <2281YQP9>; Mon, 22 Apr 2002 10:47:33 +0200 Message-ID: From: "Georgios Karagiannis (ELN)" To: "'Marcus Brunner'" Cc: "'nsis@ietf.org'" Date: Mon, 22 Apr 2002 10:47:33 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [NSIS] comments Issue (55) included in draft-ietf-nsis-req-01 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi Marcus Please receive my comments on Issue (55) included in the NSIS WG draft: draft-ietf-nsis-req-01.txt Comment on Issue (55): > 55) (OPEN) 5.2.2. Allow local QoS information exchange between two > border nodes > "The QoS signalling protocol must be able to exchange local QoS > information between edge nodes. Local QoS information might, for > example, be IP addresses, severe congestion notification, > notification of succesful or erroneous processing of QoS signalling > messages at one border node. > In some domains, the NSIS QoS signalling protocol MAY carry > identification of the ingress and egress edge between the ingress- > egress edges. However, the identification of edges should not be > visible to the end host and only applies within one QoS > administrative domain. > " > Comments: > - service mapping is more service-specific (layering,tunneling) > - the scenario to look at is a complicated service description -> in > part of the network you want to change the message to something more > easy, and at the other end go back to the more complicated part. > -QI being everywhere might be enough > -and we have already a requirement saying that intermediate node > MUST be able to add/remove domain-specific information to/from > signaling messages [GK] This requirement is related to the ability of exchanging local [GK]QoS information between QoS controllers located at the boundary of [GK] one single domain. This requirement could be combined with Section 5.5.2. [GK] Therefore I propose to add this requirement, with some changes: "The QoS signalling protocol must be able to exchange local QoS information between QoS controllers located at boundaries of one single domain. Local QoS information might, for example, be IP addresses, severe congestion notification, notification of successful or erroneous processing of QoS signalling messages at one border node. In some domains, the NSIS QoS signalling protocol MAY carry identification of the QoS controllers located at the boundaries of a domain. However, the identification of should not be visible to the end host (QoS initiator) and only applies within one QoS administrative domain." ----------------- Best regards, Georgios _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon Apr 22 05:02:35 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19670 for ; Mon, 22 Apr 2002 05:02:35 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA00345 for nsis-archive@odin.ietf.org; Mon, 22 Apr 2002 05:02:38 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA29218; Mon, 22 Apr 2002 04:50:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA29187 for ; Mon, 22 Apr 2002 04:50:34 -0400 (EDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19482 for ; Mon, 22 Apr 2002 04:50:30 -0400 (EDT) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g3M8oX0E013357 for ; Mon, 22 Apr 2002 10:50:33 +0200 (MEST) Received: FROM esealnt747.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Mon Apr 22 10:47:45 2002 +0200 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id <2281YQR2>; Mon, 22 Apr 2002 10:50:31 +0200 Message-ID: From: "Georgios Karagiannis (ELN)" To: "'Marcus Brunner'" Cc: "'nsis@ietf.org'" Date: Mon, 22 Apr 2002 10:50:31 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [NSIS] comments Issue (57) included in draft-ietf-nsis-req-01.txt Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi Marcus Please receive my comments on Issue (57) included in the NSIS WG draft: draft-ietf-nsis-req-01.txt Comment on Issue (57): > 57) (OPEN) potentially better title for text from issue 56) e.g. > (?minimal impact on core?) [GK] This requirement is related to the performance of the interior nodes, [GK] i.e., nodes located within a domain. we could change the title into: [GK] "Minimal impact on interior (core) nodes" Best regards, Georgios _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon Apr 22 05:12:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19802 for ; Mon, 22 Apr 2002 05:12:36 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA01018 for nsis-archive@odin.ietf.org; Mon, 22 Apr 2002 05:12:35 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA29688; Mon, 22 Apr 2002 04:59:32 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA29651 for ; Mon, 22 Apr 2002 04:59:29 -0400 (EDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19602 for ; Mon, 22 Apr 2002 04:59:24 -0400 (EDT) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g3M8xRs7024374 for ; Mon, 22 Apr 2002 10:59:27 +0200 (MEST) Received: FROM esealnt746.al.sw.ericsson.se BY esealnt461 ; Mon Apr 22 10:49:12 2002 +0200 Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 22 Apr 2002 10:48:57 +0200 Message-ID: From: "Georgios Karagiannis (ELN)" To: "'Marcus Brunner'" Cc: "'nsis@ietf.org'" Date: Mon, 22 Apr 2002 10:49:10 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [NSIS] comments Issue (56) included in draft-ietf-nsis-req-01 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi Marcus Please receive my comments on Issue (56) included in the NSIS WG draft: draft-ietf-nsis-req-01.txt Comment on Issue (56): Issue (56) > 56) (CLOSED) add req 5.3.1.3 of draft-partain-..-00 > -already added a req to the scalability section (issue ???), which > has been provided by Anders [GK] The proposal of Anders covers partially this requirement. [GK] I propose to enlarge it. ------------ Best regards, Georgios _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon Apr 22 05:14:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19838 for ; Mon, 22 Apr 2002 05:14:26 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA01124 for nsis-archive@odin.ietf.org; Mon, 22 Apr 2002 05:14:30 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA00303; Mon, 22 Apr 2002 05:02:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA00266 for ; Mon, 22 Apr 2002 05:02:23 -0400 (EDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19654 for ; Mon, 22 Apr 2002 05:02:19 -0400 (EDT) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g3M92Ls7026195 for ; Mon, 22 Apr 2002 11:02:21 +0200 (MEST) Received: FROM esealnt747.al.sw.ericsson.se BY esealnt461 ; Mon Apr 22 10:52:10 2002 +0200 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id <2281YQS2>; Mon, 22 Apr 2002 10:52:10 +0200 Message-ID: From: "Georgios Karagiannis (ELN)" To: "'Marcus Brunner'" Cc: "'nsis@ietf.org'" Date: Mon, 22 Apr 2002 10:52:11 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [NSIS] comments Issue (58) included in draft-ietf-nsis-req-01.txt Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi Marcus Please receive my comments on Issue (58) included in the NSIS WG draft: draft-ietf-nsis-req-01.txt Comment on Issue (58): > 58) (CLOSED) add req 5.3.2 from draft-partain-...-00 > - the fast establishment req is handled by the low setup latency > req, and the scalability in handover req > - added the text to the teminal mobility scenario [GK] Agree that the fast reservations is partially included in the [GK] Section 5.6.6. However, the word handover is missing from Section 5.6.6. [GK] Please add the word handover in the text: "time scale (e.g., handover in [GK] mobile environments), " Best regards, Georgios _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon Apr 22 05:20:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19899 for ; Mon, 22 Apr 2002 05:20:26 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA01313 for nsis-archive@odin.ietf.org; Mon, 22 Apr 2002 05:20:29 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA00478; Mon, 22 Apr 2002 05:03:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA00384 for ; Mon, 22 Apr 2002 05:03:48 -0400 (EDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19685 for ; Mon, 22 Apr 2002 05:03:43 -0400 (EDT) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g3M93k0E022941 for ; Mon, 22 Apr 2002 11:03:46 +0200 (MEST) Received: FROM esealnt747.al.sw.ericsson.se BY esealnt461 ; Mon Apr 22 10:53:43 2002 +0200 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id <2281YQS8>; Mon, 22 Apr 2002 10:53:43 +0200 Message-ID: From: "Georgios Karagiannis (ELN)" To: "'Marcus Brunner'" Cc: "'nsis@ietf.org'" Date: Mon, 22 Apr 2002 10:53:43 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [NSIS] comments Issue (59) included in draft-ietf-nsis-req-01.txt Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi Marcus Please receive my comments on Issue (59) included in the NSIS WG draft: draft-ietf-nsis-req-01.txt Comment on Issue (59): > 59) (OPEN) add req: ability to deal with severe congestion (req > 5.3.4 of draft-partain-..-00 > issues are: > - the use in highly utilized networks > - deos it belong to failure recovery (I would assume from a service > point of view this is failure > - hop by hop problem (issue from Jorge) [GK] I think that this requirement is somehow related to failure recovery, [GK] but is not the same. It occurs in a highly utilised network and [GK] if it is not solved very fast then the network performance will [GK] quickly collapse; [GK] I propose to include it as a separate QoS requirement; Best regards, Georgios _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon Apr 22 05:20:35 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19914 for ; Mon, 22 Apr 2002 05:20:35 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA01332 for nsis-archive@odin.ietf.org; Mon, 22 Apr 2002 05:20:38 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA00737; Mon, 22 Apr 2002 05:05:51 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA00687 for ; Mon, 22 Apr 2002 05:05:48 -0400 (EDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19754 for ; Mon, 22 Apr 2002 05:05:43 -0400 (EDT) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g3M95ks7028350 for ; Mon, 22 Apr 2002 11:05:46 +0200 (MEST) Received: FROM esealnt747.al.sw.ericsson.se BY esealnt461 ; Mon Apr 22 10:55:30 2002 +0200 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id <2281YQTP>; Mon, 22 Apr 2002 10:55:30 +0200 Message-ID: From: "Georgios Karagiannis (ELN)" To: "'Marcus Brunner'" Cc: "'nsis@ietf.org'" Date: Mon, 22 Apr 2002 10:55:30 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [NSIS] comments Issue (60) included in draft-ietf-nsis-req-01.txt Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi Marcus Please receive my comments on Issue (60) included in the NSIS WG draft: draft-ietf-nsis-req-01.txt Comment on Issue (60): ---------------- > 60) (OPEN) add req 5.4.3. from draft-partain-...-00 "Allow efficient > QoS re-establishment after handover" > "Handover is an essential function in wireless networks. After > handover, QoS may need to be completely or partially re-established > due to route changes. The re-establishment may be requested by the > mobile node itself or triggered by the access point that the mobile > node is attached to. In the first case, the QoS signalling should > allow efficient QoS re-establishment after handover. Re- > establishment of QoS after handover should be as quick as possible > so that the mobile node does not experience service interruption or > QoS degradation. The re-establishment should be localized, and not > require end-to-end signalling, if possible." > most likely it is already cover, please check again, whether there > is something missing [GK] Sorry, Marcus but I could not find this requirement in the 01 version [GK] of the NSIS WG draft. -------------- Best regards, Georgios _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Mon Apr 22 09:45:32 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25558 for ; Mon, 22 Apr 2002 09:45:27 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA15155 for nsis-archive@odin.ietf.org; Mon, 22 Apr 2002 09:45:30 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA14387; Mon, 22 Apr 2002 09:32:47 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA14353 for ; Mon, 22 Apr 2002 09:32:44 -0400 (EDT) Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25050 for ; Mon, 22 Apr 2002 09:32:40 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g3MDXmJ12935 for ; Mon, 22 Apr 2002 16:33:48 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 22 Apr 2002 16:32:40 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Mon, 22 Apr 2002 16:32:40 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] comments Issue (1) included in draft-ietf-nsis-req-01.txt Date: Mon, 22 Apr 2002 16:32:39 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64FB5@esebe004.NOE.Nokia.com> Thread-Topic: [NSIS] comments Issue (1) included in draft-ietf-nsis-req-01.txt Thread-Index: AcHp14liAvMQtwmjS0KDM0LuKzznRAAKnhzA To: , Cc: X-OriginalArrivalTime: 22 Apr 2002 13:32:40.0800 (UTC) FILETIME=[2CF25E00:01C1EA02] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id JAA14354 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Georgios, > > 1) (OPEN) add Scenarios > > Do we need to add, remove, or change the scenarios? > > - added scenario on QoS signalling between PSTN gateways and > > backbone routers > > - added: Application request end-to-end QoS path from the network > > We can what ever scenario we want. The more the better to > understand > > the issues. Nevertheless, we have to take care that we are future > > prove as well. > > [GK] Agree with these additions. I would very much appreciate > if you could > [GK] add also the following scenario (Section 3.4 of > [GK] draft-partain-nsis-requirements-00.txt): > > "QoS for Virtual Private Networks > > There are two types of L3 VPNs, distinguished by where the endpoints > of the tunnels exist. The endpoints of the tunnels may either be on > the customer (CPE), or the provider equipment or provider edge (PE). > > Virtual Private networks are also likely to request bandwidth for > Assured Forwarding style services in addition to the Expedited > Forwarding services the PSTN GW are likely to use." I'm not so sure this is within out charter. I think we need more justification before adding this to the draft. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Mon Apr 22 09:46:43 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25612 for ; Mon, 22 Apr 2002 09:46:43 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA15219 for nsis-archive@odin.ietf.org; Mon, 22 Apr 2002 09:46:46 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA14604; Mon, 22 Apr 2002 09:34:36 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA14561 for ; Mon, 22 Apr 2002 09:34:30 -0400 (EDT) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25116 for ; Mon, 22 Apr 2002 09:34:12 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g3MDXAu15154 for ; Mon, 22 Apr 2002 16:33:15 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 22 Apr 2002 16:34:06 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Mon, 22 Apr 2002 16:34:06 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] comments Issue (2) included in draft-ietf-nsis-req-01.txt Date: Mon, 22 Apr 2002 16:34:06 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64FB6@esebe004.NOE.Nokia.com> Thread-Topic: [NSIS] comments Issue (2) included in draft-ietf-nsis-req-01.txt Thread-Index: AcHp196U8J96Z7IlRAyNuZbYCv9gVQAKlq/g To: , Cc: X-OriginalArrivalTime: 22 Apr 2002 13:34:06.0876 (UTC) FILETIME=[604085C0:01C1EA02] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id JAA14566 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Marcus & Georgios, > Please receive my comments on Issue (2) included in the > NSIS WG draft: draft-ietf-nsis-req-01.txt > > Comment on Issue (2): > > > > 2) (OPEN) Sender/receiver initiation > > What is the requirement concerning data sender or data receiver or > > both to initiate a QoS request. > > - does it matter who pays? > > - terminology text added > > open issue, what is a potential req (currently we say "both must be > > possible") > > [GK] both should be possible but it should be optimized for > sender initiated; I think that SHOULD is the right level of requirement for sender / reciever driven requests. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Mon Apr 22 09:48:29 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25660 for ; Mon, 22 Apr 2002 09:48:29 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA15303 for nsis-archive@odin.ietf.org; Mon, 22 Apr 2002 09:48:32 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA14686; Mon, 22 Apr 2002 09:35:19 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA14655 for ; Mon, 22 Apr 2002 09:35:15 -0400 (EDT) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25218 for ; Mon, 22 Apr 2002 09:35:10 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g3MDYCu15509 for ; Mon, 22 Apr 2002 16:34:12 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 22 Apr 2002 16:35:08 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Mon, 22 Apr 2002 16:35:08 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] comments Issue (8) included in draft-ietf-nsis-req-01 Date: Mon, 22 Apr 2002 16:35:07 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64FB7@esebe004.NOE.Nokia.com> Thread-Topic: [NSIS] comments Issue (8) included in draft-ietf-nsis-req-01 Thread-Index: AcHp2FaxLxyDj6pqSVeujtvohmq7oAAKhbEw To: , Cc: X-OriginalArrivalTime: 22 Apr 2002 13:35:08.0450 (UTC) FILETIME=[84F3F820:01C1EA02] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id JAA14656 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi, > Please receive my comments on Issue (8) included in the > NSIS WG draft: draft-ietf-nsis-req-01.txt > > Comment on Issue (8): > > > 8) (OPEN) bi-directional data path setup with one QoS request > > I have not seen consensus on whether to require > bi-directional data > > path setup with QoS. > > - How can we actually perform bi-directional > reservations when the > > forward and reverse paths are not reciprocal, with respect to > > routing topology and routing policy of network domains between > > sender and receiver? > > - The need to ensure that the return path is the same as the > > forwarding path is one of the problems with RSVP, > particularly in a > > mobile environment. > > [GK] The bi-directional data path setup does not need to use the same > [GK] return path as the forwarding path. The only requirement > to achieve > [GK] a bi-directional reservation is that the sender for the > forwarding path > [GK] is also the receiver for the return path and that the > receiver for the > [GK] forwarding path is also the sender for the return path. > [GK] Therefore, I think that the bi-directional option should not be mandatory > [GK] but at least optional; Perhaps 'Bi-directional QoS requests MAY be possible' is enough. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Mon Apr 22 09:48:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25676 for ; Mon, 22 Apr 2002 09:48:36 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA15317 for nsis-archive@odin.ietf.org; Mon, 22 Apr 2002 09:48:39 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA14862; Mon, 22 Apr 2002 09:37:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA14833 for ; Mon, 22 Apr 2002 09:37:27 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25340 for ; Mon, 22 Apr 2002 09:37:23 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g3MDbgF19625 for ; Mon, 22 Apr 2002 16:37:42 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 22 Apr 2002 16:37:24 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Mon, 22 Apr 2002 16:37:09 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] comments Issue (12) included in draft-ietf-nsis-req-01 Date: Mon, 22 Apr 2002 16:37:09 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64FB8@esebe004.NOE.Nokia.com> Thread-Topic: [NSIS] comments Issue (12) included in draft-ietf-nsis-req-01 Thread-Index: AcHp2MIrJG+F/657S06wthCqWuSZKQAKdWWw To: , Cc: X-OriginalArrivalTime: 22 Apr 2002 13:37:09.0989 (UTC) FILETIME=[CD655950:01C1EA02] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id JAA14834 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Georgios, > > 12) (CLOSED) text replacing scalability reqs > > "The nsis architecture should give the ability to > constrain the load > > (CPU load, memory space, signaling bandwidth consumption and > > signaling intensity) on devices where it is needed. This can be > > achieved by many different methods, for example message > aggregation, > > by ignoring signaling message, header compression or minimizing > > functionality. The architecture may choose any of these methods as > > long as the requirement is met." > > Editor: added the above text, but did not remove scalability reqs > > [GK] If the text will have to replace the scalability requirements, > [GK] then in my opinion it should be slightly modified by > adding the words > [GK] "and the number of reservation states". The text becomes then: > > "The nsis architecture should give the ability to constrain the load > (CPU load, memory space, signaling bandwidth consumption and > signaling intensity) and the number of reservation states on devices > where it is needed. This can be > achieved by many different methods, for example message aggregation, > by ignoring signaling message, header compression or minimizing > functionality. The architecture may choose any of these methods as > long as the requirement is met." I think that your text goes beyond what we can document. The NSIS 'architecture' (I prefer) framework, cannot talk about header compression, etc. - that is definately out of scope for NSIS. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Mon Apr 22 10:25:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26770 for ; Mon, 22 Apr 2002 10:25:25 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA17647 for nsis-archive@odin.ietf.org; Mon, 22 Apr 2002 10:25:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA16756; Mon, 22 Apr 2002 10:05:41 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA16723 for ; Mon, 22 Apr 2002 10:05:38 -0400 (EDT) Received: from tms001bb.han.telia.se (tms001bb.han.telia.se [131.115.230.132]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26250 for ; Mon, 22 Apr 2002 10:05:33 -0400 (EDT) From: Anders.P.Bergsten@telia.se Received: from TMS041MB.tcad.telia.se ([131.115.230.167]) by tms001bb.han.telia.se with Microsoft SMTPSVC(5.0.2195.2966); Mon, 22 Apr 2002 16:05:39 +0200 X-MIMEOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] comments Issue (12) included in draft-ietf-nsis-req-01 Date: Mon, 22 Apr 2002 16:05:39 +0200 Message-ID: <1BF8A5964E4EFA41A094B835FCA712912CCCDE@TMS041MB.tcad.telia.se> Thread-Topic: [NSIS] comments Issue (12) included in draft-ietf-nsis-req-01 Thread-Index: AcHp2MIrJG+F/657S06wthCqWuSZKQAKdWWwAACtgIA= To: , , Cc: X-OriginalArrivalTime: 22 Apr 2002 14:05:39.0885 (UTC) FILETIME=[C892C5D0:01C1EA06] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id KAA16724 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit John, As the original author of the text I would like to comment: >> 12) (CLOSED) text replacing scalability reqs >> "The nsis architecture should give the ability to >> constrain the load >> (CPU load, memory space, signaling bandwidth consumption and >> signaling intensity) on devices where it is needed. This can be >> achieved by many different methods, for example message >> aggregation, >> by ignoring signaling message, header compression or minimizing >> functionality. The architecture may choose any of these >> methods as long as the requirement is met." (this was the original text) > I think that your text goes beyond what we can document. The NSIS > 'architecture' (I prefer) framework, cannot talk about header > compression, etc. - that is definately out of scope for NSIS. The text mearly tries to state that the "framework" should give the ability to constrain "load". Then it _examplifies_ this with three different methods. This is doen to give some clarity to the requirement. Whether or not the examples stay or not is not my major concern, you can choose. However sometimes examples are good. Anders _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Mon Apr 22 11:01:18 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28214 for ; Mon, 22 Apr 2002 11:01:17 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA20135 for nsis-archive@odin.ietf.org; Mon, 22 Apr 2002 11:01:21 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA19204; Mon, 22 Apr 2002 10:47:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA19176 for ; Mon, 22 Apr 2002 10:47:09 -0400 (EDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27764 for ; Mon, 22 Apr 2002 10:47:03 -0400 (EDT) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g3MEl50E018478 for ; Mon, 22 Apr 2002 16:47:05 +0200 (MEST) Received: FROM esealnt746.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Mon Apr 22 16:44:06 2002 +0200 Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 22 Apr 2002 16:46:53 +0200 Message-ID: From: "Georgios Karagiannis (ELN)" To: "'john.loughney@nokia.com'" , brunner@ccrle.nec.de Cc: nsis@ietf.org Subject: RE: [NSIS] comments Issue (2) included in draft-ietf-nsis-req-01. txt Date: Mon, 22 Apr 2002 16:46:53 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi John From the discussions that we have had until now within the NSIS WG, I can conclude that we should develop a NSIS protocol that is optimized to be sender initiated and unicast. However, a receiver initiated version could be optionally developed. Best regards, Georgios -----Original Message----- From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] Sent: maandag 22 april 2002 15:34 To: Georgios.Karagiannis@eln.ericsson.se; brunner@ccrle.nec.de Cc: nsis@ietf.org Subject: RE: [NSIS] comments Issue (2) included in draft-ietf-nsis-req-01.txt Hi Marcus & Georgios, > Please receive my comments on Issue (2) included in the > NSIS WG draft: draft-ietf-nsis-req-01.txt > > Comment on Issue (2): > > > > 2) (OPEN) Sender/receiver initiation > > What is the requirement concerning data sender or data receiver or > > both to initiate a QoS request. > > - does it matter who pays? > > - terminology text added > > open issue, what is a potential req (currently we say "both must be > > possible") > > [GK] both should be possible but it should be optimized for > sender initiated; I think that SHOULD is the right level of requirement for sender / reciever driven requests. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Mon Apr 22 11:01:21 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28228 for ; Mon, 22 Apr 2002 11:01:21 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA20149 for nsis-archive@odin.ietf.org; Mon, 22 Apr 2002 11:01:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA19318; Mon, 22 Apr 2002 10:49:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA19287 for ; Mon, 22 Apr 2002 10:49:34 -0400 (EDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27904 for ; Mon, 22 Apr 2002 10:49:29 -0400 (EDT) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g3MEnV0E019526 for ; Mon, 22 Apr 2002 16:49:31 +0200 (MEST) Received: FROM esealnt747.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Mon Apr 22 16:46:05 2002 +0200 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id <2281Y4W5>; Mon, 22 Apr 2002 16:48:24 +0200 Message-ID: From: "Georgios Karagiannis (ELN)" To: "'john.loughney@nokia.com'" , brunner@ccrle.nec.de Cc: nsis@ietf.org Subject: RE: [NSIS] comments Issue (8) included in draft-ietf-nsis-req-01 Date: Mon, 22 Apr 2002 16:48:50 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi John Yes, I agree the bi-directional requirement is an optional requirement! Best regards, Georgios -----Original Message----- From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] Sent: maandag 22 april 2002 15:35 To: Georgios.Karagiannis@eln.ericsson.se; brunner@ccrle.nec.de Cc: nsis@ietf.org Subject: RE: [NSIS] comments Issue (8) included in draft-ietf-nsis-req-01 Hi, > Please receive my comments on Issue (8) included in the > NSIS WG draft: draft-ietf-nsis-req-01.txt > > Comment on Issue (8): > > > 8) (OPEN) bi-directional data path setup with one QoS request > > I have not seen consensus on whether to require > bi-directional data > > path setup with QoS. > > - How can we actually perform bi-directional > reservations when the > > forward and reverse paths are not reciprocal, with respect to > > routing topology and routing policy of network domains between > > sender and receiver? > > - The need to ensure that the return path is the same as the > > forwarding path is one of the problems with RSVP, > particularly in a > > mobile environment. > > [GK] The bi-directional data path setup does not need to use the same > [GK] return path as the forwarding path. The only requirement > to achieve > [GK] a bi-directional reservation is that the sender for the > forwarding path > [GK] is also the receiver for the return path and that the > receiver for the > [GK] forwarding path is also the sender for the return path. > [GK] Therefore, I think that the bi-directional option should not be mandatory > [GK] but at least optional; Perhaps 'Bi-directional QoS requests MAY be possible' is enough. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Mon Apr 22 11:04:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28331 for ; Mon, 22 Apr 2002 11:04:28 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA20410 for nsis-archive@odin.ietf.org; Mon, 22 Apr 2002 11:04:32 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA18954; Mon, 22 Apr 2002 10:42:35 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA18923 for ; Mon, 22 Apr 2002 10:42:33 -0400 (EDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27364 for ; Mon, 22 Apr 2002 10:42:27 -0400 (EDT) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g3MEgT0E015505 for ; Mon, 22 Apr 2002 16:42:29 +0200 (MEST) Received: FROM esealnt747.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Mon Apr 22 16:39:42 2002 +0200 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id <2281Y447>; Mon, 22 Apr 2002 16:42:01 +0200 Message-ID: From: "Georgios Karagiannis (ELN)" To: "'john.loughney@nokia.com'" , brunner@ccrle.nec.de Cc: nsis@ietf.org Subject: RE: [NSIS] comments Issue (12) included in draft-ietf-nsis-req-01 Date: Mon, 22 Apr 2002 16:42:26 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi John My main comment was related to the addition of the words "number of reservation states" and that is within the scope of NSIS. Regarding the header compression text; it was an example used by Anders. Best Regards, Georgios -----Original Message----- From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] Sent: maandag 22 april 2002 15:37 To: Georgios.Karagiannis@eln.ericsson.se; brunner@ccrle.nec.de Cc: nsis@ietf.org Subject: RE: [NSIS] comments Issue (12) included in draft-ietf-nsis-req-01 Hi Georgios, > > 12) (CLOSED) text replacing scalability reqs > > "The nsis architecture should give the ability to > constrain the load > > (CPU load, memory space, signaling bandwidth consumption and > > signaling intensity) on devices where it is needed. This can be > > achieved by many different methods, for example message > aggregation, > > by ignoring signaling message, header compression or minimizing > > functionality. The architecture may choose any of these methods as > > long as the requirement is met." > > Editor: added the above text, but did not remove scalability reqs > > [GK] If the text will have to replace the scalability requirements, > [GK] then in my opinion it should be slightly modified by > adding the words > [GK] "and the number of reservation states". The text becomes then: > > "The nsis architecture should give the ability to constrain the load > (CPU load, memory space, signaling bandwidth consumption and > signaling intensity) and the number of reservation states on devices > where it is needed. This can be > achieved by many different methods, for example message aggregation, > by ignoring signaling message, header compression or minimizing > functionality. The architecture may choose any of these methods as > long as the requirement is met." I think that your text goes beyond what we can document. The NSIS 'architecture' (I prefer) framework, cannot talk about header compression, etc. - that is definately out of scope for NSIS. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Mon Apr 22 15:49:06 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10468 for ; Mon, 22 Apr 2002 15:49:06 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA14869 for nsis-archive@odin.ietf.org; Mon, 22 Apr 2002 15:49:10 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA13180; Mon, 22 Apr 2002 15:31:28 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA13139 for ; Mon, 22 Apr 2002 15:31:25 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09847 for ; Mon, 22 Apr 2002 15:31:20 -0400 (EDT) From: Hemant.Chaskar@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g3MJVfF16272 for ; Mon, 22 Apr 2002 22:31:41 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 22 Apr 2002 22:31:21 +0300 Received: from daebh002.NOE.Nokia.com ([172.18.242.232]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Mon, 22 Apr 2002 22:31:21 +0300 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Mon, 22 Apr 2002 14:30:48 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1EA34.344098D3" Date: Mon, 22 Apr 2002 15:30:47 -0400 Message-ID: Thread-Topic: MIP QoS requirements draft - modification proposal for Section 3.3.2 Thread-Index: AcHqNDQ65uuu1j4tQ4WuZBhJMq4cBQ== To: Cc: X-OriginalArrivalTime: 22 Apr 2002 19:30:48.0853 (UTC) FILETIME=[34D30C50:01C1EA34] Subject: [NSIS] MIP QoS requirements draft - modification proposal for Section 3.3.2 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C1EA34.344098D3 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi: =20 I received some comments privately that the text in Section 3.3.2 of = draft-ietf-mobileip-qos-requirements-02.txt, is not clear enough. In = response to that, I propose the following modification to this text. = Please let me know if you have any comments, else I will go ahead and = incorporate it in the next version (03) of the draft. =20 Thanks, Hemant =20 Old text: ---------- =20 2. Interactions with link-layer support for QoS: =20 The QoS mechanism MAY provide some information to the link layers for = them to support the required QoS. Since a vast number of devices using = Mobile IP will be connected to the Internet via wireless links, QoS = parameters relevant for wireless links, such as error rate, MAY have to = be included in the set of IP-level QoS parameters to be possibly = considered by the underlying link layer. =20 An example scenario will be two UDP streams requiring different levels = of error protection at the link layer. For such cases, an IP-layer QoS = mechanism may indicate some generic parameters such as acceptable IP = packet loss rate to link layers. =20 New text: ----------- =20 2. Interactions with wireless link-layer support for QoS: =20 Since a vast number of devices using Mobile IP will be connected to the = Internet via wireless links, the QoS mechanism for Mobile IP MAY provide = some information to the wireless link layers for them to support the = required QoS.=20 =20 An example scenario that may benefit from such information is that of = the two UDP streams associated with the same media, but requiring = different levels of error protection at the wireless link layer due to = certain characteristics of their respective encoding schemes. The = packets of these two streams are equally delay sensitive (so as to = maintain playout synchronization at the receiver), and hence, may be = treated equally (as regards queuing) by IP layer. But they may need to = be transmitted on wireless channels of different error = characteristics(say different FEC coding or power levels). =20 The QoS information included for the benefit of wireless link layers = SHOULD be such that it is meaningful both ways: to applications that = reside over IP so that they can choose the IP service of certain QoS = characteristics and to wireless link QoS managers so that they can then = map this information to the details of lower layer mechanisms and their = parameters. =20 In the example scenario described above, such a QoS information could be = expressed as the acceptable loss rate of IP packets in the UDP stream. = This parameter enables the UDP application to choose the IP service = having QoS that matches its requirements, and it also enables the = wireless link QoS managers to choose the right wireless channel to = transmit the packets of this UDP stream. ------_=_NextPart_001_01C1EA34.344098D3 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi:
 
I received some comments privately = that the text=20 in Section 3.3.2 of draft-ietf-mobileip-qos-requirements-02.txt, is not = clear=20 enough. In response to that, I propose the following modification to = this text.=20 Please let me know if you have any comments, else I will go ahead and=20 incorporate it in the next version (03) of the draft.
 
Thanks,
Hemant
 
Old text:
----------
 
2. Interactions with link-layer = support for=20 QoS:
 
The QoS mechanism MAY provide some = information to=20 the link layers for them to support the required QoS. Since a vast = number of=20 devices using Mobile IP will be connected to the Internet via wireless = links,=20 QoS parameters relevant for wireless links, such as error rate, MAY have = to be=20 included in the set of IP-level QoS parameters to be possibly considered = by the=20 underlying link layer.
 
An example scenario will be two UDP = streams=20 requiring different levels of error protection at the link layer. For = such=20 cases, an IP-layer QoS mechanism may indicate some generic parameters = such as=20 acceptable IP packet loss rate to link layers.
 
New text:
-----------
 
2. Interactions with wireless = link-layer support=20 for QoS:
 
Since a vast number of devices using = Mobile IP=20 will be connected to the Internet via wireless links, the QoS mechanism = for=20 Mobile IP MAY provide some information to the wireless link layers for = them to=20 support the required QoS.
  
An example scenario that = may=20 benefit from such information is that of the two UDP streams associated = with the=20 same media, but requiring different levels of error protection at the = wireless=20 link layer due to certain characteristics of their respective encoding = schemes.=20 The packets of these two streams are equally delay sensitive (so as to = maintain=20 playout synchronization at the receiver), and hence, may be treated = equally (as=20 regards queuing) by IP layer. But they may need to be transmitted on = wireless=20 channels of different error characteristics(say different FEC coding or = power=20 levels).
  
The QoS information included for the = benefit of=20 wireless link layers SHOULD be such that it is meaningful both ways: to=20 applications that reside over IP so that they can choose the IP service = of=20 certain QoS characteristics and to wireless link QoS managers so that = they can=20 then map this information to the details of lower layer mechanisms and = their=20 parameters.
 
In the example scenario described = above, such a=20 QoS information could be expressed as the acceptable loss rate of IP = packets in=20 the UDP stream. This parameter enables the UDP application to choose the = IP=20 service having QoS that matches its requirements, and it also enables = the=20 wireless link QoS managers to choose the right wireless channel to = transmit the=20 packets of this UDP stream.
------_=_NextPart_001_01C1EA34.344098D3-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon Apr 22 23:55:17 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24407 for ; Mon, 22 Apr 2002 23:55:17 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id XAA14435 for nsis-archive@odin.ietf.org; Mon, 22 Apr 2002 23:55:19 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA14171; Mon, 22 Apr 2002 23:45:45 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA14137 for ; Mon, 22 Apr 2002 23:45:41 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24294 for ; Mon, 22 Apr 2002 23:45:37 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g3N3jwF08579 for ; Tue, 23 Apr 2002 06:45:59 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 23 Apr 2002 06:45:39 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 23 Apr 2002 06:45:39 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] comments Issue (2) included in draft-ietf-nsis-req-01.txt Date: Tue, 23 Apr 2002 06:45:38 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64FBD@esebe004.NOE.Nokia.com> Thread-Topic: [NSIS] comments Issue (2) included in draft-ietf-nsis-req-01.txt Thread-Index: AcHqDJVHOw8oGh7UQ3qeFRzX/r7SpQAbJi+g To: , Cc: X-OriginalArrivalTime: 23 Apr 2002 03:45:39.0304 (UTC) FILETIME=[55B65680:01C1EA79] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id XAA14138 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Georgios, > From the discussions that we have had until now > within the NSIS WG, > I can conclude that we should develop a NSIS protocol > that is optimized to be sender initiated and unicast. > However, a receiver initiated version could > be optionally developed. I agree. SHOULD support sender initiated MAY support reciever initiated MUST support unicast MAY support multicast. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Mon Apr 22 23:56:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24429 for ; Mon, 22 Apr 2002 23:56:56 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id XAA14454 for nsis-archive@odin.ietf.org; Mon, 22 Apr 2002 23:56:59 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA14254; Mon, 22 Apr 2002 23:48:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA14221 for ; Mon, 22 Apr 2002 23:48:03 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24326 for ; Mon, 22 Apr 2002 23:47:59 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g3N3mLF09142 for ; Tue, 23 Apr 2002 06:48:21 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 23 Apr 2002 06:48:01 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 23 Apr 2002 06:48:01 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] comments Issue (12) included in draft-ietf-nsis-req-01 Date: Tue, 23 Apr 2002 06:48:00 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64FBE@esebe004.NOE.Nokia.com> Thread-Topic: [NSIS] comments Issue (12) included in draft-ietf-nsis-req-01 Thread-Index: AcHqC+8TpkOSAvkrR1OmkOWJsW3q9QAbX4ug To: , Cc: X-OriginalArrivalTime: 23 Apr 2002 03:48:01.0485 (UTC) FILETIME=[AA756FD0:01C1EA79] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id XAA14222 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi, > My main comment was related to the addition of > the words "number of reservation states" and that is > within the scope of NSIS. > > Regarding the header compression text; it was an example used > by Anders. OK, the complaint I had was this: The architecture may choose any of these methods as long as the requirement is met. I'd change it to be: Systems may use some of the above methods to meet the requirement, but how this is done is outside the scope of this document. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Tue Apr 23 03:44:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08509 for ; Tue, 23 Apr 2002 03:44:07 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA06089 for nsis-archive@odin.ietf.org; Tue, 23 Apr 2002 03:44:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA05697; Tue, 23 Apr 2002 03:31:51 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA05663 for ; Tue, 23 Apr 2002 03:31:47 -0400 (EDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08418 for ; Tue, 23 Apr 2002 03:31:44 -0400 (EDT) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g3N7Vks7022229 for ; Tue, 23 Apr 2002 09:31:46 +0200 (MEST) Received: FROM esealnt746.al.sw.ericsson.se BY esealnt461 ; Tue Apr 23 09:31:45 2002 +0200 Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 23 Apr 2002 09:31:45 +0200 Message-ID: From: "Georgios Karagiannis (ELN)" To: "'john.loughney@nokia.com'" , brunner@ccrle.nec.de Cc: nsis@ietf.org Subject: RE: [NSIS] comments Issue (2) included in draft-ietf-nsis-req-01. txt Date: Tue, 23 Apr 2002 09:31:43 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi John I agree with the proposal that you gave! Best Regards, Georgios -----Original Message----- From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] Sent: dinsdag 23 april 2002 5:46 To: Georgios.Karagiannis@eln.ericsson.se; brunner@ccrle.nec.de Cc: nsis@ietf.org Subject: RE: [NSIS] comments Issue (2) included in draft-ietf-nsis-req-01.txt Hi Georgios, > From the discussions that we have had until now > within the NSIS WG, > I can conclude that we should develop a NSIS protocol > that is optimized to be sender initiated and unicast. > However, a receiver initiated version could > be optionally developed. I agree. SHOULD support sender initiated MAY support reciever initiated MUST support unicast MAY support multicast. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Tue Apr 23 04:41:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08510 for ; Tue, 23 Apr 2002 03:44:07 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA06088 for nsis-archive@odin.ietf.org; Tue, 23 Apr 2002 03:44:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA05151; Tue, 23 Apr 2002 03:29:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA05123 for ; Tue, 23 Apr 2002 03:29:41 -0400 (EDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08402 for ; Tue, 23 Apr 2002 03:29:37 -0400 (EDT) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g3N7Tds7020919 for ; Tue, 23 Apr 2002 09:29:39 +0200 (MEST) Received: FROM esealnt746.al.sw.ericsson.se BY esealnt461 ; Tue Apr 23 09:29:38 2002 +0200 Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 23 Apr 2002 09:29:38 +0200 Message-ID: From: "Georgios Karagiannis (ELN)" To: "'john.loughney@nokia.com'" , brunner@ccrle.nec.de Cc: nsis@ietf.org Subject: RE: [NSIS] comments Issue (12) included in draft-ietf-nsis-req-01 Date: Tue, 23 Apr 2002 09:29:36 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi John I agree with your proposal! Best regards, Georgios -----Original Message----- From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] Sent: dinsdag 23 april 2002 5:48 To: Georgios.Karagiannis@eln.ericsson.se; brunner@ccrle.nec.de Cc: nsis@ietf.org Subject: RE: [NSIS] comments Issue (12) included in draft-ietf-nsis-req-01 Hi, > My main comment was related to the addition of > the words "number of reservation states" and that is > within the scope of NSIS. > > Regarding the header compression text; it was an example used > by Anders. OK, the complaint I had was this: The architecture may choose any of these methods as long as the requirement is met. I'd change it to be: Systems may use some of the above methods to meet the requirement, but how this is done is outside the scope of this document. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Wed Apr 24 03:49:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26729 for ; Wed, 24 Apr 2002 03:49:55 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA10603 for nsis-archive@odin.ietf.org; Wed, 24 Apr 2002 03:49:57 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA10139; Wed, 24 Apr 2002 03:41:29 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA10012 for ; Wed, 24 Apr 2002 03:41:24 -0400 (EDT) Received: from augean.eleceng.adelaide.edu.au (augean.eleceng.adelaide.edu.au [129.127.28.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26599; Wed, 24 Apr 2002 03:41:19 -0400 (EDT) Received: from eleceng.adelaide.edu.au (citr2.eleceng.adelaide.edu.au [129.127.29.38]) by augean.eleceng.adelaide.edu.au (8.10.1/8.10.1/ElecEng-1.0) with ESMTP id g3O7eU103479; Wed, 24 Apr 2002 17:10:30 +0930 (CST) Message-ID: <3CC66170.E1A50CA4@eleceng.adelaide.edu.au> Date: Wed, 24 Apr 2002 17:10:32 +0930 From: Amoakoh Gyasi-Agyei Organization: Centre for Internet Technology Research (CITR) X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: mip-qos@research.nokia.com, diffserv-interest@ietf.org, issll@mercury.lcs.mit.edu, nsis@ietf.org, seamoby@ietf.org, mflannag@cisco.com, kanodia@rice.edu, FrancisDomoney@aol.com, diffserv@ietf.org, Amoakoh , brian@hursley.ibm.com Content-Type: multipart/mixed; boundary="------------D774405C1F1EC9EDE76F370D" Subject: [NSIS] Wireless Diffserv Majordomo Discussion List? Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org This is a multi-part message in MIME format. --------------D774405C1F1EC9EDE76F370D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear Comrades, Some of us have already expressed a keen interest in creating an active Wireless Diffserv Majordomo Discussion List that will concentrate on technical issues pertaining to Diffserv over wireless links (such as modeling & performance analysis, implementation, etc.) which is otherwise compatible to Diffserv standards. Are the contents well addressed in any already existing list? Any more suggestions regarding scope, how the list should be organised, etc. Brian & other fellows: thanks for your support. P.S. Sorry if this email disturbs you in any way. Thanks. Thanks for your support & feedback, Amoakoh _______________________________________________________ Amoakoh Gyasi-Agyei Centre for Internet Technology Research (CITR) Electrical & Electronic Engineering Department Adelaide University Level 5, 10 Pulteney St., Adelaide 5000 Tel: +61 8 8303 6902 (office) Tel: +61 402 638 141 (mbl) Tel: +61 8 8271 4534 (home) Fax: +61 8 8303 4405 (office) http://aaron.eleceng.adelaide.edu.au/Personal/amoakoh/ --------------D774405C1F1EC9EDE76F370D Content-Type: text/x-vcard; charset=us-ascii; name="amoakoh.vcf" Content-Description: Card for Amoakoh Gyasi-Agyei Content-Disposition: attachment; filename="amoakoh.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Gyasi-Agyei;Amoakoh tel;cell:+61 402 638 141 tel;fax:+61 8 8303 4405 tel;work:+61 8 8303 6209 x-mozilla-html:FALSE adr:;;;;;; version:2.1 email;internet:Amoakoh@eleceng.adelaide.edu.au fn:Amoakoh end:vcard --------------D774405C1F1EC9EDE76F370D-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@optimus.ietf.org Wed Apr 24 08:27:19 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01377 for ; Wed, 24 Apr 2002 08:27:19 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA25335 for nsis-archive@odin.ietf.org; Wed, 24 Apr 2002 08:27:21 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA24954; Wed, 24 Apr 2002 08:18:40 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA24921 for ; Wed, 24 Apr 2002 08:18:33 -0400 (EDT) Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01105 for ; Wed, 24 Apr 2002 08:18:25 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g3OCJaJ14120 for ; Wed, 24 Apr 2002 15:19:36 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 24 Apr 2002 15:18:25 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 24 Apr 2002 15:18:25 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Wed, 24 Apr 2002 15:18:25 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64FD9@esebe004.NOE.Nokia.com> Thread-Topic: Updated info about the Interim Meeting Thread-Index: AcHriiJhWosr3ATVSreN6an2NM8Ddg== To: X-OriginalArrivalTime: 24 Apr 2002 12:18:25.0644 (UTC) FILETIME=[224B02C0:01C1EB8A] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id IAA24923 Subject: [NSIS] Updated info about the Interim Meeting Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi all, A few people have pointed out that at the end of the announcement, I had the wrong dates listed, so the correct dates are: The rough agenda is as follows: Tuesday May 21st 10 AM to 4 PM Wednesday May 22nd 9 AM to 4 PM Thursday May 23rd 9 AM to 12 Noon Please indicate your attendance Tues ___ Wed ___ Thurs ___ Also, when registering at one of the hotels, the code is NOK. Seaside hotel: single room 90EUR, double room 112EUR Address: Ruoholahdenranta 3 FIN-00180 Helsinki, Finland Tel. +358 (0)9 693 60 Sales: +358 (0)9 6936 1016 Fax: +358 (0)9 6932 123 e-mail: seaside@seasidehotel.fi Web: www.seasidehotel.fi Toll free: 9800 2010 Best Western Worldwide Radisson SAS Royal hotel: single and double room 110EUR Address: Runeberginkatu, 2 SF-00100 Helsinki, Finland Phone: +358 9 695 80 Email: sales.royal.helsinki@radissonsas.com http://www.radisson.com/helsinkifi Thanks! John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Wed Apr 24 13:18:13 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29381 for ; Wed, 24 Apr 2002 13:18:11 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA17983 for nsis-archive@odin.ietf.org; Wed, 24 Apr 2002 13:18:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA17506; Wed, 24 Apr 2002 13:08:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA17473 for ; Wed, 24 Apr 2002 13:08:21 -0400 (EDT) Received: from auds953.usa.alcatel.com (auds953.usa.alcatel.com [143.209.238.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28906 for ; Wed, 24 Apr 2002 13:08:18 -0400 (EDT) Received: from alcatel.com (localhost [127.0.0.1]) by auds953.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g3OH7I424220; Wed, 24 Apr 2002 12:07:19 -0500 (CDT) Message-ID: <3CC6E65C.8090508@alcatel.com> Date: Wed, 24 Apr 2002 12:07:40 -0500 From: Behcet Sarikaya Organization: Alcatel USA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2 X-Accept-Language: en-us MIME-Version: 1.0 To: Amoakoh Gyasi-Agyei CC: nsis@ietf.org Subject: Re: [NSIS] Wireless Diffserv Majordomo Discussion List? References: <3CC66170.E1A50CA4@eleceng.adelaide.edu.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 7bit Comrade Amoakoh, These issues are normally treated in the standards organization of the specific link, e.g. 802.11g is for QoS in IEEE 802.11 links, etc. Regards, Amoakoh Gyasi-Agyei wrote: >Dear Comrades, > >Some of us have already expressed a keen interest in creating an active >Wireless Diffserv Majordomo Discussion List that will concentrate on >technical issues pertaining to Diffserv over wireless links (such as >modeling & performance analysis, implementation, etc.) which is >otherwise compatible to Diffserv standards. Are the contents well >addressed in any already existing list? Any more suggestions regarding >scope, how the list should be organised, etc. > >Brian & other fellows: thanks for your support. > >P.S. Sorry if this email disturbs you in any way. Thanks. > >Thanks for your support & feedback, >Amoakoh >_______________________________________________________ >Amoakoh Gyasi-Agyei >Centre for Internet Technology Research (CITR) >Electrical & Electronic Engineering Department >Adelaide University >Level 5, 10 Pulteney St., Adelaide 5000 >Tel: +61 8 8303 6902 (office) >Tel: +61 402 638 141 (mbl) >Tel: +61 8 8271 4534 (home) >Fax: +61 8 8303 4405 (office) >http://aaron.eleceng.adelaide.edu.au/Personal/amoakoh/ > -- Behcet _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Wed Apr 24 20:45:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12447 for ; Wed, 24 Apr 2002 20:45:27 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA12549 for nsis-archive@odin.ietf.org; Wed, 24 Apr 2002 20:45:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA12198; Wed, 24 Apr 2002 20:35:34 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA12167 for ; Wed, 24 Apr 2002 20:35:31 -0400 (EDT) Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12324 for ; Wed, 24 Apr 2002 20:35:28 -0400 (EDT) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate3.mot.com (motgate3 2.1) with ESMTP id RAA27124 for ; Wed, 24 Apr 2002 17:23:46 -0700 (MST)] Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id RAA08555 for ; Wed, 24 Apr 2002 17:35:29 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2654.52) id <2NG913RG>; Wed, 24 Apr 2002 19:35:29 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B046500F0@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'john.loughney@nokia.com'" , Nakhjiri Madjid-MNAKHJI1 Cc: nsis@ietf.org Subject: RE: [NSIS] refreshes Date: Wed, 24 Apr 2002 19:35:16 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain; charset="Windows-1251" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Hi John, Well, it depends if you see reliability is a requirement or a solution. BR, Madjid -----Original Message----- From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] Sent: Monday, April 22, 2002 3:03 AM To: Madjid Nakhjiri Cc: nsis@ietf.org Subject: RE: [NSIS] refreshes Hi Madjid, > Thanks for the respone and sorry for the delay. Are refreshes > required then? I must have missed it in the requirements? Refreshes, in my opinion, are much more of a solution, than a requirement. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Thu Apr 25 00:02:32 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17490 for ; Thu, 25 Apr 2002 00:02:32 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id AAA22276 for nsis-archive@odin.ietf.org; Thu, 25 Apr 2002 00:02:32 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA21415; Wed, 24 Apr 2002 23:51:18 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA21384 for ; Wed, 24 Apr 2002 23:51:15 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17335 for ; Wed, 24 Apr 2002 23:51:12 -0400 (EDT) From: john.loughney@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g3P3pWF10592 for ; Thu, 25 Apr 2002 06:51:32 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 25 Apr 2002 06:51:11 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Thu, 25 Apr 2002 06:51:11 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1251" Subject: RE: [NSIS] refreshes Date: Thu, 25 Apr 2002 06:51:10 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64FE0@esebe004.NOE.Nokia.com> Thread-Topic: [NSIS] refreshes Thread-Index: AcHr8RuwnO2i3onbRTSszK+089CYtgAGzexw To: Cc: X-OriginalArrivalTime: 25 Apr 2002 03:51:11.0507 (UTC) FILETIME=[708BFE30:01C1EC0C] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id XAA21385 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org Content-Transfer-Encoding: 8bit Hi Madjid, > Well, it depends if you see reliability is a requirement or > a solution. Reliablility is reliability. Refreshes can be used to achieve reliability, so therefor it is a solution. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From daemon@ns.ietf.org Thu Apr 25 17:16:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06457 for ; Thu, 25 Apr 2002 17:16:07 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA11805 for nsis-archive@odin.ietf.org; Thu, 25 Apr 2002 17:16:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA10888; Thu, 25 Apr 2002 17:02:47 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA10858 for ; Thu, 25 Apr 2002 17:02:45 -0400 (EDT) Received: from dnbnt.dnb.com.tw (61-220-95-202.HINET-IP.hinet.net [61.220.95.202]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05874 for ; Thu, 25 Apr 2002 17:02:40 -0400 (EDT) Message-Id: <200204252102.RAA05874@ietf.org> Received: from test (202.103.67.44 [202.103.67.44]) by dnbnt.dnb.com.tw with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2232.9) id JTL0Y78N; Thu, 25 Apr 2002 23:06:19 +0800 Reply-To: office_management@desertmail.com From: andrew12643@messpro.com To: nsis@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Thu, 25 Apr 2002 08:09:13 -0700 Subject: [NSIS] ===Medical Breakthrough...Aging can be reversed=== 12643 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Next Steps in Signaling X-BeenThere: nsis@ietf.org All HGH (Human Growth Hormone) products are not the same. There are three different types of products. Yet, all three are advertised as if they where the same. The three types are: 1) Homeopathic HGH 2) Pre-cursor HGH 3) Real or synthetic HGH (delivered by injection or, by an oral spray method). Do you know differences? Call us and we'll explain them to you. Our toll free number is 888-621-7300. For more information on HGH read on............ ***************************************************************************** HAVE YOU HEARD OF HUMAN GROWTH HORMONE (HGH)??? Released by your own pituitary gland, HGH starts declining in your 20s, even more in your 30s and 40s, eventually resulting in the shrinkage of major organs -- plus, all other symptoms related to old age. IN THOUSANDS OF CLINICAL STUDIES, HGH HAS BEEN SHOWN TO ACCOMPLISH THE FOLLOWING: * Reduce Body Fat and Build Lean Muscle WITHOUT EXERCISE! * Enhance Sexual Performance * Remove Wrinkles and Cellulite * Lower Blood Pressure and Improve Cholesterol Profile * Improve Sleep, Vision and Memory * Restore Hair Color and Growth * Strengthen the Immune System * Increase Energy and Cardiac Output * Turn back your body's Biological Time Clock 10 - 20 years * Live Longer AND Stronger All natural and organic plant based FEEL 10 YEARS YOUNGER WITH ORAL SPRAY HGH. GUARANTEED We are the manufacturer and we sell directly to Doctors, Chiropractors, and consumers world wide the highest grade HGH Oral Spray available. With internet marketing, we are able to save advertising cost and pass those savings along to you. But you must act now. To receive more information call us now. TOLL FREE 1-888-621-7300 We must speak to you in person to qualify your usage. All of your questions will be addressed and answered in a friendly, no pressure manner. Our main purpose is to provide you with information so you can make an educated decision. For more information call 1-888-621-7300 If you are on line write down our phone number and call us when you can. Soon, you and your loved ones will be very glad you did. Read what people are saying: "The effects of 6 months of GH on lean body mass and fat were equivalent in magnitude to the changes incurred during 10-20 years of aging." Dr. Daniel Rudman, MD, New England Journal of Medicine. "Within four months, my body fat decreased form 30% down to 21%! I noticed my skin is more supple and my overall mental outlook improved significantly." D.W., New Jersey "We have been on the spray for just 3 weeks now, and besides the tremendous energy we both feel, my husbands allergies and spells of depression have lifted. I am healing extremely fast after an accident and have lost 7 lbs. without trying!" C.B., Flagstaff. AZ Thanks for reading our letter, The HGH Staff USA Division PS: The HGH Staff guarantees the highest quality and lowest price. We manufacture and ship directly to your door. Offer expires 19 April 2002 Call us now 1-888-621-7300 *********************************************************** ======= End of message ======== To Qualify for a Free HGH Consultation call the HGH Staff -- Today. *********************************************************** The following statement is provided to be in compliance with commercial email laws. If you do not wish to receive further mailings, please click reply and type remvoe in the subject box. Then click send. This message is in full compliance with U.S. Federal requirements for commercial email under bill S.1618 Title lll, Section 301, Paragraph (a)(2)(C) passed by the 105th U.S. Congress and is not considered SPAM since it includes a remove mechanism. *********************************************************** This message is not intended for residents in the states of CA, NC, NV, RI, TN, VA & WA. Screening of addresses has been done to the best of our technical ability. *********************************************************** Call us now 1-888-621-7300 for your free HGH consultation. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis