From daemon@optimus.ietf.org  Fri Feb  1 02:39: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 CAA03175
	for <nsis-archive@odin.ietf.org>; Fri, 1 Feb 2002 02:39:23 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id CAA28550
	for nsis-archive@odin.ietf.org; Fri, 1 Feb 2002 02:39: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 CAA28516;
	Fri, 1 Feb 2002 02:38:25 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA28485
	for <nsis@optimus.ietf.org>; Fri, 1 Feb 2002 02:38:23 -0500 (EST)
Received: from mail1.telekom.de ([62.225.183.235])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03131
	for <nsis@ietf.org>; Fri, 1 Feb 2002 02:38:18 -0500 (EST)
Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Fri, 1 Feb 2002 08:36:02 +0100
Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19)
	id <DVHT831C>; Fri, 1 Feb 2002 08:37:45 +0100
Message-Id: <DFD875E85664D3118FA6080006277DE70362C882@U8PN2>
From: "Geib, Ruediger" <Ruediger.Geib@t-systems.com>
To: mat@cisco.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] summary of thread on data and signalling path
Date: Fri, 1 Feb 2002 08:37:44 +0100 
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 CAA28486
Sender: nsis-admin@ietf.org
Errors-To: nsis-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Next Steps in Signaling <nsis.ietf.org>
X-BeenThere: nsis@ietf.org
Content-Transfer-Encoding: 8bit

Hi Mike,

> David Partain writes:
>  > Marcus started this thread by stating that he doesn't think this
>  > should be a requirement.  I think we need to consider the
>  > scenarios.
>  > 
>  >  - There are absolutely going to be cases where a centralized
>  >    entity will take a decision about QoS requests.  In this
>  >    case, there's no question there is no need to have data
>  >    follow the signalling path.
> 
> Has somebody shown, absolutely, how this centralized
> thing understands an arbitrary routing topology between
> the sender and receiver? What happends when it leaves
> an AS?

I guess one of the most challenging issues with centralized admission control is making the proxy topology aware. It will have to intercept routing. It may be useful to have one proxy per intra-domain routing area. While I was working on an inter proxy signalling interface we never considered one proxy to cover more than one AS. 
I think "centralized" doesn't mean "single system". (The same would hold for "decentralized", which doesn't mean "every node".) 

Regards, Rüdiger 

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



From daemon@optimus.ietf.org  Fri Feb  1 07:38: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 HAA20250
	for <nsis-archive@odin.ietf.org>; Fri, 1 Feb 2002 07:38:13 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id HAA11731
	for nsis-archive@odin.ietf.org; Fri, 1 Feb 2002 07:38:17 -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 HAA11283;
	Fri, 1 Feb 2002 07:30: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 HAA11228
	for <nsis@optimus.ietf.org>; Fri, 1 Feb 2002 07:30:46 -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 HAA20075
	for <nsis@ietf.org>; Fri, 1 Feb 2002 07:30:41 -0500 (EST)
Received: from irams1.ira.uka.de ([129.13.10.5])
	by iraun2.uka.de with esmtp (Exim 3.30 #7 (Debian))
	id 16Wcq3-0007nG-00; Fri, 01 Feb 2002 13:30:43 +0100
Received: from i72pc127.tm.uni-karlsruhe.de
	([141.3.70.78] helo=i72pc127.tm.uka.de ident=root)
	by irams1.ira.uka.de with esmtp (Exim 3.30 #7 (Debian))
	id 16Wcq2-0004KB-00; Fri, 01 Feb 2002 13:30:42 +0100
Received: from i72pc127.tm.uka.de (localhost [127.0.0.1])
	by i72pc127.tm.uka.de (8.11.2/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id g11CUgU15804;
	Fri, 1 Feb 2002 13:30:42 +0100
Message-Id: <200202011230.g11CUgU15804@i72pc127.tm.uka.de>
X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4+dev
To: Michael Thomas <mat@cisco.com>
cc: David.Partain@ericsson.com, NSIS Mailing List <nsis@ietf.org>
Subject: Re: [NSIS] summary of thread on data and signalling path 
In-Reply-To: Message from Michael Thomas <mat@cisco.com> 
   of "Thu, 31 Jan 2002 08:54:51 PST." <15449.30427.5587.662644@thomasm-u1.cisco.com> 
References: <0GQT00A5D35168@mbb1.ericsson.se>  <15449.30427.5587.662644@thomasm-u1.cisco.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Date: Fri, 01 Feb 2002 13:30:42 +0100
From: Roland Bless <bless@tm.uka.de>
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 <nsis.ietf.org>
X-BeenThere: nsis@ietf.org
Content-Transfer-Encoding: 8bit

Hi Michael,

> Has somebody shown, absolutely, how this centralized
> thing understands an arbitrary routing topology between
> the sender and receiver? What happends when it leaves
> an AS?

For instance, this centralized management entity (I call it DSDM -
Differentiated Services Domain Manager) can use BGP routing information
to get knowledge of the data path at AS level. In my proposed
architecture the Domain Manager does local admission control within the
domain and also dynamically creates aggregates of reservations to ASs or
networks downstream (thus, one can differentiate between Intra-Domain
and Inter-Domain reservations in analogy to the routing hierarchy).
Therefore, it knows the next DSDM in the adjacent AS hop towards which
it forwards a reservation request. In order to create aggregates, which
will give you scalability with respect to the number of reservation
states and signaling messages, you'll need the routing information at AS
level. 

However, there remain two problems:
- Routes might not be that stable as they should be for QoS provisioning
  (this is a general problem)
- Since you only know the path downstream to the destination, you cannot
  do bi-directional resource reservation in the same signaling message
  (paths may be asymmetric)

The signaling protocol has two different variants: End system <-> DSDM
and DSDM <-> DSDM, where the latter has only a few additional functions
due to aggregation. I'm currently working on a simulation of the DARIS
(Dynamic Aggregation of Reservations for Internet Services) approach
using the complete BGP extracted AS topology from March 2000 (only about
7100 AS nodes due to memory restrictions). So I'm working on the proof you
requested...

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  Fri Feb  1 10:59: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 KAA27380
	for <nsis-archive@odin.ietf.org>; Fri, 1 Feb 2002 10:59:02 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id KAA22534
	for nsis-archive@odin.ietf.org; Fri, 1 Feb 2002 10:59: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 KAA22201;
	Fri, 1 Feb 2002 10:52: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 KAA22170
	for <nsis@optimus.ietf.org>; Fri, 1 Feb 2002 10:52:41 -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 KAA27248
	for <nsis@ietf.org>; Fri, 1 Feb 2002 10:52:37 -0500 (EST)
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id g11Fq6605312;
	Fri, 1 Feb 2002 07:52: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 AAU50063;
	Fri, 1 Feb 2002 07:51:36 -0800 (PST)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id HAA22807; Fri, 1 Feb 2002 07:52:06 -0800 (PST)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15450.47526.240987.628050@thomasm-u1.cisco.com>
Date: Fri, 1 Feb 2002 07:52:06 -0800 (PST)
To: "Geib, Ruediger" <Ruediger.Geib@t-systems.com>
Cc: mat@cisco.com, nsis@ietf.org
Subject: RE: [NSIS] summary of thread on data and signalling path
In-Reply-To: <DFD875E85664D3118FA6080006277DE70362C882@U8PN2>
References: <DFD875E85664D3118FA6080006277DE70362C882@U8PN2>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!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 <nsis.ietf.org>
X-BeenThere: nsis@ietf.org
Content-Transfer-Encoding: 7bit

Geib, Ruediger writes:
 > > Has somebody shown, absolutely, how this centralized
 > > thing understands an arbitrary routing topology between
 > > the sender and receiver? What happends when it leaves
 > > an AS?
 > 
 > I guess one of the most challenging issues with centralized admission control is making the proxy topology aware. It will have to intercept routing. It may be useful to have one proxy per intra-domain routing area. While I was working on an inter proxy signalling interface we never considered one proxy to cover more than one AS. 
 > I think "centralized" doesn't mean "single system". (The same would hold for "decentralized", which doesn't mean "every node".) 

   
1) How does this jibe with routing protocols with
   local convergence properties -- like link state
   reversal protocols -- which seem like they'd be
   attractive for mobility? It appears to me that
   it may harm them since the centralized thing needs
   to be intimately involved with local changes.

2) The hardest problems of mobility is how
   things behave intradomain -- something that
   cellular systems have figured out, but IP
   protocols by and large have not. I don't
   see how centralization helps. I worry that
   it may, in fact, obfuscate the real problem.

3) Even if you manage to centralize the decision
   making, is there a need to inform the forwarders
   in the path about classification, etc? Would it
   need to alter the path to something other than
   the least cost routing metric? If so, how would 
   that be done?

	   Mike

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



From daemon@optimus.ietf.org  Mon Feb  4 03:38: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 DAA16516
	for <nsis-archive@odin.ietf.org>; Mon, 4 Feb 2002 03:38:16 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id DAA16433
	for nsis-archive@odin.ietf.org; Mon, 4 Feb 2002 03:38: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 DAA15116;
	Mon, 4 Feb 2002 03:23:49 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA15086
	for <nsis@optimus.ietf.org>; Mon, 4 Feb 2002 03:23:47 -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 DAA16327
	for <nsis@ietf.org>; Mon, 4 Feb 2002 03:23:44 -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.1.0/Switch-2.1.0) with ESMTP id g148NkZ22670
	for <nsis@ietf.org>; Mon, 4 Feb 2002 10:23:46 +0200 (EET)
Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T58dd145a6dac158f23077@esvir03nok.nokia.com> for <nsis@ietf.org>;
 Mon, 4 Feb 2002 10:23:40 +0200
Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779);
	 Mon, 4 Feb 2002 10:23: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"
Date: Mon, 4 Feb 2002 10:23:38 +0200
Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF09BC8E@esebe004.NOE.Nokia.com>
Thread-Topic: Working Group Requirements document
Thread-Index: AcGtVUCn78jbHqCCReKKRP4qmkvPnw==
To: <nsis@ietf.org>
X-OriginalArrivalTime: 04 Feb 2002 08:23:39.0287 (UTC) FILETIME=[3F894270:01C1AD55]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id DAA15087
Subject: [NSIS] Working Group Requirements document
Sender: nsis-admin@ietf.org
Errors-To: nsis-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Next Steps in Signaling <nsis.ietf.org>
X-BeenThere: nsis@ietf.org
Content-Transfer-Encoding: 8bit

Hi all,

There have several requests that the following document be made
a working group document:

http://search.ietf.org/internet-drafts/draft-brunner-nsis-req-00.txt

After discussing with our Area Directors, we have asked Marcus Brunner
to edit the Signaling Requirements draft, with the above draft
forming the basis of initial draft. 

I would like to see if there is interest within the working group to
have a conference call in order to help progress the work on this draft.

best regards,
John

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



From daemon@optimus.ietf.org  Mon Feb  4 04:09: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 EAA16980
	for <nsis-archive@odin.ietf.org>; Mon, 4 Feb 2002 04:09:42 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id EAA18392
	for nsis-archive@odin.ietf.org; Mon, 4 Feb 2002 04:09: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 DAA17551;
	Mon, 4 Feb 2002 03:57:19 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA17521
	for <nsis@optimus.ietf.org>; Mon, 4 Feb 2002 03:57:17 -0500 (EST)
Received: from mail1.telekom.de ([62.225.183.235])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16798
	for <nsis@ietf.org>; Mon, 4 Feb 2002 03:57:14 -0500 (EST)
Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Mon, 4 Feb 2002 09:54:28 +0100
Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19)
	id <1C09DDZZ>; Mon, 4 Feb 2002 09:56:07 +0100
Message-Id: <DFD875E85664D3118FA6080006277DE70362C888@U8PN2>
From: "Geib, Ruediger" <Ruediger.Geib@t-systems.com>
To: mat@cisco.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] summary of thread on data and signalling path
Date: Mon, 4 Feb 2002 09:56:02 +0100 
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 DAA17522
Sender: nsis-admin@ietf.org
Errors-To: nsis-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Next Steps in Signaling <nsis.ietf.org>
X-BeenThere: nsis@ietf.org
Content-Transfer-Encoding: 8bit

Hi Mike,

the resource managing proxy is absolutely passive with regard to routing. It is listening and checks whether resources per route fit to demand. To support mobility, the proxy could be the unit to store per reservation QoS context information and support admission release and control between old and new access router of the moving terminal.
Support for mobile environment however is limited: A centralized resource control system will probably only work in a low to medium mobility environment. If mobility means a large number of simultaneous handovers, maybe even coupled with ad hoc networks, a centralized resource control will not work.

I didn't mention that I assume a centralized resource control for a DiffServ domain (only). 

Regards, Rüdiger


> Geib, Ruediger writes:
>  > > Has somebody shown, absolutely, how this centralized
>  > > thing understands an arbitrary routing topology between
>  > > the sender and receiver? What happends when it leaves
>  > > an AS?
>  > 
>  > I guess one of the most challenging issues with 
> centralized admission control is making the proxy topology 
> aware. It will have to intercept routing. It may be useful to 
> have one proxy per intra-domain routing area. While I was 
> working on an inter proxy signalling interface we never 
> considered one proxy to cover more than one AS. 
>  > I think "centralized" doesn't mean "single system". (The 
> same would hold for "decentralized", which doesn't mean 
> "every node".) 
> 
>    
> 1) How does this jibe with routing protocols with
>    local convergence properties -- like link state
>    reversal protocols -- which seem like they'd be
>    attractive for mobility? It appears to me that
>    it may harm them since the centralized thing needs
>    to be intimately involved with local changes.
> 
> 2) The hardest problems of mobility is how
>    things behave intradomain -- something that
>    cellular systems have figured out, but IP
>    protocols by and large have not. I don't
>    see how centralization helps. I worry that
>    it may, in fact, obfuscate the real problem.
> 
> 3) Even if you manage to centralize the decision
>    making, is there a need to inform the forwarders
>    in the path about classification, etc? Would it
>    need to alter the path to something other than
>    the least cost routing metric? If so, how would 
>    that be done?
> 
> 	   Mike
> 

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



From daemon@optimus.ietf.org  Mon Feb  4 04:38: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 EAA17356
	for <nsis-archive@odin.ietf.org>; Mon, 4 Feb 2002 04:38:51 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id EAA19993
	for nsis-archive@odin.ietf.org; Mon, 4 Feb 2002 04:38: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 EAA19802;
	Mon, 4 Feb 2002 04:35: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 EAA19774
	for <nsis@optimus.ietf.org>; Mon, 4 Feb 2002 04:35:28 -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 EAA17317
	for <nsis@ietf.org>; Mon, 4 Feb 2002 04:35:22 -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.1.0/Switch-2.1.0) with ESMTP id g149ZTZ22260
	for <nsis@ietf.org>; Mon, 4 Feb 2002 11:35:29 +0200 (EET)
Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T58dd5603b3ac158f23077@esvir03nok.nokia.com>;
 Mon, 4 Feb 2002 11:35:23 +0200
Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779);
	 Mon, 4 Feb 2002 11:35:21 +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] RE: Independence of signaling and data path
Date: Mon, 4 Feb 2002 11:35:21 +0200
Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF5D955B@esebe004.NOE.Nokia.com>
Thread-Topic: [NSIS] RE: Independence of signaling and data path
Thread-Index: AcGqsdeS7TLtJ9JgRRaIw2ncCFcrlwCrPfIw
To: <ifreytsis@cetacean.com>
Cc: <nsis@ietf.org>
X-OriginalArrivalTime: 04 Feb 2002 09:35:22.0169 (UTC) FILETIME=[4440F290:01C1AD5F]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id EAA19775
Sender: nsis-admin@ietf.org
Errors-To: nsis-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Next Steps in Signaling <nsis.ietf.org>
X-BeenThere: nsis@ietf.org
Content-Transfer-Encoding: 8bit

Hi Ilya,

> I think it would help if you elaborate on the context to use the term
> "proxy".

Proxy is an entity that acts on behalf of another.  In terms of NSIS,
what I have thought would be that there would be an entity in the 
path which could act as a QoS proxy.  This QoS proxy would be 
responsible for setting up & managing the QoS resources needed.

This isn't a new idea, here are some drafts on the subject:

http://search.ietf.org/internet-drafts/draft-paskalis-rsvpmp-00.txt
http://search.ietf.org/internet-drafts/draft-ietf-rsvp-proxy-02.txt
http://search.ietf.org/internet-drafts/draft-nitsan-cops-rsvp-proxy-03.txt

John

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



From daemon@optimus.ietf.org  Mon Feb  4 09:56: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 JAA24272
	for <nsis-archive@odin.ietf.org>; Mon, 4 Feb 2002 09:56:00 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id JAA06713
	for nsis-archive@odin.ietf.org; Mon, 4 Feb 2002 09:56:02 -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 JAA06666;
	Mon, 4 Feb 2002 09:54: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 JAA06629
	for <nsis@optimus.ietf.org>; Mon, 4 Feb 2002 09:54:08 -0500 (EST)
Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24188
	for <nsis@ietf.org>; Mon, 4 Feb 2002 09:54:05 -0500 (EST)
Received: from mbb5.ericsson.se (mbb5.ericsson.se [136.225.151.210])
	by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id g14Es6C07579
	for <nsis@ietf.org>; Mon, 4 Feb 2002 15:54:06 +0100 (MET)
Received: from there (lm6068.lmera.ericsson.se [150.132.106.68])
 by mbb1.ericsson.se (PMDF V5.2-29 #39352)
 with SMTP id <0GR000DFFK24U0@mbb1.ericsson.se> for nsis@ietf.org; Mon,
 4 Feb 2002 15:54:05 +0100 (MET)
Date: Mon, 04 Feb 2002 15:55:22 +0100
From: David Partain <David.Partain@ericsson.com>
Subject: Re: [NSIS] Working Group Requirements document
In-reply-to: <0C1353ABB1DEB74DB067ADFF749C4EEF09BC8E@esebe004.NOE.Nokia.com>
To: NSIS Mailing List <nsis@ietf.org>
Reply-to: David.Partain@ericsson.com
Message-id: <0GR000DFJK25U0@mbb1.ericsson.se>
MIME-version: 1.0
X-Mailer: KMail [version 1.3.2]
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 8bit
References: <0C1353ABB1DEB74DB067ADFF749C4EEF09BC8E@esebe004.NOE.Nokia.com>
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 <nsis.ietf.org>
X-BeenThere: nsis@ietf.org
Content-Transfer-Encoding: 8bit

Hi all,

> I would like to see if there is interest within the working group to
> have a conference call in order to help progress the work on this draft.

There certainly is interest on my part.

Cheers,

dlp

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



From daemon@optimus.ietf.org  Mon Feb  4 10:01: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 KAA24515
	for <nsis-archive@odin.ietf.org>; Mon, 4 Feb 2002 10:01:22 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id KAA07415
	for nsis-archive@odin.ietf.org; Mon, 4 Feb 2002 10:01: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 JAA06419;
	Mon, 4 Feb 2002 09:47: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 JAA06388
	for <nsis@optimus.ietf.org>; Mon, 4 Feb 2002 09:47:18 -0500 (EST)
Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23916
	for <nsis@ietf.org>; Mon, 4 Feb 2002 09:47:14 -0500 (EST)
Received: from esealnt406.al.sw.ericsson.se (ESEALNT406.al.sw.ericsson.se [153.88.251.29])
	by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g14ElGX4020015
	for <nsis@ietf.org>; Mon, 4 Feb 2002 15:47:16 +0100 (MET)
Received: FROM esealnt746.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Mon Feb 04 15:47:15 2002 +0100
Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <YHLJ317T>; Mon, 4 Feb 2002 15:47:16 +0100
Message-ID: <E244E44D6AB85E40AEEF7EAABE3545FA8233F3@enleent104.nl.eu.ericsson.se>
From: "Georgios Karagiannis (ELN)" <Georgios.Karagiannis@eln.ericsson.se>
To: "'john.loughney@nokia.com'" <john.loughney@nokia.com>, nsis@ietf.org
Subject: RE: [NSIS] Working Group Requirements document
Date: Mon, 4 Feb 2002 15:47:12 +0100 
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 <nsis.ietf.org>
X-BeenThere: nsis@ietf.org

Hi John

Yes, I am interested on contributing to this
telephone conference meeting!

Best regards,
Georgios

-----Original Message-----
From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]
Sent: maandag 4 februari 2002 9:24
To: nsis@ietf.org
Subject: [NSIS] Working Group Requirements document


Hi all,

There have several requests that the following document be made
a working group document:

http://search.ietf.org/internet-drafts/draft-brunner-nsis-req-00.txt

After discussing with our Area Directors, we have asked Marcus Brunner
to edit the Signaling Requirements draft, with the above draft
forming the basis of initial draft. 

I would like to see if there is interest within the working group to
have a conference call in order to help progress the work on this draft.

best regards,
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 Feb  4 10:04: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 KAA24800
	for <nsis-archive@odin.ietf.org>; Mon, 4 Feb 2002 10:04:31 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id KAA07614
	for nsis-archive@odin.ietf.org; Mon, 4 Feb 2002 10:04: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 KAA07556;
	Mon, 4 Feb 2002 10:03:19 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA07525
	for <nsis@optimus.ietf.org>; Mon, 4 Feb 2002 10:03:18 -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 KAA24748
	for <nsis@ietf.org>; Mon, 4 Feb 2002 10:03:15 -0500 (EST)
Received: by idcpa4.pa.interdigital.com with Internet Mail Service (5.5.2653.19)
	id <YZA1XJTZ>; Mon, 4 Feb 2002 10:01:29 -0500
Message-ID: <A1170612471BD21185B90008C7FA0A0D02D812F3@idcpa4.pa.interdigital.com>
From: "Shaheen, Kamel M." <Kamel.Shaheen@InterDigital.com>
To: "'john.loughney@nokia.com'" <john.loughney@nokia.com>, nsis@ietf.org
Subject: RE: [NSIS] Working Group Requirements document
Date: Mon, 4 Feb 2002 10:01:27 -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 <nsis.ietf.org>
X-BeenThere: nsis@ietf.org

Hi John,

I would be interested in the telecon meeting.

Kamel Shaheen
InterDigital Communication

-----Original Message-----
From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]
Sent: Mon, February 04, 2002 3:24 AM
To: nsis@ietf.org
Subject: [NSIS] Working Group Requirements document


Hi all,

There have several requests that the following document be made
a working group document:

http://search.ietf.org/internet-drafts/draft-brunner-nsis-req-00.txt

After discussing with our Area Directors, we have asked Marcus Brunner
to edit the Signaling Requirements draft, with the above draft
forming the basis of initial draft. 

I would like to see if there is interest within the working group to
have a conference call in order to help progress the work on this draft.

best regards,
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 Feb  4 12:03: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 MAA29382
	for <nsis-archive@odin.ietf.org>; Mon, 4 Feb 2002 12:03:58 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id MAA16392
	for nsis-archive@odin.ietf.org; Mon, 4 Feb 2002 12:04: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 LAA14674;
	Mon, 4 Feb 2002 11:53:08 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA14641
	for <nsis@ns.ietf.org>; Mon, 4 Feb 2002 11:53:06 -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 LAA28783
	for <nsis@ietf.org>; Mon, 4 Feb 2002 11:53:02 -0500 (EST)
Received: from sbctri.tri.sbc.com (sbctri [144.60.1.10])
	by howler.tri.sbc.com (8.11.0/8.11.0) with ESMTP id g14GsmT07512;
	Mon, 4 Feb 2002 10:54:48 -0600 (CST)
Received: from TRIMAIL2.ad.tri.sbc.com (localhost [127.0.0.1])
	by sbctri.tri.sbc.com (8.11.0/8.9.3) with ESMTP id g14GpxU27924;
	Mon, 4 Feb 2002 10:51:59 -0600 (CST)
Received: by TRIMAIL2.ad.tri.sbc.com with Internet Mail Service (5.5.2653.19)
	id <ZND3KL5D>; Mon, 4 Feb 2002 10:52:28 -0600
Message-ID: <905A1C4ABF353F4C8CC16FA9F53DD0D638B9D0@TRIMAIL2.ad.tri.sbc.com>
From: "Schneider, Marco" <schneider@tri.sbc.com>
To: "'john.loughney@nokia.com'" <john.loughney@nokia.com>, nsis@ietf.org
Subject: RE: [NSIS] Working Group Requirements document
Date: Mon, 4 Feb 2002 10:52:26 -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 <nsis.ietf.org>
X-BeenThere: nsis@ietf.org

Hi John,

I am very interested in participating.

Marco Schneider
SBC

> -----Original Message-----
> From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]
> Sent: Monday, February 04, 2002 2:24 AM
> To: nsis@ietf.org
> Subject: [NSIS] Working Group Requirements document
> 
> 
> Hi all,
> 
> There have several requests that the following document be made
> a working group document:
> 
> http://search.ietf.org/internet-drafts/draft-brunner-nsis-req-00.txt
> 
> After discussing with our Area Directors, we have asked Marcus Brunner
> to edit the Signaling Requirements draft, with the above draft
> forming the basis of initial draft. 
> 
> I would like to see if there is interest within the working group to
> have a conference call in order to help progress the work on 
> this draft.
> 
> best regards,
> 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 Feb  4 12:13: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 MAA29735
	for <nsis-archive@odin.ietf.org>; Mon, 4 Feb 2002 12:13:39 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id MAA17171
	for nsis-archive@odin.ietf.org; Mon, 4 Feb 2002 12:13:42 -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 MAA16952;
	Mon, 4 Feb 2002 12:11: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 MAA16914
	for <nsis@ns.ietf.org>; Mon, 4 Feb 2002 12:11:26 -0500 (EST)
Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29620
	for <nsis@ietf.org>; Mon, 4 Feb 2002 12:11:18 -0500 (EST)
Received: from mbb5.ericsson.se (mbb5.ericsson.se [136.225.151.210])
	by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g14HBJX4007604
	for <nsis@ietf.org>; Mon, 4 Feb 2002 18:11:19 +0100 (MET)
Received: from era.ericsson.se (rcur181ip231.ericsson.se [147.214.181.231])
 by mbb1.ericsson.se (PMDF V5.2-29 #39352)
 with ESMTP id <0GR00070JQEVPI@mbb1.ericsson.se> for nsis@ietf.org; Mon,
 4 Feb 2002 18:11:19 +0100 (MET)
Date: Mon, 04 Feb 2002 18:11:18 +0100
From: "Lars.Westberg" <Lars.Westberg@era.ericsson.se>
Subject: Re: [NSIS] Working Group Requirements document
To: john.loughney@nokia.com
Cc: nsis@ietf.org
Message-id: <3C5EC0B6.8B0F5C4@era.ericsson.se>
MIME-version: 1.0
X-Mailer: Mozilla 4.61 [en] (Win98; I)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7bit
X-Accept-Language: en
References: <0C1353ABB1DEB74DB067ADFF749C4EEF09BC8E@esebe004.NOE.Nokia.com>
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 <nsis.ietf.org>
X-BeenThere: nsis@ietf.org
Content-Transfer-Encoding: 7bit

I am interested to partizipate in the telephone conference.

Regards Lasse

john.loughney@nokia.com wrote:

> Hi all,
>
> There have several requests that the following document be made
> a working group document:
>
> http://search.ietf.org/internet-drafts/draft-brunner-nsis-req-00.txt
>
> After discussing with our Area Directors, we have asked Marcus Brunner
> to edit the Signaling Requirements draft, with the above draft
> forming the basis of initial draft.
>
> I would like to see if there is interest within the working group to
> have a conference call in order to help progress the work on this draft.
>
> best regards,
> 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 Feb  4 12: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 MAA29995
	for <nsis-archive@odin.ietf.org>; Mon, 4 Feb 2002 12:21:15 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id MAA17767
	for nsis-archive@odin.ietf.org; Mon, 4 Feb 2002 12:21: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 MAA16734;
	Mon, 4 Feb 2002 12:08: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 MAA16709
	for <nsis@ns.ietf.org>; Mon, 4 Feb 2002 12:08:07 -0500 (EST)
Received: from arb-exchange1.cetaceannetworks.com ([63.127.199.225])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29545
	for <nsis@ietf.org>; Mon, 4 Feb 2002 12:07:58 -0500 (EST)
Received: by mail.cetaceannetworks.com with Internet Mail Service (5.5.2653.19)
	id <1GGA35PK>; Mon, 4 Feb 2002 12:04:36 -0500
Message-ID: <6D8664171C38D511B5AD0002B325CE6633ECF9@mail.cetaceannetworks.com>
From: "Freytsis, Ilya" <ifreytsis@cetacean.com>
To: "'nsis@ietf.org'" <nsis@ietf.org>
Date: Mon, 4 Feb 2002 12:04:36 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [NSIS] RE: nsis digest, Vol 1 #131 - 7 msgs
Sender: nsis-admin@ietf.org
Errors-To: nsis-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Next Steps in Signaling <nsis.ietf.org>
X-BeenThere: nsis@ietf.org

John,
I'd like to participate in the conference call.
Ilya


From: john.loughney@nokia.com
charset="iso-8859-1"
Date: Mon, 4 Feb 2002 10:23:38 +0200
To: <nsis@ietf.org>
Subject: [NSIS] Working Group Requirements document

Hi all,

There have several requests that the following document be made
a working group document:

http://search.ietf.org/internet-drafts/draft-brunner-nsis-req-00.txt

After discussing with our Area Directors, we have asked Marcus Brunner
to edit the Signaling Requirements draft, with the above draft
forming the basis of initial draft.

I would like to see if there is interest within the working group to
have a conference call in order to help progress the work on this draft.

best regards,
John



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



From daemon@ns.ietf.org  Mon Feb  4 13:12: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 NAA01879
	for <nsis-archive@odin.ietf.org>; Mon, 4 Feb 2002 13:12:25 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id NAA21257
	for nsis-archive@odin.ietf.org; Mon, 4 Feb 2002 13:12: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 NAA21090;
	Mon, 4 Feb 2002 13:10: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 NAA21059
	for <nsis@ns.ietf.org>; Mon, 4 Feb 2002 13:10:07 -0500 (EST)
Received: from mail.icu.ac.kr (mail.icu.ac.kr [210.107.128.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01834
	for <nsis@ietf.org>; Mon, 4 Feb 2002 13:10:03 -0500 (EST)
Received: from jkyoungxp (v33-184.icu.ac.kr [210.107.133.184])
	by mail.icu.ac.kr (8.11.0/8.11.0) with SMTP id g14I2b504582;
	Tue, 5 Feb 2002 03:02:37 +0900 (KST)
Message-ID: <00b801c1ada6$f522a7b0$b8856bd2@jkyoungxp>
From: "Ki Young Jung" <jjungki@icu.ac.kr>
To: <john.loughney@nokia.com>, <nsis@ietf.org>
References: <0C1353ABB1DEB74DB067ADFF749C4EEF09BC8E@esebe004.NOE.Nokia.com>
Subject: Re: [NSIS] Working Group Requirements document
Date: Tue, 5 Feb 2002 03:08:32 +0900
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 <nsis.ietf.org>
X-BeenThere: nsis@ietf.org
Content-Transfer-Encoding: 7bit

Hi, all.
First, sorry for my poor English.

Indeed, I can't fully follow the mailing list, but I have some thinking
related with the
draft  http://search.ietf.org/internet-drafts/draft-brunner-nsis-req-00.txt.

> 3.4. Scenario 4: QoS reservations/negotiation from access to core
>     network

>   The scenario includes the signaling between access networks and core
>   networks in order to setup and change reservations together with
>   potential negotiation.

>   The issues to be solved in this scenario are different from previous
>   ones. The entity of reservation is most likely an aggregate, and the
>   time scales of reservations might be different (long living
>   reservations of aggregates, rarer re-negotiation). However, the
>   specification of the traffic, a particular QoS is guaranteed for,
>   needs to be changed. E.g., in case additional flows are added to the
>   aggregate, the traffic specification of the flow needs to be added
>   if it is not already included in the aggregates specification.

Actually, I think that if we mentioned about the mobility with the
aggregated flow, we should consider the dynamic resource allocation.
If a flow (or MT) leave from old aggregated flow or enter into new
aggregated flow, nothing will be requred to do, I think. But some flows
(MTs) are behave like that, re-provisioning signaling is needed to allocate
some additional resource or to release some extra resources as like the
draft. Also, it is another situation that some source terminals belonging a
aggregated flow are stop the packet transmission for a long time.
The signaling packet like this one should follows the path of a aggregated
flow, of course.

I hope to talk about this situation like above one within this mailing list.
And if I miss something, please forgive my ignorance and let me know.

Regards.

----------------------------------------------------
Ki Young Jung (jjungki@icu.ac.kr)
Information and Communications University(ICU)
Broadband Network Laboratory (http://bnlab.icu.ac.kr)
58-4 Hwaam-dong, Yusong-gu, Taejon, 305-732, KOREA
Tel)+82-42-866-6182, 016-370-1751 Fax)+82-42-866-6110


----- Original Message -----
From: <john.loughney@nokia.com>
To: <nsis@ietf.org>
Sent: Monday, February 04, 2002 5:23 PM
Subject: [NSIS] Working Group Requirements document


> Hi all,
>
> There have several requests that the following document be made
> a working group document:
>
> http://search.ietf.org/internet-drafts/draft-brunner-nsis-req-00.txt
>
> After discussing with our Area Directors, we have asked Marcus Brunner
> to edit the Signaling Requirements draft, with the above draft
> forming the basis of initial draft.
>
> I would like to see if there is interest within the working group to
> have a conference call in order to help progress the work on this draft.
>
> best regards,
> 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  Tue Feb  5 00:48: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 AAA15183
	for <nsis-archive@odin.ietf.org>; Tue, 5 Feb 2002 00:48:57 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id AAA24795
	for nsis-archive@odin.ietf.org; Tue, 5 Feb 2002 00:48: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 AAA24713;
	Tue, 5 Feb 2002 00:46: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 AAA24683
	for <nsis@optimus.ietf.org>; Tue, 5 Feb 2002 00:46:39 -0500 (EST)
Received: from cmail.packetcom.com ([63.108.173.139])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15133
	for <nsis@ietf.org>; Tue, 5 Feb 2002 00:46:38 -0500 (EST)
Received: from caspiannetworks.com (h-64-105-34-195.SNVACAID.covad.net [64.105.34.195])
	by cmail.packetcom.com (Mirapoint)
	with ESMTP id ABR49769 (AUTH tso@caspiannetworks.com);
	Mon, 4 Feb 2002 21:46:08 -0800 (PST)
Message-ID: <3C5F6B48.97A6A980@caspiannetworks.com>
Date: Mon, 04 Feb 2002 21:19:05 -0800
From: Tricci So <tso@caspiannetworks.com>
Organization: Caspian Networks
X-Mailer: Mozilla 4.78 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
CC: nsis@ietf.org
Subject: Re: [NSIS] Working Group Requirements document
References: <0C1353ABB1DEB74DB067ADFF749C4EEF09BC8E@esebe004.NOE.Nokia.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 <nsis.ietf.org>
X-BeenThere: nsis@ietf.org
Content-Transfer-Encoding: 7bit

Hi John et al,

Sorry for taking me so long to plug into the NSIS mailing list discussion.
It is not easy to keep up with the IETF work when there are other
responsibilities within the company.

Anyway, I truly appreciate all the hard work that been done to put together
the NSIS requirements draft.  I have quicky read through it.  It is very
comprehensive.  However, I do have some requests on the current format and
contents........

1. Although information is good, but too much information sometimes will
digress the real intent of the document.  May I suggest to move the service
application scenarios to the appendix since it seems to be the common
approach for most of the IETF draft.  So that audience can focus on the
scope and requirements discussions.

2. Is the QoS Initiator MUST always interact directly with QoS Controller?
I hope not that this is NOT the intent.

3. In term of the organization of the requirements, as it has been suggested
in section 4.2 that NSIS signaling could run end-to-end, end-to-edge,
edge-to-edge or network-to-network.  I am wondering that if the requirements
can be organized in such a way as
- general requirements
- end-to-edge signaling requirements for certain service applications -
edge-to-edge signaling requirements
- network-to-network signaling requirements

I thought that it may help to make the document more readable since there
are a lot of detailed requirements group together in a single section.   It
is easier to identify which requirement is applicable to which part of the
network.

4. Also, since the goal is to re-use existing protocols as much as possible,
I thought it may be a good idea to create a table of how certain existing
signaling protocol satisfies the given set of requirements in each of the
segment listed above.  By doing this exercise, it is much easier to examine
what are missing in the current signaling protocols.

B.T.W. The comparison can be resided in the appendix as well.

Truly thank you for such a great work.  I will also like to participate in
the conference call if one is available.

Cheers,
Tricci

john.loughney@nokia.comou  wrote:

> Hi all,
>
> There have several requests that the following document be made
> a working group document:
>
> http://search.ietf.org/internet-drafts/draft-brunner-nsis-req-00.txt
>
> After discussing with our Area Directors, we have asked Marcus Brunner
> to edit the Signaling Requirements draft, with the above draft
> forming the basis of initial draft.
>
> I would like to see if there is interest within the working group to
> have a conference call in order to help progress the work on this draft.
>
> best regards,
> 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  Tue Feb  5 01:35: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 BAA15581
	for <nsis-archive@odin.ietf.org>; Tue, 5 Feb 2002 01:35:19 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id BAA06402
	for nsis-archive@odin.ietf.org; Tue, 5 Feb 2002 01:35:20 -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 BAA05430;
	Tue, 5 Feb 2002 01:23:49 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA05401
	for <nsis@optimus.ietf.org>; Tue, 5 Feb 2002 01:23:47 -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 BAA15436
	for <nsis@ietf.org>; Tue, 5 Feb 2002 01:23:45 -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.1.0/Switch-2.1.0) with ESMTP id g156NoZ17645
	for <nsis@ietf.org>; Tue, 5 Feb 2002 08:23:50 +0200 (EET)
Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T58e1cced34ac158f23077@esvir03nok.nokia.com>;
 Tue, 5 Feb 2002 08:23:45 +0200
Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779);
	 Tue, 5 Feb 2002 08:23:45 +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] Working Group Requirements document
Date: Tue, 5 Feb 2002 08:23:45 +0200
Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF5D9580@esebe004.NOE.Nokia.com>
Thread-Topic: [NSIS] Working Group Requirements document
Thread-Index: AcGuCI4kYYJV8vtyQqysuG+eWDqQvgABHUZg
To: <tso@caspiannetworks.com>
Cc: <nsis@ietf.org>
X-OriginalArrivalTime: 05 Feb 2002 06:23:45.0632 (UTC) FILETIME=[AA325E00:01C1AE0D]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id BAA05402
Sender: nsis-admin@ietf.org
Errors-To: nsis-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Next Steps in Signaling <nsis.ietf.org>
X-BeenThere: nsis@ietf.org
Content-Transfer-Encoding: 8bit

Hi Tricci,

> Sorry for taking me so long to plug into the NSIS mailing 
> list discussion. It is not easy to keep up with the IETF work 
> when there are other responsibilities within the company.

I think most of us can agree to that!

> 1. Although information is good, but too much information 
> sometimes will digress the real intent of the document.  May I 
> suggest to move the service application scenarios to the appendix 
> since it seems to be the common approach for most of the IETF draft.  
> So that audience can focus on the scope and requirements discussions.

I strongly agree.  I think the appendix is an appropriate place.

> 2. Is the QoS Initiator MUST always interact directly with 
> QoS Controller? I hope not that this is NOT the intent.

I think that the requirement should say that this MUST be supported.
By supporting it, it means that the protocol would allow this to
happen, but not require it to happen.

> 3. In term of the organization of the requirements, as it has 
> been suggested in section 4.2 that NSIS signaling could run end-to-end, 
> end-to-edge, edge-to-edge or network-to-network.  I am wondering that if 
> the requirements can be organized in such a way as
> - general requirements
> - end-to-edge signaling requirements for certain service applications 
> - edge-to-edge signaling requirements
> - network-to-network signaling requirements
> 
> I thought that it may help to make the document more readable 
> since there are a lot of detailed requirements group together in a single 
> section.   It is easier to identify which requirement is applicable to 
> which part of the network.

I think that would be useful as well.

> 4. Also, since the goal is to re-use existing protocols as 
> much as possible, I thought it may be a good idea to create a table of how 
> certain existing signaling protocol satisfies the given set of requirements in 
> each of the segment listed above.  By doing this exercise, it is much 
> easier to examine what are missing in the current signaling protocols.

Actually, our second work item is to produce a draft on
analysing existing protocols, so you suggest will most likely
be contained there.

thanks for your comments,
John

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



From daemon@optimus.ietf.org  Tue Feb  5 08:50: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 IAA29766
	for <nsis-archive@odin.ietf.org>; Tue, 5 Feb 2002 08:50:11 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id IAA29375
	for nsis-archive@odin.ietf.org; Tue, 5 Feb 2002 08:50:14 -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 IAA29061;
	Tue, 5 Feb 2002 08:40: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 IAA29030
	for <nsis@optimus.ietf.org>; Tue, 5 Feb 2002 08:40:19 -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 IAA29402
	for <nsis@ietf.org>; Tue, 5 Feb 2002 08:40:15 -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 g15DeNj93865;
	Tue, 5 Feb 2002 14:40:23 +0100 (CET)
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 07E3BC05B; Tue,  5 Feb 2002 14:39:36 +0100 (CET)
Date: Tue, 05 Feb 2002 14:51:45 +0100
From: Marcus Brunner <brunner@ccrle.nec.de>
Reply-To: brunner@ccrle.nec.de
To: Tricci So <tso@caspiannetworks.com>
Cc: nsis@ietf.org
Subject: Re: [NSIS] Working Group Requirements document
Message-ID: <15959328.1012920705@[192.168.102.79]>
In-Reply-To: <3C5F6B48.97A6A980@caspiannetworks.com>
References: <0C1353ABB1DEB74DB067ADFF749C4EEF09BC8E@esebe004.NOE.Nokia.com>
 <3C5F6B48.97A6A980@caspiannetworks.com>
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 <nsis.ietf.org>
X-BeenThere: nsis@ietf.org
Content-Transfer-Encoding: 7bit

Tricci,

--On Monday, February 04, 2002 9:19 PM -0800 Tricci So 
<tso@caspiannetworks.com> wrote:

> Hi John et al,
>
> Sorry for taking me so long to plug into the NSIS mailing list discussion.
> It is not easy to keep up with the IETF work when there are other
> responsibilities within the company.
>
> Anyway, I truly appreciate all the hard work that been done to put
> together the NSIS requirements draft.  I have quicky read through it.  It
> is very comprehensive.  However, I do have some requests on the current
> format and contents........
>
> 1. Although information is good, but too much information sometimes will
> digress the real intent of the document.  May I suggest to move the
> service application scenarios to the appendix since it seems to be the
> common approach for most of the IETF draft.  So that audience can focus
> on the scope and requirements discussions.
>

IMO the need to be rewritten a bit to more cover use cases as sugested by 
somebody else on the list.

> 3. In term of the organization of the requirements, as it has been
> suggested in section 4.2 that NSIS signaling could run end-to-end,
> end-to-edge, edge-to-edge or network-to-network.  I am wondering that if
> the requirements can be organized in such a way as
> - general requirements
> - end-to-edge signaling requirements for certain service applications -
> edge-to-edge signaling requirements
> - network-to-network signaling requirements
>
> I thought that it may help to make the document more readable since there
> are a lot of detailed requirements group together in a single section.
> It is easier to identify which requirement is applicable to which part of
> the network.
>

Other opinions? We tried to group them contextwise not where in the network 
they apply.

> 4. Also, since the goal is to re-use existing protocols as much as
> possible, I thought it may be a good idea to create a table of how
> certain existing signaling protocol satisfies the given set of
> requirements in each of the segment listed above.  By doing this
> exercise, it is much easier to examine what are missing in the current
> signaling protocols.
>

I think this needs to be done at a later stage, when deciding how to go on.

> B.T.W. The comparison can be resided in the appendix as well.
>
> Truly thank you for such a great work.  I will also like to participate in
> the conference call if one is available.
>

Welcome, thanks for you help.

Marcus

> Cheers,
> Tricci
>
> john.loughney@nokia.comou  wrote:
>
>> Hi all,
>>
>> There have several requests that the following document be made
>> a working group document:
>>
>> http://search.ietf.org/internet-drafts/draft-brunner-nsis-req-00.txt
>>
>> After discussing with our Area Directors, we have asked Marcus Brunner
>> to edit the Signaling Requirements draft, with the above draft
>> forming the basis of initial draft.
>>
>> I would like to see if there is interest within the working group to
>> have a conference call in order to help progress the work on this draft.
>>
>> best regards,
>> 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
>



--------------------------------------
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  Tue Feb  5 09:08: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 JAA00154
	for <nsis-archive@odin.ietf.org>; Tue, 5 Feb 2002 09:08:58 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id JAA00194
	for nsis-archive@odin.ietf.org; Tue, 5 Feb 2002 09:09: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 JAA00155;
	Tue, 5 Feb 2002 09:07: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 JAA00123
	for <nsis@optimus.ietf.org>; Tue, 5 Feb 2002 09:07:36 -0500 (EST)
Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00076
	for <nsis@ietf.org>; Tue, 5 Feb 2002 09:07:33 -0500 (EST)
Received: (from sob@localhost)
	by newdev.harvard.edu (8.10.2/8.10.2) id g15E7ZS26334;
	Tue, 5 Feb 2002 09:07:35 -0500 (EST)
Date: Tue, 5 Feb 2002 09:07:35 -0500 (EST)
From: Scott  Bradner <sob@harvard.edu>
Message-Id: <200202051407.g15E7ZS26334@newdev.harvard.edu>
To: tso@caspiannetworks.com
Subject: Re: [NSIS] Working Group Requirements document
Cc: nsis@ietf.org
Sender: nsis-admin@ietf.org
Errors-To: nsis-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Next Steps in Signaling <nsis.ietf.org>
X-BeenThere: nsis@ietf.org

> 4. Also, since the goal is to re-use existing protocols as much as possible,
> I thought it may be a good idea to create a table of how certain existing
> signaling protocol satisfies the given set of requirements in each of the
> segment listed above.  By doing this exercise, it is much easier to examine
> what are missing in the current signaling protocols.

I don't this should be in the requirements documen, which should focus
(strangly enough) on requirements not solutions

Scott

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



From daemon@optimus.ietf.org  Tue Feb  5 09:25: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 JAA00754
	for <nsis-archive@odin.ietf.org>; Tue, 5 Feb 2002 09:25:58 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id JAA01053
	for nsis-archive@odin.ietf.org; Tue, 5 Feb 2002 09:26: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 JAA00461;
	Tue, 5 Feb 2002 09:15: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 JAA00430
	for <nsis@optimus.ietf.org>; Tue, 5 Feb 2002 09:15:55 -0500 (EST)
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 JAA00379
	for <nsis@ietf.org>; Tue, 5 Feb 2002 09:15:46 -0500 (EST)
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.1.0/Switch-2.1.0) with ESMTP id g15EFpi04340
	for <nsis@ietf.org>; Tue, 5 Feb 2002 16:15:52 +0200 (EET)
Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T58e37cd7f9ac158f21081@esvir01nok.ntc.nokia.com>;
 Tue, 5 Feb 2002 16:15:31 +0200
Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779);
	 Tue, 5 Feb 2002 16:15:31 +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] Working Group Requirements document
Date: Tue, 5 Feb 2002 16:15:31 +0200
Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF5D959A@esebe004.NOE.Nokia.com>
Thread-Topic: [NSIS] Working Group Requirements document
Thread-Index: AcGuT2soIYge9m4+Ro+WOw4uB1Hn3AAABJPA
To: <sob@harvard.edu>
Cc: <nsis@ietf.org>
X-OriginalArrivalTime: 05 Feb 2002 14:15:31.0747 (UTC) FILETIME=[91F4BF30:01C1AE4F]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id JAA00431
Sender: nsis-admin@ietf.org
Errors-To: nsis-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Next Steps in Signaling <nsis.ietf.org>
X-BeenThere: nsis@ietf.org
Content-Transfer-Encoding: 8bit

Hi Scott,

> > 4. Also, since the goal is to re-use existing protocols as 
> much as possible,
> > I thought it may be a good idea to create a table of how 
> certain existing
> > signaling protocol satisfies the given set of requirements 
> in each of the
> > segment listed above.  By doing this exercise, it is much 
> easier to examine
> > what are missing in the current signaling protocols.
> 
> I don't this should be in the requirements documen, which should focus
> (strangly enough) on requirements not solutions

Agreed - I think that I mentioned that we have a seperate WG 
document for this.

John

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



From daemon@ns.ietf.org  Tue Feb  5 13:33: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 NAA12752
	for <nsis-archive@odin.ietf.org>; Tue, 5 Feb 2002 13:33:07 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id NAA24195
	for nsis-archive@odin.ietf.org; Tue, 5 Feb 2002 13:33: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 NAA22834;
	Tue, 5 Feb 2002 13:16: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 NAA22804
	for <nsis@ns.ietf.org>; Tue, 5 Feb 2002 13:16:04 -0500 (EST)
Received: from aifhs8.alcatel.fr (una200.alcatel.fr [212.208.74.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11823
	for <nsis@ietf.org>; Tue, 5 Feb 2002 13:16:02 -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 TAA27637;
        Tue, 5 Feb 2002 19:15:28 +0100 (MET)
Received: from alcatel.fr ([139.54.208.95])
          by frmail30.netfr.alcatel.fr (Lotus Domino Release 5.0.6a)
          with ESMTP id 2002020519152711:4855 ;
          Tue, 5 Feb 2002 19:15:27 +0100 
Message-ID: <3C6021BE.E9D3773D@alcatel.fr>
Date: Tue, 05 Feb 2002 19:17:34 +0100
Organization: Alcatel
X-Mailer: Mozilla 4.78 [fr] (Windows NT 5.0; U)
X-Accept-Language: fr
MIME-Version: 1.0
To: john.loughney@nokia.com
CC: nsis@ietf.org
Subject: Re: [NSIS] Working Group Requirements document
References: <0C1353ABB1DEB74DB067ADFF749C4EEF09BC8E@esebe004.NOE.Nokia.com>
X-MIMETrack: Itemize by SMTP Server on FRMAIL30/FR/ALCATEL(Release 5.0.6a |January 17, 2001) at
 02/05/2002 19:15:27,
	Serialize by Router on FRMAIL30/FR/ALCATEL(Release 5.0.6a |January 17, 2001) at
 02/05/2002 19:15:27,
	Serialize complete at 02/05/2002 19:15:27
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
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 <nsis.ietf.org>
X-BeenThere: nsis@ietf.org
Content-Transfer-Encoding: 7bit



> I would like to see if there is interest within the working group to
> have a conference call in order to help progress the work on this draft.


John,

I am also interested in participating in the conference call.

Best regards,

-- 
Alban Couturier

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



From daemon@optimus.ietf.org  Wed Feb  6 11:15: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 LAA24834
	for <nsis-archive@odin.ietf.org>; Wed, 6 Feb 2002 11:15:18 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id LAA10645
	for nsis-archive@odin.ietf.org; Wed, 6 Feb 2002 11:15: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 LAA10531;
	Wed, 6 Feb 2002 11:12: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 LAA10499
	for <nsis@optimus.ietf.org>; Wed, 6 Feb 2002 11:12:29 -0500 (EST)
Received: from zcars0m9.ca.nortel.com (zcars0m9.nortelnetworks.com [47.129.242.157])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24743
	for <nsis@ietf.org>; Wed, 6 Feb 2002 11:12:25 -0500 (EST)
Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57])
	by zcars0m9.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g16GBuH19941;
	Wed, 6 Feb 2002 11:11: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 g16GBt325902;
	Wed, 6 Feb 2002 11:11:55 -0500 (EST)
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19)
	id <1J339938>; Wed, 6 Feb 2002 11:11:56 -0500
Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA47FF@zcard031.ca.nortel.com>
From: "Gary Kenward"<gkenward@nortelnetworks.com>
To: "'john.loughney@nokia.com'" <john.loughney@nokia.com>, nsis@ietf.org
Subject: RE: [NSIS] Working Group Requirements document
Date: Wed, 6 Feb 2002 11:11:57 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C1AF29.0000B1D0"
Sender: nsis-admin@ietf.org
Errors-To: nsis-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Next Steps in Signaling <nsis.ietf.org>
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_01C1AF29.0000B1D0
Content-Type: text/plain;
	charset="iso-8859-1"

John:

 If there is still room on the conference bridge, I would like to 
participate.

Cheers,
Gary

> -----Original Message-----
> From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]
> Sent: February 4, 2002 03:24
> To: nsis@ietf.org
> Subject: [NSIS] Working Group Requirements document
> 
> 
> Hi all,
> 
> There have several requests that the following document be made
> a working group document:
> 
> http://search.ietf.org/internet-drafts/draft-brunner-nsis-req-00.txt
> 
> After discussing with our Area Directors, we have asked Marcus Brunner
> to edit the Signaling Requirements draft, with the above draft
> forming the basis of initial draft. 
> 
> I would like to see if there is interest within the working group to
> have a conference call in order to help progress the work on 
> this draft.
> 
> best regards,
> John
> 
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis
> 

------_=_NextPart_001_01C1AF29.0000B1D0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>RE: [NSIS] Working Group Requirements document</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>John:</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;If there is still room on the conference =
bridge, I would like to </FONT>
<BR><FONT SIZE=3D2>participate.</FONT>
</P>

<P><FONT SIZE=3D2>Cheers,</FONT>
<BR><FONT SIZE=3D2>Gary</FONT>
</P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: john.loughney@nokia.com [<A =
HREF=3D"mailto:john.loughney@nokia.com">mailto:john.loughney@nokia.com</=
A>]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: February 4, 2002 03:24</FONT>
<BR><FONT SIZE=3D2>&gt; To: nsis@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: [NSIS] Working Group Requirements =
document</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Hi all,</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; There have several requests that the following =
document be made</FONT>
<BR><FONT SIZE=3D2>&gt; a working group document:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; <A =
HREF=3D"http://search.ietf.org/internet-drafts/draft-brunner-nsis-req-00=
.txt" =
TARGET=3D"_blank">http://search.ietf.org/internet-drafts/draft-brunner-n=
sis-req-00.txt</A></FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; After discussing with our Area Directors, we =
have asked Marcus Brunner</FONT>
<BR><FONT SIZE=3D2>&gt; to edit the Signaling Requirements draft, with =
the above draft</FONT>
<BR><FONT SIZE=3D2>&gt; forming the basis of initial draft. </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I would like to see if there is interest within =
the working group to</FONT>
<BR><FONT SIZE=3D2>&gt; have a conference call in order to help =
progress the work on </FONT>
<BR><FONT SIZE=3D2>&gt; this draft.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; best regards,</FONT>
<BR><FONT SIZE=3D2>&gt; John</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; =
_______________________________________________</FONT>
<BR><FONT SIZE=3D2>&gt; nsis mailing list</FONT>
<BR><FONT SIZE=3D2>&gt; nsis@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; <A =
HREF=3D"https://www1.ietf.org/mailman/listinfo/nsis" =
TARGET=3D"_blank">https://www1.ietf.org/mailman/listinfo/nsis</A></FONT>=

<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1AF29.0000B1D0--

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



From daemon@ns.ietf.org  Mon Feb 11 05:46: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 FAA27971
	for <nsis-archive@odin.ietf.org>; Mon, 11 Feb 2002 05:46:04 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id FAA00159
	for nsis-archive@odin.ietf.org; Mon, 11 Feb 2002 05:46: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 FAA00087;
	Mon, 11 Feb 2002 05:44: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 FAA00056
	for <nsis@ns.ietf.org>; Mon, 11 Feb 2002 05:44:46 -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 FAA27955
	for <nsis@ietf.org>; Mon, 11 Feb 2002 05:44:42 -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.1.0/Switch-2.1.0) with ESMTP id g1BAiJ307113
	for <nsis@ietf.org>; Mon, 11 Feb 2002 12:44:19 +0200 (EET)
Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T5901a2012dac158f25077@esvir05nok.ntc.nokia.com> for <nsis@ietf.org>;
 Mon, 11 Feb 2002 12:44:43 +0200
Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779);
	 Mon, 11 Feb 2002 12:44:43 +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"
Date: Mon, 11 Feb 2002 12:44:43 +0200
Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF09BCA9@esebe004.NOE.Nokia.com>
Thread-Topic: [NSIS] Working Group Requirements document
Thread-Index: AcGuT2soIYge9m4+Ro+WOw4uB1Hn3AAABJPAASZAvZA=
To: <nsis@ietf.org>
X-OriginalArrivalTime: 11 Feb 2002 10:44:43.0318 (UTC) FILETIME=[1D622560:01C1B2E9]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id FAA00057
Subject: [NSIS] Update on Conference Call
Sender: nsis-admin@ietf.org
Errors-To: nsis-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Next Steps in Signaling <nsis.ietf.org>
X-BeenThere: nsis@ietf.org
Content-Transfer-Encoding: 8bit

Hi all,

I didn't mean to kill discussion on the mailing list, by checking
to see if there is interest in a conference call.  

Currently, there is interest in having a call, but I don't see 
much which needs to be discussed.  Generally, a conference call
can be helpful to resolve issues which are difficult to resolve
on the mailing list.

Currently, I assume that Marcus is diligently updating the 
requirements document.  There have been a couple of comments
on the mailing list on the draft, but without any burning 
issues, it is probably premature to schedule a conference 
call.

best regards,
John

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



From daemon@ns.ietf.org  Mon Feb 11 05:50: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 FAA28016
	for <nsis-archive@odin.ietf.org>; Mon, 11 Feb 2002 05:50:58 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id FAA00396
	for nsis-archive@odin.ietf.org; Mon, 11 Feb 2002 05:51: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 FAA00265;
	Mon, 11 Feb 2002 05:46:59 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA00227
	for <nsis@ns.ietf.org>; Mon, 11 Feb 2002 05:46:57 -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 FAA27992
	for <nsis@ietf.org>; Mon, 11 Feb 2002 05:46:53 -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.1.0/Switch-2.1.0) with ESMTP id g1BAkU308032
	for <nsis@ietf.org>; Mon, 11 Feb 2002 12:46:30 +0200 (EET)
Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T5901a4020eac158f25077@esvir05nok.ntc.nokia.com> for <nsis@ietf.org>;
 Mon, 11 Feb 2002 12:46:54 +0200
Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779);
	 Mon, 11 Feb 2002 12:46:54 +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"
Date: Mon, 11 Feb 2002 12:46:54 +0200
Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64839@esebe004.NOE.Nokia.com>
Thread-Topic: [NSIS] Working Group Requirements document
Thread-Index: AcGuT2soIYge9m4+Ro+WOw4uB1Hn3AAABJPAASZsqbA=
To: <nsis@ietf.org>
X-OriginalArrivalTime: 11 Feb 2002 10:46:54.0765 (UTC) FILETIME=[6BBB5DD0:01C1B2E9]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id FAA00228
Subject: [NSIS] IETF 53 Meeting time
Sender: nsis-admin@ietf.org
Errors-To: nsis-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Next Steps in Signaling <nsis.ietf.org>
X-BeenThere: nsis@ietf.org
Content-Transfer-Encoding: 8bit

Hi all,

Currently, NSIS is scheduled for Friday.  My feeling is that 
most of the time should be used for discussion of the
requirements.

FRIDAY, March 22, 2002
0800-1000 IETF Registration - 
0800-0900 Continental Breakfast - 
0900-1130 Morning Sessions

best regards,
John

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



From daemon@optimus.ietf.org  Mon Feb 11 12:16: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 MAA11178
	for <nsis-archive@odin.ietf.org>; Mon, 11 Feb 2002 12:16:36 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id MAA22032
	for nsis-archive@odin.ietf.org; Mon, 11 Feb 2002 12:16: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 MAA21691;
	Mon, 11 Feb 2002 12:09: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 MAA21660
	for <nsis@optimus.ietf.org>; Mon, 11 Feb 2002 12:09:05 -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 MAA10646
	for <nsis@ietf.org>; Mon, 11 Feb 2002 12:09:01 -0500 (EST)
Received: from sbctri.tri.sbc.com (sbctri [144.60.1.10])
	by howler.tri.sbc.com (8.11.0/8.11.0) with ESMTP id g1BHBFT18445;
	Mon, 11 Feb 2002 11:11:15 -0600 (CST)
Received: from TRIMAIL2.ad.tri.sbc.com (localhost [127.0.0.1])
	by sbctri.tri.sbc.com (8.11.0/8.9.3) with ESMTP id g1BH8N123936;
	Mon, 11 Feb 2002 11:08:23 -0600 (CST)
Received: by TRIMAIL2.ad.tri.sbc.com with Internet Mail Service (5.5.2653.19)
	id <1R9SR4M4>; Mon, 11 Feb 2002 11:08:53 -0600
Message-ID: <905A1C4ABF353F4C8CC16FA9F53DD0D638B9E8@TRIMAIL2.ad.tri.sbc.com>
From: "Schneider, Marco" <schneider@tri.sbc.com>
To: "'john.loughney@nokia.com'" <john.loughney@nokia.com>, nsis@ietf.org
Subject: RE: [NSIS] Update on Conference Call
Date: Mon, 11 Feb 2002 11:08:43 -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 <nsis.ietf.org>
X-BeenThere: nsis@ietf.org

John,

I have been off doing some of the other things that pay the bills and I
suspect that may be the case for others as well. In my opinion there is
definitely still a lot to discuss. I will throw in some issues and comments
by end of week.

Marco

> -----Original Message-----
> From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]
> Sent: Monday, February 11, 2002 4:45 AM
> To: nsis@ietf.org
> Subject: [NSIS] Update on Conference Call
> 
> 
> Hi all,
> 
> I didn't mean to kill discussion on the mailing list, by checking
> to see if there is interest in a conference call.  
> 
> Currently, there is interest in having a call, but I don't see 
> much which needs to be discussed.  Generally, a conference call
> can be helpful to resolve issues which are difficult to resolve
> on the mailing list.
> 
> Currently, I assume that Marcus is diligently updating the 
> requirements document.  There have been a couple of comments
> on the mailing list on the draft, but without any burning 
> issues, it is probably premature to schedule a conference 
> call.
> 
> best regards,
> 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  Tue Feb 12 04:56: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 EAA07011
	for <nsis-archive@odin.ietf.org>; Tue, 12 Feb 2002 04:56:28 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id EAA11786
	for nsis-archive@odin.ietf.org; Tue, 12 Feb 2002 04:56: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 EAA11667;
	Tue, 12 Feb 2002 04:51: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 EAA11644
	for <nsis@optimus.ietf.org>; Tue, 12 Feb 2002 04:51:37 -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 EAA06962
	for <nsis@ietf.org>; Tue, 12 Feb 2002 04:51:34 -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 g1C9pkj35387;
	Tue, 12 Feb 2002 10:51:46 +0100 (CET)
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 0F8A2C040; Tue, 12 Feb 2002 10:50:54 +0100 (CET)
Date: Tue, 12 Feb 2002 11:03:14 +0100
From: Marcus Brunner <brunner@ccrle.nec.de>
Reply-To: brunner@ccrle.nec.de
To: john.loughney@nokia.com, nsis@ietf.org
Subject: Re: [NSIS] Update on Conference Call
Message-ID: <3229884.1013511794@[192.168.102.79]>
In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEF09BCA9@esebe004.NOE.Nokia.com>
References:  <0C1353ABB1DEB74DB067ADFF749C4EEF09BCA9@esebe004.NOE.Nokia.com>
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 <nsis.ietf.org>
X-BeenThere: nsis@ietf.org
Content-Transfer-Encoding: 7bit

Yes I am updating the draft (but so far not diligently :-)
Marcus

--On Monday, February 11, 2002 12:44 PM +0200 john.loughney@nokia.com wrote:

> Hi all,
>
> I didn't mean to kill discussion on the mailing list, by checking
> to see if there is interest in a conference call.
>
> Currently, there is interest in having a call, but I don't see
> much which needs to be discussed.  Generally, a conference call
> can be helpful to resolve issues which are difficult to resolve
> on the mailing list.
>
> Currently, I assume that Marcus is diligently updating the
> requirements document.  There have been a couple of comments
> on the mailing list on the draft, but without any burning
> issues, it is probably premature to schedule a conference
> call.
>
> best regards,
> John
>
> _______________________________________________
> 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 Feb 14 10:28: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 KAA24160
	for <nsis-archive@odin.ietf.org>; Thu, 14 Feb 2002 10:28:44 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id KAA03505
	for nsis-archive@odin.ietf.org; Thu, 14 Feb 2002 10:28: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 KAA03306;
	Thu, 14 Feb 2002 10:23: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 KAA03275
	for <nsis@optimus.ietf.org>; Thu, 14 Feb 2002 10:23:04 -0500 (EST)
Received: from penguin-ext.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 KAA24025
	for <nsis@ietf.org>; Thu, 14 Feb 2002 10:22:59 -0500 (EST)
Received: from mbb5.ericsson.se (mbb5.ericsson.se [136.225.151.210])
	by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id g1EFMVB09559
	for <nsis@ietf.org>; Thu, 14 Feb 2002 16:22:31 +0100 (MET)
Received: from there (lm6068.lmera.ericsson.se [150.132.106.68])
 by mbb1.ericsson.se (PMDF V5.2-29 #39352)
 with SMTP id <0GRJ00HDD41HDS@mbb1.ericsson.se> for nsis@ietf.org; Thu,
 14 Feb 2002 16:22:31 +0100 (MET)
Date: Thu, 14 Feb 2002 16:22:29 +0100
From: David Partain <David.Partain@ericsson.com>
To: NSIS Mailing List <nsis@ietf.org>
Reply-to: David.Partain@ericsson.com
Message-id: <0GRJ00HDG41JDS@mbb1.ericsson.se>
MIME-version: 1.0
X-Mailer: KMail [version 1.3.2]
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 8bit
Content-Transfer-Encoding: 8bit
Subject: [NSIS] Draft submitted:  draft-partain-nsis-requirements-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 <nsis.ietf.org>
X-BeenThere: nsis@ietf.org
Content-Transfer-Encoding: 8bit

Greetings,

I just sent the following to the Internet Drafts people.

  "Please find attached draft-partain-nsis-requirements-00.txt.
   This is not the product of an IETF Working Group, although it
   is written specifically with the NSIS Working Group in mind.

   Title     : NSIS QoS Signalling Requirements
   Author(s) : D. Partain, A. Bergsten, M. Greis, G. Karagiannis,
               J. Manner, J. Murphy, P. Pan, V. Rexhepi,
               L.  Westberg, H. Zheng
   Filename  : draft-partain-nsis-requirements-00.txt
   Pages     : 30
   Date      : February 2002

   This memo identifies a set of requirements that must be
   applied to the development of the NSIS quality of service
   (QoS) signalling protocol.  These requirements are based upon
   the needs of various kinds of applications that will utilize
   IP networks and need to be able to signal their QoS needs."

I won't belabor the mailing list by attaching a copy of the
draft to this mail, but if you're interested in having a
look at it before the ID people get it out, you'll find it
at http://standards.ericsson.net/partain

In addition, so you'll know what we've been up to, you'll find
all of the versions of the document up to this submission,
warts and all, as well as a list of what we consider to be
open issues with this document.

Before anyone shouts at me, I realize that John has selected
Marcus Brunner's document as the foundation for the WG's
requirements draft.  The authors above were already close to
finished with this document when that announcement was made, so
it only made sense to complete the document for the WG's review.
We, of course, hope that it will move the discussion forward.

Looking forward to your comments.

Cheers,

David Partain

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



From daemon@optimus.ietf.org  Sun Feb 17 21:32: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 VAA14663
	for <nsis-archive@odin.ietf.org>; Sun, 17 Feb 2002 21:32:58 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id VAA12297
	for nsis-archive@odin.ietf.org; Sun, 17 Feb 2002 21:33:02 -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 VAA11735;
	Sun, 17 Feb 2002 21:28:56 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA11703
	for <nsis@optimus.ietf.org>; Sun, 17 Feb 2002 21:28:54 -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 VAA14601
	for <nsis@ietf.org>; Sun, 17 Feb 2002 21:28:50 -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 g1I2TEj88228;
	Mon, 18 Feb 2002 03:29:14 +0100 (CET)
Received: by citadel.mobility.ccrle.nec.de (Postfix on SuSE eMail Server 2.0, from userid 30)
	id 3E866C05C; Mon, 18 Feb 2002 03:28:17 +0100 (CET)
To: David.Partain@ericsson.com, David Partain <David.Partain@ericsson.com>
Subject: Re: [NSIS] Draft submitted:  draft-partain-nsis-requirements-00.txt
Message-ID: <1013999297.3c7066c130462@citadel.mobility.ccrle.nec.de>
Date: Mon, 18 Feb 2002 03:28:17 +0100 (CET)
From: Marcus Brunner <brunner@ccrle.nec.de>
Cc: NSIS Mailing List <nsis@ietf.org>
References: <0GRJ00HDG41JDS@mbb1.ericsson.se>
In-Reply-To: <0GRJ00HDG41JDS@mbb1.ericsson.se>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
User-Agent: IMP/PHP IMAP webmail program 2.2.3
X-Originating-IP: 192.168.102.83
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 <nsis.ietf.org>
X-BeenThere: nsis@ietf.org
Content-Transfer-Encoding: 8bit

I thank David and his co-authors for the draft. It really helps to have the 
ideas of people on "virtual" paper. 

Comments, question etc. are coming in different mails.
Marcus



Zitiere David Partain <David.Partain@ericsson.com>:

> Before anyone shouts at me, I realize that John has selected
> Marcus Brunner's document as the foundation for the WG's
> requirements draft.  The authors above were already close to
> finished with this document when that announcement was made, so
> it only made sense to complete the document for the WG's review.
> We, of course, hope that it will move the discussion forward.
> 
> Looking forward to your comments.
> 
> Cheers,
> 
> David Partain
> 
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis
> 
> 



-------
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  Sun Feb 17 21:35: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 VAA15393
	for <nsis-archive@odin.ietf.org>; Sun, 17 Feb 2002 21:35:01 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id VAA12369
	for nsis-archive@odin.ietf.org; Sun, 17 Feb 2002 21:35: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 VAA11687;
	Sun, 17 Feb 2002 21:28:22 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA11655
	for <nsis@optimus.ietf.org>; Sun, 17 Feb 2002 21:28:20 -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 VAA14597
	for <nsis@ietf.org>; Sun, 17 Feb 2002 21:28:15 -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 g1I2Sij88224
	for <nsis@ietf.org>; Mon, 18 Feb 2002 03:28:44 +0100 (CET)
Received: by citadel.mobility.ccrle.nec.de (Postfix on SuSE eMail Server 2.0, from userid 30)
	id 0A242C05C; Mon, 18 Feb 2002 03:27:40 +0100 (CET)
To: NSIS Mailing List <nsis@ietf.org>
Message-ID: <1013999259.3c70669bf0f89@citadel.mobility.ccrle.nec.de>
Date: Mon, 18 Feb 2002 03:27:39 +0100 (CET)
From: Marcus Brunner <brunner@ccrle.nec.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
User-Agent: IMP/PHP IMAP webmail program 2.2.3
X-Originating-IP: 192.168.102.83
Content-Transfer-Encoding: 8bit
Subject: [NSIS] Scenario for IP telephony
Sender: nsis-admin@ietf.org
Errors-To: nsis-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Next Steps in Signaling <nsis.ietf.org>
X-BeenThere: nsis@ietf.org
Content-Transfer-Encoding: 8bit

I have shortly looked it over David and Co´s draft and found the scenario on 
QoS signaling between PSTN gateways and backbone routers particularly 
interesting.

However IMHO the scenario could be broadend to something like "IP telephony 
signaling server to network QoS signaling" not only including PSTN signaling 
servers, but SIP servers as well. Opinions?

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  Mon Feb 18 11:15: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 LAA06755
	for <nsis-archive@odin.ietf.org>; Mon, 18 Feb 2002 11:15:56 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id LAA27515
	for nsis-archive@odin.ietf.org; Mon, 18 Feb 2002 11:16: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 LAA27162;
	Mon, 18 Feb 2002 11:10:48 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA27129
	for <nsis@optimus.ietf.org>; Mon, 18 Feb 2002 11:10:46 -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 LAA06303;
	Mon, 18 Feb 2002 11:10:41 -0500 (EST)
Message-Id: <200202181610.LAA06303@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, 18 Feb 2002 11:10:41 -0500
Subject: [NSIS] I-D ACTION:draft-partain-nsis-requirements-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 <nsis.ietf.org>
X-BeenThere: nsis@ietf.org

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: NSIS QoS Signalling Requirements
	Author(s)	: D. Partain et al.
	Filename	: draft-partain-nsis-requirements-00.txt
	Pages		: 30
	Date		: 15-Feb-02
	
This memo identifies a set of requirements that must be applied to
the development of the NSIS quality of service (QoS) signalling
protocol.  These requirements are based upon the needs of various
kinds of applications that will utilize IP networks and need to be
able to signal their QoS needs

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-partain-nsis-requirements-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-partain-nsis-requirements-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-partain-nsis-requirements-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:	<20020215100647.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-partain-nsis-requirements-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-partain-nsis-requirements-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20020215100647.I-D@ietf.org>

--OtherAccess--

--NextPart--



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



From daemon@optimus.ietf.org  Mon Feb 18 15:18: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 PAA16704
	for <nsis-archive@odin.ietf.org>; Mon, 18 Feb 2002 15:18:59 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id PAA09716
	for nsis-archive@odin.ietf.org; Mon, 18 Feb 2002 15:19: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 PAA09519;
	Mon, 18 Feb 2002 15:17: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 PAA09486
	for <nsis@optimus.ietf.org>; Mon, 18 Feb 2002 15:17:51 -0500 (EST)
Received: from yahoo.com (nas1.bec.com.eg [163.121.112.37] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA16639
	for <nsis@ietf.org>; Mon, 18 Feb 2002 15:17:07 -0500 (EST)
From: youcherry@yahoo.com
Message-Id: <200202182017.PAA16639@ietf.org>
Reply-To: youcherry@yahoo.com
To: nsis@ietf.org
Date: 18 Feb 2002 20:49:58 GMT
MIME-Version: 1.0
Content-Type: text/html; charset=US-ASCII
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit
Subject: [NSIS] Take me.
Sender: nsis-admin@ietf.org
Errors-To: nsis-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Next Steps in Signaling <nsis.ietf.org>
X-BeenThere: nsis@ietf.org
Content-Transfer-Encoding: 8bit

<table width="400" border="0" bgcolor="#FF66CC" align="center">
  <tr>
    <td align="center">
      <p><font face="Verdana, Arial, Helvetica, sans-serif" size="5"><br>
        Can you break my cherry?</font></p>
      <p><font face="Verdana, Arial, Helvetica, sans-serif"><a href="http://nearly19.com/?r=taboo&p=e"><b>Click
        Here and give it a try...</b></a><br>
        <br>
        <br>
        </font> </p>
      </td>
  </tr>
</table>
<p align="center"><i>Little sluts are waiting for your big dick!<br>
  What are you waiting for?</i></p>
<p align="center"><font size="5" face="Arial, Helvetica, sans-serif"><b><a href="http://nearly19.com/?r=taboo&p=e">  HERE</a></b></font></p>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br><br><br><br>
<hr size="1">
<font face="Arial, Helvetica" size="1">Note: this is not a spam email. This email
was sent to you because your email was entered in on a website requesting to be
a registered subscriber. If you did not request this email, please just answer on this mail.<br>
</font><br><br>

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



From daemon@optimus.ietf.org  Tue Feb 19 10:42: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 KAA24401
	for <nsis-archive@odin.ietf.org>; Tue, 19 Feb 2002 10:42:48 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id KAA13532
	for nsis-archive@odin.ietf.org; Tue, 19 Feb 2002 10:42: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 KAA13432;
	Tue, 19 Feb 2002 10:40: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 KAA13407
	for <nsis@optimus.ietf.org>; Tue, 19 Feb 2002 10:40:40 -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 KAA24341
	for <nsis@ietf.org>; Tue, 19 Feb 2002 10:40:38 -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.1.0/Switch-2.1.0) with ESMTP id g1JFerQ22130
	for <nsis@ietf.org>; Tue, 19 Feb 2002 09:40:54 -0600 (CST)
Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T592a2c4889ac12f254079@davir01nok.americas.nokia.com> for <nsis@ietf.org>;
 Tue, 19 Feb 2002 09:40:34 -0600
Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Tue, 19 Feb 2002 09:40:34 -0600
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C1B95B.C4B98924"
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
Date: Tue, 19 Feb 2002 10:40:33 -0500
Message-ID: <E320A8529CF07E4C967ECC2F380B0CF94F57C0@bsebe001.NOE.Nokia.com>
Thread-Topic: Few comments on draft-brunner-nsis-req-00.txt
Thread-Index: AcG5W8QfKRG/dQpxSQO0XZsc344uCw==
To: <nsis@ietf.org>
X-OriginalArrivalTime: 19 Feb 2002 15:40:34.0509 (UTC) FILETIME=[C538EFD0:01C1B95B]
Subject: [NSIS] Few comments on draft-brunner-nsis-req-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 <nsis.ietf.org>
X-BeenThere: nsis@ietf.org

This is a multi-part message in MIME format.

------_=_NextPart_001_01C1B95B.C4B98924
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi:
=20
I understand that the authors are in process of revising the above =
draft. I would like to provide few comments that may be considered =
during the revision process. Thanks.
=20
Hemant
=20
-----
=20
=20
Section 2. Terminology:
=20
[QoS] Domain: I think this should be called [Administrative] domain, as =
the definition has no relation to the uniformity of QoS technology (as =
with the definition of QoS subdomain) of the domain, rather it is based =
on administrative uniformity.
=20
Section 3.1, items 1) Handoff decision and 2) Trigger sources:
=20
The handoff decision and trigger sources should be out of scope of NSIS. =
NSIS should rather focus only on "establishing" QoS along the packet =
path after handoff. The handoff decision and triggers should be left to =
mobility management protocols to consider.
=20
Also, all the scenarios (at least end host oriented) in this section are =
somehow related to mobile terminals. There is a lack of other scenarios, =
such as say scenarios with inter-domain QoS establishment, QoS =
establishment over a path that traverses diverse QoS provisioning =
technologies, QoS accounting and authorization, QoS management etc. It =
will be useful to add such diverse scenarios there (I do not have text =
for them handy with me though). If the section becomes too big, it might =
be worthwhile to separate scenarios document and requirements document.
=20
Section 5.1:
=20
It may be useful to explicitly state the following requirement: "The =
signaling protocol should be independent of the QoS provisioning =
paradigms." This is in contrast to RSVP which is very tightly coupled to =
IntServ (though later force fitted to DiffServ).

------_=_NextPart_001_01C1B95B.C4B98924
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">


<META content=3D"MSHTML 5.50.4611.1300" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DTahoma size=3D2><SPAN=20
class=3D063335115-18022002>Hi:</SPAN></FONT></DIV>
<DIV><FONT face=3DTahoma size=3D2><SPAN=20
class=3D063335115-18022002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DTahoma size=3D2><SPAN class=3D063335115-18022002>I =
understand that=20
the authors are in process of revising the above draft. I would like to =
provide=20
few comments that may be considered during the revision process.=20
Thanks.</SPAN></FONT></DIV>
<DIV><FONT face=3DTahoma size=3D2><SPAN=20
class=3D063335115-18022002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DTahoma size=3D2><SPAN=20
class=3D063335115-18022002>Hemant</SPAN></FONT></DIV>
<DIV><FONT face=3DTahoma size=3D2></FONT>&nbsp;</DIV>
<DIV><SPAN class=3D063335115-18022002><FONT face=3DTahoma=20
size=3D2>-----</FONT></SPAN></DIV>
<DIV><FONT face=3DTahoma size=3D2><SPAN=20
class=3D063335115-18022002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DTahoma size=3D2><SPAN=20
class=3D063335115-18022002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DTahoma size=3D2><SPAN =
class=3D063335115-18022002>Section 2.=20
Terminology:</SPAN></FONT></DIV>
<DIV><FONT face=3DTahoma size=3D2><SPAN=20
class=3D063335115-18022002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DTahoma size=3D2><SPAN class=3D063335115-18022002>[QoS] =
Domain: I=20
think this should be called [Administrative] domain, as the definition =
has no=20
relation to the uniformity of QoS technology (as with the definition of =
QoS=20
subdomain)&nbsp;of the domain, rather it&nbsp;is based on administrative =

uniformity.</SPAN></FONT></DIV>
<DIV><FONT face=3DTahoma size=3D2><SPAN=20
class=3D063335115-18022002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DTahoma size=3D2><SPAN =
class=3D063335115-18022002>Section 3.1, items=20
1) Handoff decision and 2) Trigger sources:</SPAN></FONT></DIV>
<DIV><FONT face=3DTahoma size=3D2><SPAN=20
class=3D063335115-18022002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DTahoma size=3D2><SPAN class=3D063335115-18022002>The =
handoff=20
decision and trigger sources&nbsp;should be out of scope of NSIS. NSIS =
should=20
rather focus only on "establishing" QoS along the packet path after =
handoff. The=20
handoff decision and triggers should be left to mobility management =
protocols to=20
consider.</SPAN></FONT></DIV>
<DIV><FONT face=3DTahoma size=3D2><SPAN=20
class=3D063335115-18022002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DTahoma size=3D2><SPAN class=3D063335115-18022002>Also, =
all the=20
scenarios (at least end host oriented) in this section are somehow =
related to=20
mobile terminals. There is a lack of other scenarios, such as say =
scenarios with=20
inter-domain QoS establishment, QoS establishment over a path that =
traverses=20
diverse QoS provisioning technologies, QoS accounting and authorization, =
QoS=20
management etc. It will be useful to add&nbsp;such =
diverse&nbsp;scenarios there=20
(I do not have text for them handy with me though). If the section =
becomes too=20
big, it might be worthwhile to separate scenarios document and =
requirements=20
document.</SPAN></FONT></DIV>
<DIV><FONT face=3DTahoma size=3D2><SPAN=20
class=3D063335115-18022002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DTahoma size=3D2><SPAN =
class=3D063335115-18022002>Section=20
5.1:</SPAN></FONT></DIV>
<DIV><FONT face=3DTahoma size=3D2><SPAN=20
class=3D063335115-18022002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DTahoma size=3D2><SPAN class=3D063335115-18022002>It =
may be useful to=20
explicitly&nbsp;state the following requirement: "The signaling protocol =
should=20
be independent of the QoS provisioning paradigms." This is in contrast =
to RSVP=20
which is very tightly coupled to IntServ (though later force fitted to=20
DiffServ).</SPAN></FONT></DIV></BODY></HTML>

------_=_NextPart_001_01C1B95B.C4B98924--

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



From daemon@optimus.ietf.org  Tue Feb 19 15:05: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 PAA03633
	for <nsis-archive@odin.ietf.org>; Tue, 19 Feb 2002 15:05:37 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id PAA00237
	for nsis-archive@odin.ietf.org; Tue, 19 Feb 2002 15:05: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 OAA29661;
	Tue, 19 Feb 2002 14:59: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 OAA29632
	for <nsis@optimus.ietf.org>; Tue, 19 Feb 2002 14:59:54 -0500 (EST)
Received: from penguin-ext.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 OAA03426
	for <nsis@ietf.org>; Tue, 19 Feb 2002 14:59:51 -0500 (EST)
Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137])
	by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g1JJxLB20654
	for <nsis@ietf.org>; Tue, 19 Feb 2002 20:59:21 +0100 (MET)
Received: from era-t.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T))
	id UAA12149; Tue, 19 Feb 2002 20:59:18 +0100
Message-ID: <3C72ADBB.8060906@era-t.ericsson.se>
Date: Tue, 19 Feb 2002 20:55:39 +0100
From: Gabor Fodor <Gabor.Fodor@era-t.ericsson.se>
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2
X-Accept-Language: en-us
MIME-Version: 1.0
To: nsis@ietf.org
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [NSIS] I-D ACTION:draft-fodor-reqts-cellular-netwks-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 <nsis.ietf.org>
X-BeenThere: nsis@ietf.org
Content-Transfer-Encoding: 7bit

Hi All,

I relaize that  the group is in the process of working on 
the requirements draft and that Marcus' draft is the 
basis for that.  However, I hope that the following draft 
can still highlight some important requirements 
from the point of view of multi-mode (mobile) terminals 
that use IP level signaling to request 
QoS enabled services from an IP backbone.  

I expect that during the lifetime of the NSIS
signaling protocol multiple access technologies 
(including wireless, cellular, WLAN and wired ones)
will be widely used to access IP based services, 
and we therefore list a few key requirements 
on the signaling protocol that is used in such a scenario.
Applications that use the protocol may not be even aware 
of the specific access technology that they are using 
at a given time. 

In such a scenario, the IP level
QoS parameters are not only used to specify the requested 
IP level service, but also 
(through an access specific translation function)
to help the mobile node's wireless link manager to configure the
wireless bearer service. 
In such a scenario, the IP level QoS
signaling must meet special requirements in order to 
support the spectrum efficient management 
of the wireless resources.

I hope that these requirements can serve as an input towards
the doc.

/Gabor

-------- Original Message --------
Subject: I-D ACTION:draft-fodor-reqts-cellular-netwks-00.txt
Date: Tue, 19 Feb 2002 07:01:48 -0500
From: Internet-Drafts@ietf.org
Reply-To: Internet-Drafts@ietf.org
To: IETF-Announce:;@loki.ietf.org



A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: NSIS QoS Signaling Requirements from a Multi-access 
                          Wireless Perspective
	Author(s)	: G. Fodor
	Filename	: draft-fodor-reqts-cellular-netwks-00.txt
	Pages		: 9
	Date		: 18-Feb-02
	
We consider access technology agnostic applications that use IP level
QoS primitives to specify their QoS requirements. In future wireless
systems (beyond what is often referred to as 3G), where mobile nodes
may access an IP backbone over diverse access networks, the IP level
QoS primitives are not only used to specify the requested IP level
service, but also (through an access specific translation function)
to help the mobile node's wireless link manager to configure the
wireless bearer service. In such a scenario, the IP level QoS
primitives must meet special requirements in order to support the
spectrum efficient management of the wireless resources.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-fodor-reqts-cellular-netwks-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-fodor-reqts-cellular-netwks-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-fodor-reqts-cellular-netwks-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.







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



From daemon@optimus.ietf.org  Tue Feb 19 16:26: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 QAA06023
	for <nsis-archive@odin.ietf.org>; Tue, 19 Feb 2002 16:26:13 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id QAA04084
	for nsis-archive@odin.ietf.org; Tue, 19 Feb 2002 16:26:16 -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 QAA03968;
	Tue, 19 Feb 2002 16:24: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 QAA03936
	for <nsis@optimus.ietf.org>; Tue, 19 Feb 2002 16:24:33 -0500 (EST)
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 QAA06000
	for <nsis@ietf.org>; Tue, 19 Feb 2002 16:24:29 -0500 (EST)
Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19)
	id <1S9WNJ99>; Tue, 19 Feb 2002 21:23:20 -0000
Message-ID: <76C92FBBFB58D411AE760090271ED4180459492A@rsys002a.roke.co.uk>
From: "Hancock, Robert" <robert.hancock@roke.co.uk>
To: Marcus Brunner <brunner@ccrle.nec.de>, NSIS Mailing List
	 <nsis@ietf.org>
Subject: RE: [NSIS] Scenario for IP telephony (is about to become: signall
	ing on or off the data path, again...)
Date: Tue, 19 Feb 2002 21:23:17 -0000
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 <nsis.ietf.org>
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"
Content-Transfer-Encoding: quoted-printable

Marcus,

I also found that scenario interesting, especially as it provides some =
structured thinking on the scalability issues, like what information we =
would like/need to be able to ignore and where. So more scenarios which =
tell us about aggregation requirements (and how faithfully flows within =
aggregates need to be treated) are certainly important.

If we generalise the scenario the way you are suggesting, I guess this =
will bring the signalling on/off data path question back to life. The =
characteristic of the PSTN gateway that seems to be emphasised in the =
draft is that it is the traffic source/sink. On the other hand, a SIP =
server might be nowhere near the traffic path (a server doing call =
redirection might easily not even be in the same administrative domain =
as any of the traffic).

I like the flexibility to support off-path signalling, but this seems =
to be going a bit far. Or are you suggesting less general situations =
like in a small corporate network where simple IP phones know that they =
have a local SIP server which they can cede QoS negotiation =
responsibility to?

Robert H.

> -----Original Message-----
> From: Marcus Brunner [mailto:brunner@ccrle.nec.de]
> Sent: 18 February 2002 02:28
> To: NSIS Mailing List
> Subject: [NSIS] Scenario for IP telephony
>=20
>=20
> I have shortly looked it over David and Co=B4s draft and found=20
> the scenario on=20
> QoS signaling between PSTN gateways and backbone routers particularly =

> interesting.
>=20
> However IMHO the scenario could be broadend to something like=20
> "IP telephony=20
> signaling server to network QoS signaling" not only including=20
> PSTN signaling=20
> servers, but SIP servers as well. Opinions?
>=20
> Marcus
>=20
> -------
> Marcus Brunner
> Network Labs
> NEC Europe Ltd
> Heidelberg, Germany
>=20
> E-Mail: brunner@ccrle.nec.de
> WWW: www.brubers.org/marcus
>=20
>=20
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis
>=20

--------------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 Feb 19 16: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 QAA06039
	for <nsis-archive@odin.ietf.org>; Tue, 19 Feb 2002 16:26:19 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id QAA04099
	for nsis-archive@odin.ietf.org; Tue, 19 Feb 2002 16:26: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 QAA04012;
	Tue, 19 Feb 2002 16:24: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 QAA03972
	for <nsis@optimus.ietf.org>; Tue, 19 Feb 2002 16:24:35 -0500 (EST)
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 QAA06003
	for <nsis@ietf.org>; Tue, 19 Feb 2002 16:24:31 -0500 (EST)
Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19)
	id <1S9WNJ0A>; Tue, 19 Feb 2002 21:23:20 -0000
Message-ID: <76C92FBBFB58D411AE760090271ED4180459492B@rsys002a.roke.co.uk>
From: "Hancock, Robert" <robert.hancock@roke.co.uk>
To: Hemant.Chaskar@nokia.com, nsis@ietf.org
Subject: RE: [NSIS] Few comments on draft-brunner-nsis-req-00.txt
Date: Tue, 19 Feb 2002 21:23:19 -0000
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 <nsis.ietf.org>
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.

--------------InterScan_NT_MIME_Boundary
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C1B98B.A5AFC19A"

------_=_NextPart_001_01C1B98B.A5AFC19A
Content-Type: text/plain;
	charset="iso-8859-1"

Hi Hemant,
 
On the 5.1 comment, I would be very keen to establish these sorts of 'decoupling' boundaries. 5.1.4 is about decoupling signalling protocol and signalling data, which [I think] corresponds partly to the question of RSVP/IntServ coupling. In 5.1.1 we said that signalling had to be applicable to a variety of QoS technology, but this could be strengthened to say that independence of signalling and provisioning paradigm is a (the?) way to do this. 
 
Sometimes it's hard to work out where the dividing line between protocol and service class/provisioning paradigm should actually lie (what about session identification, policy attributes, authentication, soft/hard-state-ness...). Do you have specific concerns about which of these things [or others] have caused problems in coupling rsvp and intserv together?
 
robert h.
 
PS. Briefly, I might well agree with you on the terminology and scenario issues. (For terminology, we started with 'Domain' but then I wanted to dress it up a little since 'Domain' is such an over-used word. And I'd like more core-oriented scenarios, but we need people to write them ... )

-----Original Message-----
From: Hemant.Chaskar@nokia.com [mailto:Hemant.Chaskar@nokia.com]
Sent: 19 February 2002 15:41
To: nsis@ietf.org
Subject: [NSIS] Few comments on draft-brunner-nsis-req-00.txt


Hi:
 
I understand that the authors are in process of revising the above draft. I would like to provide few comments that may be considered during the revision process. Thanks.
 
Hemant
 
-----
 
 
Section 2. Terminology:
 
[QoS] Domain: I think this should be called [Administrative] domain, as the definition has no relation to the uniformity of QoS technology (as with the definition of QoS subdomain) of the domain, rather it is based on administrative uniformity.
 
Section 3.1, items 1) Handoff decision and 2) Trigger sources:
 
The handoff decision and trigger sources should be out of scope of NSIS. NSIS should rather focus only on "establishing" QoS along the packet path after handoff. The handoff decision and triggers should be left to mobility management protocols to consider.
 
Also, all the scenarios (at least end host oriented) in this section are somehow related to mobile terminals. There is a lack of other scenarios, such as say scenarios with inter-domain QoS establishment, QoS establishment over a path that traverses diverse QoS provisioning technologies, QoS accounting and authorization, QoS management etc. It will be useful to add such diverse scenarios there (I do not have text for them handy with me though). If the section becomes too big, it might be worthwhile to separate scenarios document and requirements document.
 
Section 5.1:
 
It may be useful to explicitly state the following requirement: "The signaling protocol should be independent of the QoS provisioning paradigms." This is in contrast to RSVP which is very tightly coupled to IntServ (though later force fitted to DiffServ).


------_=_NextPart_001_01C1B98B.A5AFC19A
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">


<META content="MSHTML 5.50.4616.200" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=390115120-19022002><FONT face=Arial color=#0000ff size=2>Hi 
Hemant,</FONT></SPAN></DIV>
<DIV><SPAN class=390115120-19022002><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=390115120-19022002><FONT face=Arial color=#0000ff size=2>On the 
5.1 comment, I would be very keen to establish these sorts of 'decoupling' 
boundaries. 5.1.4 is about decoupling signalling protocol and signalling data, 
which [I think] corresponds partly to the question of RSVP/IntServ coupling. In 
5.1.1 we said that signalling&nbsp;had to be applicable to a variety of QoS 
technology, but this could be strengthened to say that independence of 
signalling and provisioning paradigm is a (the?) way to do this. 
</FONT></SPAN></DIV>
<DIV><SPAN class=390115120-19022002><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=390115120-19022002><FONT face=Arial color=#0000ff 
size=2>Sometimes it's hard to work out where the dividing line between protocol 
and service class/provisioning paradigm&nbsp;should actually lie (what about 
session identification, policy attributes, authentication, 
soft/hard-state-ness...). Do you have specific concerns about which of these 
things [or others] have caused problems in coupling rsvp and intserv 
together?</FONT></SPAN></DIV>
<DIV><SPAN class=390115120-19022002><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=390115120-19022002><FONT face=Arial color=#0000ff size=2>robert 
h.</FONT></SPAN></DIV>
<DIV><SPAN class=390115120-19022002><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=390115120-19022002><FONT face=Arial color=#0000ff size=2>PS. 
<SPAN class=390115120-19022002><FONT face=Arial color=#0000ff size=2>Briefly, I 
might well agree with you on the terminology and scenario issues. (For 
terminology, we started with 'Domain' but then I wanted to dress it up a little 
since 'Domain' is such an over-used word. And I'd like more core-oriented 
scenarios, but we need people to write them ... 
)</FONT></SPAN></FONT></SPAN></DIV>
<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Hemant.Chaskar@nokia.com 
  [mailto:Hemant.Chaskar@nokia.com]<BR><B>Sent:</B> 19 February 2002 
  15:41<BR><B>To:</B> nsis@ietf.org<BR><B>Subject:</B> [NSIS] Few comments on 
  draft-brunner-nsis-req-00.txt<BR><BR></FONT></DIV>
  <DIV><FONT face=Tahoma size=2><SPAN 
  class=063335115-18022002>Hi:</SPAN></FONT></DIV>
  <DIV><FONT face=Tahoma size=2><SPAN 
  class=063335115-18022002></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=Tahoma size=2><SPAN class=063335115-18022002>I understand that 
  the authors are in process of revising the above draft. I would like to 
  provide few comments that may be considered during the revision process. 
  Thanks.</SPAN></FONT></DIV>
  <DIV><FONT face=Tahoma size=2><SPAN 
  class=063335115-18022002></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=Tahoma size=2><SPAN 
  class=063335115-18022002>Hemant</SPAN></FONT></DIV>
  <DIV><FONT face=Tahoma size=2></FONT>&nbsp;</DIV>
  <DIV><SPAN class=063335115-18022002><FONT face=Tahoma 
  size=2>-----</FONT></SPAN></DIV>
  <DIV><FONT face=Tahoma size=2><SPAN 
  class=063335115-18022002></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=Tahoma size=2><SPAN 
  class=063335115-18022002></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=Tahoma size=2><SPAN class=063335115-18022002>Section 2. 
  Terminology:</SPAN></FONT></DIV>
  <DIV><FONT face=Tahoma size=2><SPAN 
  class=063335115-18022002></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=Tahoma size=2><SPAN class=063335115-18022002>[QoS] Domain: I 
  think this should be called [Administrative] domain, as the definition has no 
  relation to the uniformity of QoS technology (as with the definition of QoS 
  subdomain)&nbsp;of the domain, rather it&nbsp;is based on administrative 
  uniformity.</SPAN></FONT></DIV>
  <DIV><FONT face=Tahoma size=2><SPAN 
  class=063335115-18022002></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=Tahoma size=2><SPAN class=063335115-18022002>Section 3.1, 
  items 1) Handoff decision and 2) Trigger sources:</SPAN></FONT></DIV>
  <DIV><FONT face=Tahoma size=2><SPAN 
  class=063335115-18022002></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=Tahoma size=2><SPAN class=063335115-18022002>The handoff 
  decision and trigger sources&nbsp;should be out of scope of NSIS. NSIS should 
  rather focus only on "establishing" QoS along the packet path after handoff. 
  The handoff decision and triggers should be left to mobility management 
  protocols to consider.</SPAN></FONT></DIV>
  <DIV><FONT face=Tahoma size=2><SPAN 
  class=063335115-18022002></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=Tahoma size=2><SPAN class=063335115-18022002>Also, all the 
  scenarios (at least end host oriented) in this section are somehow related to 
  mobile terminals. There is a lack of other scenarios, such as say scenarios 
  with inter-domain QoS establishment, QoS establishment over a path that 
  traverses diverse QoS provisioning technologies, QoS accounting and 
  authorization, QoS management etc. It will be useful to add&nbsp;such 
  diverse&nbsp;scenarios there (I do not have text for them handy with me 
  though). If the section becomes too big, it might be worthwhile to separate 
  scenarios document and requirements document.</SPAN></FONT></DIV>
  <DIV><FONT face=Tahoma size=2><SPAN 
  class=063335115-18022002></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=Tahoma size=2><SPAN class=063335115-18022002>Section 
  5.1:</SPAN></FONT></DIV>
  <DIV><FONT face=Tahoma size=2><SPAN 
  class=063335115-18022002></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=Tahoma size=2><SPAN class=063335115-18022002>It may be useful 
  to explicitly&nbsp;state the following requirement: "The signaling protocol 
  should be independent of the QoS provisioning paradigms." This is in contrast 
  to RSVP which is very tightly coupled to IntServ (though later force fitted to 
  DiffServ).</SPAN></FONT></DIV></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C1B98B.A5AFC19A--


--------------InterScan_NT_MIME_Boundary
Content-Type: text/plain;
	name="RMRL-Disclaimer.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="RMRL-Disclaimer.txt"
Content-Transfer-Encoding: 7bit
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 Feb 19 16:29: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 QAA06079
	for <nsis-archive@odin.ietf.org>; Tue, 19 Feb 2002 16:29:29 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id QAA04229
	for nsis-archive@odin.ietf.org; Tue, 19 Feb 2002 16:29: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 QAA04161;
	Tue, 19 Feb 2002 16:27: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 QAA04132
	for <nsis@optimus.ietf.org>; Tue, 19 Feb 2002 16:27:48 -0500 (EST)
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06067
	for <nsis@ietf.org>; Tue, 19 Feb 2002 16:27:45 -0500 (EST)
Received: from murphy-bsd.juniper.net (murphy-bsd.juniper.net [172.17.12.128])
	by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g1JLRHi02232;
	Tue, 19 Feb 2002 13:27:17 -0800 (PST)
	(envelope-from murphy@juniper.net)
Received: from juniper.net (localhost [127.0.0.1])
	by murphy-bsd.juniper.net (8.11.1/8.9.3) with ESMTP id g1JLRG245236;
	Tue, 19 Feb 2002 13:27:16 -0800 (PST)
	(envelope-from murphy@juniper.net)
Message-ID: <3C72C334.3080904@juniper.net>
Date: Tue, 19 Feb 2002 13:27:16 -0800
From: Jim Murphy <murphy@juniper.net>
Organization: Juniper Networks
User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.7) Gecko/20011222
X-Accept-Language: en-us
MIME-Version: 1.0
To: Marcus Brunner <brunner@ccrle.nec.de>
CC: NSIS Mailing List <nsis@ietf.org>
Subject: Re: [NSIS] Scenario for IP telephony
References: <1013999259.3c70669bf0f89@citadel.mobility.ccrle.nec.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
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 <nsis.ietf.org>
X-BeenThere: nsis@ietf.org
Content-Transfer-Encoding: 8bit

Marcus,

Marcus Brunner wrote:

> I have shortly looked it over David and Co´s draft and found the scenario on 
> QoS signaling between PSTN gateways and backbone routers particularly 
> interesting.
> 
> However IMHO the scenario could be broadend to something like "IP telephony 
> signaling server to network QoS signaling" not only including PSTN signaling 
> servers, but SIP servers as well. Opinions?
> 


If the SIP servers are in the path of the data flow, then yes, otherwise,
I think the SIP servers may have a role as policy servers, for example,
as defined in draft-ietf-sip-manyfolks-resource-03. The media endpoints
of the call would still signal for QoS, however, signaling servers, or close
relatives, may get into the act to authorize requests from routers at the
edge.

Thanks,

Jim


> 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
> 
> 
> 



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



From daemon@optimus.ietf.org  Wed Feb 20 07:04: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 HAA27426
	for <nsis-archive@odin.ietf.org>; Wed, 20 Feb 2002 07:04:00 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id HAA19564
	for nsis-archive@odin.ietf.org; Wed, 20 Feb 2002 07:04:02 -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 GAA19028;
	Wed, 20 Feb 2002 06:59:44 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA18999
	for <nsis@optimus.ietf.org>; Wed, 20 Feb 2002 06:59:42 -0500 (EST)
Received: from porsta.cs.Helsinki.FI (root@porsta.cs.Helsinki.FI [128.214.48.124])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27326
	for <nsis@ietf.org>; Wed, 20 Feb 2002 06:59:39 -0500 (EST)
Received: from punasaari.cs.Helsinki.FI (IDENT:jmanner@punasaari.cs.Helsinki.FI [128.214.11.52])
	by porsta.cs.Helsinki.FI (8.11.6/8.11.6) with ESMTP id g1KBxbp30093;
	Wed, 20 Feb 2002 13:59:38 +0200
Date: Wed, 20 Feb 2002 13:59:32 +0200 (EET)
From: Jukka Manner <jmanner@cs.Helsinki.FI>
To: Gabor Fodor <Gabor.Fodor@era-t.ericsson.se>
cc: nsis@ietf.org
In-Reply-To: <3C72ADBB.8060906@era-t.ericsson.se>
Message-ID: <Pine.LNX.4.44.0202201347480.15934-100000@punasaari.cs.Helsinki.FI>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Subject: [NSIS] A few comments to draft-fodor-reqts-cellular-netwks-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 <nsis.ietf.org>
X-BeenThere: nsis@ietf.org


	Hi,

	As I read the draft, two requirements left me wondering:

	R2: how does this match with the UDP-lite proposal, where the UDP
header indicates the need for UEP. Thus, does the QoS primitives /
signalling need to indicate the need for UEP? If the transport protocol
does not support UEP, you won't get the packet sent to/accepted at the
receiver. Also, you don't even need any QoS mechanism to use UDP-lite.

	R3: you seem to assume that doing bi-directional resource 
allocations also implies that routing is symmetric for uplink and 
downlink. Since IP routing is asymmetric, I doubt that bi-directional 
reservations are possible with a single mechanism, but rather imply that 
there must be separate signalling for the two directions. Thus, eg. RSVP 
makes it possible to have asymmetric reservations on the two directions.

	Cheers,

	Jukka


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



From daemon@optimus.ietf.org  Wed Feb 20 09:23: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 JAA01327
	for <nsis-archive@odin.ietf.org>; Wed, 20 Feb 2002 09:23:39 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id JAA25696
	for nsis-archive@odin.ietf.org; Wed, 20 Feb 2002 09:23: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 JAA25619;
	Wed, 20 Feb 2002 09:20: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 JAA25589
	for <nsis@optimus.ietf.org>; Wed, 20 Feb 2002 09:20:53 -0500 (EST)
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 JAA01240
	for <nsis@ietf.org>; Wed, 20 Feb 2002 09:20:46 -0500 (EST)
Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19)
	id <1S9WNLCW>; Wed, 20 Feb 2002 14:18:55 -0000
Message-ID: <76C92FBBFB58D411AE760090271ED4181EA0F4@rsys002a.roke.co.uk>
From: "Hancock, Robert" <robert.hancock@roke.co.uk>
To: "'Jukka Manner'" <jmanner@cs.Helsinki.FI>,
        Gabor Fodor
	 <Gabor.Fodor@era-t.ericsson.se>
Cc: nsis@ietf.org
Subject: RE: [NSIS] A few comments to draft-fodor-reqts-cellular-netwks-00
	.txt
Date: Wed, 20 Feb 2002 14:18:45 -0000
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 <nsis.ietf.org>
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"

Hi Jukka, Gabor,

On the UDP-lite issue, my understanding is that UDP-lite only tells you that some of the packet is checksum protected and some isn't. The sophistication of signalling required for full UEP (e.g. to support AMR codec operation) is much greater. I guess if you had UEP QoS signalling you wouldn't need UDP-lite, you could just switch the checksum off altogether (at least for IPv4).

I was more concerned about whether the scenario as presented really justifies the need for wireless-related parameters at all. It seems to concentrate on the case where the wireless link is the last hop, directly connected to the node where the end application is running. In that case, it's clear that good quality IP QoS (fine grained, efficient, local etc.) is important, more so than in fixed networks. I think it's less clear that the IP layer signalling needs to have link (or 'link-ish') parameters in it. After all, the link layers already have their own signalling, and can tune the link to the required QoS even more tightly.

It's true that if applications use the IntServ classes to request QoS from their network stack, these classes need to be extended with wireless hints. But that's a comment on the deficiency of basing inter-layer interfaces on protocols, not a requirement to extend the protocol itself.

One reason we thought to be very careful here was that if you have wireless-related parameters being exchanged at both IP (RSVP) and link layers, it might be hard for independent implementors of each end to work out which layer to use for negotiation and in which order, and which layer was in charge. This was raised after SLC as an open issue on the list, but the argument wasn't really clear (partly my fault).

I think there _is_ actually a good case for having wireless related parameters, but that the justifying scenario is where the wireless link is 'interior' (e.g. 3G mobile acting as a wireless router for a local subnet), but in that case you might need take into account other considerations as well. Then you need to get the wireless-related information from the application into the router. But in either case, we need to have a clear model of how the link layer negotiation interacts with the IP layer negotiation.

Or did I miss something?

Robert H.

> -----Original Message-----
> From: Jukka Manner [mailto:jmanner@cs.Helsinki.FI]
> Sent: 20 February 2002 12:00
> To: Gabor Fodor
> Cc: nsis@ietf.org
> Subject: [NSIS] A few comments to
> draft-fodor-reqts-cellular-netwks-00.txt
> 
> 
> 
> 	Hi,
> 
> 	As I read the draft, two requirements left me wondering:
> 
> 	R2: how does this match with the UDP-lite proposal, 
> where the UDP
> header indicates the need for UEP. Thus, does the QoS primitives /
> signalling need to indicate the need for UEP? If the 
> transport protocol
> does not support UEP, you won't get the packet sent to/accepted at the
> receiver. Also, you don't even need any QoS mechanism to use UDP-lite.
> 
> 	R3: you seem to assume that doing bi-directional resource 
> allocations also implies that routing is symmetric for uplink and 
> downlink. Since IP routing is asymmetric, I doubt that bi-directional 
> reservations are possible with a single mechanism, but rather 
> imply that 
> there must be separate signalling for the two directions. 
> Thus, eg. RSVP 
> makes it possible to have asymmetric reservations on the two 
> directions.
> 
> 	Cheers,
> 
> 	Jukka
> 
> 
> _______________________________________________
> 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 Feb 20 10:02: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 KAA02707
	for <nsis-archive@odin.ietf.org>; Wed, 20 Feb 2002 10:02:45 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id KAA28154
	for nsis-archive@odin.ietf.org; Wed, 20 Feb 2002 10:02: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 KAA28030;
	Wed, 20 Feb 2002 10:01:22 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA27995
	for <nsis@optimus.ietf.org>; Wed, 20 Feb 2002 10:01:20 -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 KAA02676
	for <nsis@ietf.org>; Wed, 20 Feb 2002 10:01:15 -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.1.0/Switch-2.1.0) with ESMTP id g1KF1OZ02847
	for <nsis@ietf.org>; Wed, 20 Feb 2002 17:01:24 +0200 (EET)
Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T5930e619b8ac158f242fb@esvir04nok.ntc.nokia.com>;
 Wed, 20 Feb 2002 17:01:15 +0200
Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779);
	 Wed, 20 Feb 2002 15:58:17 +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] Scenario for IP telephony
Date: Wed, 20 Feb 2002 15:55:46 +0200
Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64982@esebe004.NOE.Nokia.com>
Thread-Topic: [NSIS] Scenario for IP telephony
Thread-Index: AcG4JAQRxxVGHp7ISISwUVOK/+eMBwB8e7HQ
To: <brunner@ccrle.nec.de>, <nsis@ietf.org>
X-OriginalArrivalTime: 20 Feb 2002 13:58:17.0213 (UTC) FILETIME=[A585A2D0:01C1BA16]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id KAA27996
Sender: nsis-admin@ietf.org
Errors-To: nsis-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Next Steps in Signaling <nsis.ietf.org>
X-BeenThere: nsis@ietf.org
Content-Transfer-Encoding: 8bit

Hi Marcus,

> However IMHO the scenario could be broadend to something like 
> "IP telephony signaling server to network QoS signaling" not only 
> including PSTN signaling servers, but SIP servers as well. Opinions?

This would be difficult.  For any signaling that is not on-path, we
will need to have a discovery mechanism as well as some sort of
URI - something like user@realm - where realm is the home network
of the user. 

I think a better approach is to allow a router to act as a QoS proxy,
and have some additional signaling (to a bandwidth broaker or something
like that) and additionally have some identity for the QoS request,
in case that user needs to interact with a AAA (or similar) mechanism.

John

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



From daemon@optimus.ietf.org  Wed Feb 20 10:03: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 KAA02764
	for <nsis-archive@odin.ietf.org>; Wed, 20 Feb 2002 10:03:43 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id KAA28245
	for nsis-archive@odin.ietf.org; Wed, 20 Feb 2002 10:03: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 KAA28142;
	Wed, 20 Feb 2002 10:02:40 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA28109
	for <nsis@optimus.ietf.org>; Wed, 20 Feb 2002 10:02:38 -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 KAA02700
	for <nsis@ietf.org>; Wed, 20 Feb 2002 10:02:33 -0500 (EST)
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.1.0/Switch-2.1.0) with ESMTP id g1KF2hZ04327
	for <nsis@ietf.org>; Wed, 20 Feb 2002 17:02:43 +0200 (EET)
Received: from esebh003.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T5930e74eb5ac158f22119@esvir02nok.ntc.nokia.com>;
 Wed, 20 Feb 2002 17:02:34 +0200
Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779);
	 Wed, 20 Feb 2002 15:59:30 +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] Scenario for IP telephony (is about to become: signalling on or off the data path, again...)
Date: Wed, 20 Feb 2002 15:59:28 +0200
Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64985@esebe004.NOE.Nokia.com>
Thread-Topic: [NSIS] Scenario for IP telephony (is about to become: signalling on or off the data path, again...)
Thread-Index: AcG5i+OhDCNgn8jKQ1+SFDjiaMLa2AAirNGA
To: <robert.hancock@roke.co.uk>, <brunner@ccrle.nec.de>, <nsis@ietf.org>
X-OriginalArrivalTime: 20 Feb 2002 13:59:30.0710 (UTC) FILETIME=[D1546360:01C1BA16]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id KAA28110
Sender: nsis-admin@ietf.org
Errors-To: nsis-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Next Steps in Signaling <nsis.ietf.org>
X-BeenThere: nsis@ietf.org
Content-Transfer-Encoding: 8bit

Hi Robert,

> I like the flexibility to support off-path signalling, but 
> this seems to be going a bit far. Or are you suggesting less 
> general situations like in a small corporate network where 
> simple IP phones know that they have a local SIP server which 
> they can cede QoS negotiation responsibility to?

I agree.  I think that if we go down the off-path signaling,
we will quickly come up with a lot of hard issues.  I'd prefer
to allow a framework architecture where an entity that is
on-path can proxy for other entities that may handle policy,
authorization, resource management, etc.

John

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



From daemon@optimus.ietf.org  Wed Feb 20 10:07: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 KAA02921
	for <nsis-archive@odin.ietf.org>; Wed, 20 Feb 2002 10:07:54 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id KAA28463
	for nsis-archive@odin.ietf.org; Wed, 20 Feb 2002 10:07:58 -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 JAA27578;
	Wed, 20 Feb 2002 09:59: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 JAA27547
	for <nsis@optimus.ietf.org>; Wed, 20 Feb 2002 09:59:44 -0500 (EST)
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 JAA02600
	for <nsis@ietf.org>; Wed, 20 Feb 2002 09:59:39 -0500 (EST)
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.1.0/Switch-2.1.0) with ESMTP id g1KF09i00860
	for <nsis@ietf.org>; Wed, 20 Feb 2002 17:00:09 +0200 (EET)
Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T5930e4a557ac158f2116f@esvir01nok.ntc.nokia.com>;
 Wed, 20 Feb 2002 16:59:40 +0200
Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779);
	 Wed, 20 Feb 2002 15:57:47 +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] Scenario for IP telephony
Date: Wed, 20 Feb 2002 15:57:00 +0200
Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64984@esebe004.NOE.Nokia.com>
Thread-Topic: [NSIS] Scenario for IP telephony
Thread-Index: AcG5jFhWM3sNYUcRRmCxbR+67aMTdwAihQxw
To: <murphy@juniper.net>, <brunner@ccrle.nec.de>
Cc: <nsis@ietf.org>
X-OriginalArrivalTime: 20 Feb 2002 13:57:47.0324 (UTC) FILETIME=[93B4EFC0:01C1BA16]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id JAA27548
Sender: nsis-admin@ietf.org
Errors-To: nsis-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Next Steps in Signaling <nsis.ietf.org>
X-BeenThere: nsis@ietf.org
Content-Transfer-Encoding: 8bit

Hi Jim,

> If the SIP servers are in the path of the data flow, then 
> yes, otherwise,
> I think the SIP servers may have a role as policy servers, 
> for example,
> as defined in draft-ietf-sip-manyfolks-resource-03. The media 
> endpoints
> of the call would still signal for QoS, however, signaling 
> servers, or close
> relatives, may get into the act to authorize requests from 
> routers at the edge.

Good point.  

John

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



From daemon@optimus.ietf.org  Wed Feb 20 17:02: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 RAA21690
	for <nsis-archive@odin.ietf.org>; Wed, 20 Feb 2002 17:02:43 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id RAA24414
	for nsis-archive@odin.ietf.org; Wed, 20 Feb 2002 17:02: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 QAA23524;
	Wed, 20 Feb 2002 16:56: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 QAA23492
	for <nsis@optimus.ietf.org>; Wed, 20 Feb 2002 16:56:41 -0500 (EST)
Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21582
	for <nsis@ietf.org>; Wed, 20 Feb 2002 16:56:35 -0500 (EST)
Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137])
	by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g1KLtwZc023757;
	Wed, 20 Feb 2002 22:55:58 +0100 (MET)
Received: from era-t.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T))
	id WAA19441; Wed, 20 Feb 2002 22:55:55 +0100
Message-ID: <3C741A8F.3000906@era-t.ericsson.se>
Date: Wed, 20 Feb 2002 22:52:15 +0100
From: Gabor Fodor <Gabor.Fodor@era-t.ericsson.se>
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2
X-Accept-Language: en-us
MIME-Version: 1.0
To: Jukka Manner <jmanner@cs.Helsinki.FI>
CC: nsis@ietf.org
Subject: Re: [NSIS] A few comments to draft-fodor-reqts-cellular-netwks-00.txt
References: <Pine.LNX.4.44.0202201347480.15934-100000@punasaari.cs.Helsinki.FI>
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 <nsis.ietf.org>
X-BeenThere: nsis@ietf.org
Content-Transfer-Encoding: 7bit

Jukka,

good questions ! Please consider my answers below :

Jukka Manner wrote:

>	Hi,
>
>	As I read the draft, two requirements left me wondering:
>
>	R2: how does this match with the UDP-lite proposal, where the UDP
>header indicates the need for UEP. Thus, does the QoS primitives /
>signalling need to indicate the need for UEP? If the transport protocol
>does not support UEP, you won't get the packet sent to/accepted at the
>receiver. Also, you don't even need any QoS mechanism to use UDP-lite.
>
UDP Lite together with quite a large number standard  RTP payload formats
(AMR, AMR WB, MPEG4, etc) allows the link layer
to perform QoS differentiation between the different parts of the RTP 
payload. 
For instance, in some cellular systems, the RTP payload may be segmented 
into
different parts, and these different parts  are transported over 
different radio channels
that are associated with different QoS. This technique can be especially 
important for
instance for AMR speech samples, but in theory the link layer can use 
this technique for
any other application. (Provided that it has some knowledge about the 
payload format
and what QoS it should associate with each part.)

You are perfectly right in saying that in practice you need UDP Lite for 
this, but UDP Lite
in itself  does not help the link layer to configure the proper QoS for 
the different parts
of the (typically RTP) payload. Therefore, R2 is concerned to support 
this kind of differentiation
by requiring from the IP level QoS signaling that it should allow for 
the indication of multiple
QoS levels.

You are also right in saying that you do not need any QoS mechanism to 
use UDP Lite,
but if an application wants to use and is able to indicate its (unequal) 
multiple QoS levels
(say an application that uses a standardized RTP format), then it should 
be able to do so.
(Let me also point out, that we are at the requirement discussion now, 
so we in fact should not
discuss the solution, but I am not thinking of quantitive QoS values 
here (that would be
unaccepatble from the application programmer's perspective), rather 
qualitative indications.)

Surely, if an application does not want this, it could simply ignore 
this capability of the
protocol.

>
>	R3: you seem to assume that doing bi-directional resource 
>allocations also implies that routing is symmetric for uplink and 
>downlink. Since IP routing is asymmetric, I doubt that bi-directional 
>reservations are possible with a single mechanism, but rather imply that 
>there must be separate signalling for the two directions. Thus, eg. RSVP 
>makes it possible to have asymmetric reservations on the two directions.
>
I would say that at this stage R3 is just stating the requirement that 
it must be able to set up
asymmetric bi-directional bearers between the parties. If  we in the 
solution phase find that
an existing protocol can do this, then it is fine. But of course we need 
to consider all requirements
when deciding on the solution approaches (such as extensions to existing 
protocols or new protocol(s)).
I am open to consider and discuss whether bi-directional reservation is 
possible/advantageous
with a single mechanism or we had better use two separate (instances of) 
mechanisms.

Jukka, thanks for the questions and I hope these answers help the 
discussion further ! 

Cheers /Gabor

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



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



From daemon@optimus.ietf.org  Wed Feb 20 18:06: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 SAA23329
	for <nsis-archive@odin.ietf.org>; Wed, 20 Feb 2002 18:06:29 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id SAA28275
	for nsis-archive@odin.ietf.org; Wed, 20 Feb 2002 18:06: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 RAA27445;
	Wed, 20 Feb 2002 17:54:48 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA27414
	for <nsis@optimus.ietf.org>; Wed, 20 Feb 2002 17:54:46 -0500 (EST)
Received: from penguin-ext.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 RAA23010
	for <nsis@ietf.org>; Wed, 20 Feb 2002 17:54:42 -0500 (EST)
Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137])
	by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g1KMsFB01147;
	Wed, 20 Feb 2002 23:54:15 +0100 (MET)
Received: from era-t.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T))
	id XAA20731; Wed, 20 Feb 2002 23:54:11 +0100
Message-ID: <3C742836.80308@era-t.ericsson.se>
Date: Wed, 20 Feb 2002 23:50:30 +0100
From: Gabor Fodor <Gabor.Fodor@era-t.ericsson.se>
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2
X-Accept-Language: en-us
MIME-Version: 1.0
To: "Hancock, Robert" <robert.hancock@roke.co.uk>
CC: "'Jukka Manner'" <jmanner@cs.Helsinki.FI>, nsis@ietf.org
Subject: Re: [NSIS] A few comments to draft-fodor-reqts-cellular-netwks-00	.txt
References: <76C92FBBFB58D411AE760090271ED4181EA0F4@rsys002a.roke.co.uk>
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 <nsis.ietf.org>
X-BeenThere: nsis@ietf.org
Content-Transfer-Encoding: 7bit

Hi Robert,

I agree that we need to have a set of scenarios in the contect of which
we can discuss both the protocol requirements and the use of the 
wireless hint
parameters. And I also agree that the scenario you are mentioning here
with the 'interior' wireless link can be one of  these relevant scenarios,
but I am not sure if I understand your concern regarding the scenario 
presented
in the draft.

That scenario assumes that the application requests a QoS service via the
"IP QoS module", and cannot configure the wireless link directly. It is 
true that
the link layers already have their own signaling and can tune to the 
required
QoS _provided_ that they know what this required QoS is ! Please note 
that we
are not proposing a huge number of strange paramaters, just a very few
generic and qualitative indications. I envisage that this kind of 
scenario becomes
especially important in a multi-access environment, where the mobile node
moves accross multiple and diverse accesses, like between a cellular and a
hot spot area, (while accessing the same IP core network)
and the application is not even aware of the specific L2 technology,
so it cannot configure it. On the other hand, the application may need 
to adjust
adaptively on the fly for instance its bit rate, simply because the 
available bandwidth differs
over these accesses, so the application needs to be able to control QoS 
during
run-time (but in an access agnostic manner). 

I think that it is useful to actually seprate the paramater discussion 
from the
actual protocol requirement discussion, and R1 actually only talks about
per-flow QoS and traffic characterization.

I also agree that we need to be careful about exchanging parameters both at
the IP and the link layer, but I don't think this should keep us from 
providing
the really necessary information at the IP layer to the link layer. 
After all, such
scenarios already exist in some cellular standards.

I would be open to start working on a small set of scenarios where we go 
through
what paramaters are needed, where they are translated to link layer 
paramaters, and
in which ones the requirements R1-R7 are important/luseful, etc. 
Likewise, I do
agree with the proposal of developing a model of how the link layer 
negotiation
interacts with the IP layer negotiation, this is important.

(Regarding the UDP discussion, please see my previous mail to Jukka and 
to the list.)

/Gabor

Hancock, Robert wrote:

>Hi Jukka, Gabor,
>
>On the UDP-lite issue, my understanding is that UDP-lite only tells you that some of the packet is checksum protected and some isn't. The sophistication of signalling required for full UEP (e.g. to support AMR codec operation) is much greater. I guess if you had UEP QoS signalling you wouldn't need UDP-lite, you could just switch the checksum off altogether (at least for IPv4).
>
>I was more concerned about whether the scenario as presented really justifies the need for wireless-related parameters at all. It seems to concentrate on the case where the wireless link is the last hop, directly connected to the node where the end application is running. In that case, it's clear that good quality IP QoS (fine grained, efficient, local etc.) is important, more so than in fixed networks. I think it's less clear that the IP layer signalling needs to have link (or 'link-ish') parameters in it. After all, the link layers already have their own signalling, and can tune the link to the required QoS even more tightly.
>
>It's true that if applications use the IntServ classes to request QoS from their network stack, these classes need to be extended with wireless hints. But that's a comment on the deficiency of basing inter-layer interfaces on protocols, not a requirement to extend the protocol itself.
>
>One reason we thought to be very careful here was that if you have wireless-related parameters being exchanged at both IP (RSVP) and link layers, it might be hard for independent implementors of each end to work out which layer to use for negotiation and in which order, and which layer was in charge. This was raised after SLC as an open issue on the list, but the argument wasn't really clear (partly my fault).
>
>I think there _is_ actually a good case for having wireless related parameters, but that the justifying scenario is where the wireless link is 'interior' (e.g. 3G mobile acting as a wireless router for a local subnet), but in that case you might need take into account other considerations as well. Then you need to get the wireless-related information from the application into the router. But in either case, we need to have a clear model of how the link layer negotiation interacts with the IP layer negotiation.
>
>Or did I miss something?
>
>Robert H.
>
>>-----Original Message-----
>>From: Jukka Manner [mailto:jmanner@cs.Helsinki.FI]
>>Sent: 20 February 2002 12:00
>>To: Gabor Fodor
>>Cc: nsis@ietf.org
>>Subject: [NSIS] A few comments to
>>draft-fodor-reqts-cellular-netwks-00.txt
>>
>>
>>
>>	Hi,
>>
>>	As I read the draft, two requirements left me wondering:
>>
>>	R2: how does this match with the UDP-lite proposal, 
>>where the UDP
>>header indicates the need for UEP. Thus, does the QoS primitives /
>>signalling need to indicate the need for UEP? If the 
>>transport protocol
>>does not support UEP, you won't get the packet sent to/accepted at the
>>receiver. Also, you don't even need any QoS mechanism to use UDP-lite.
>>
>>	R3: you seem to assume that doing bi-directional resource 
>>allocations also implies that routing is symmetric for uplink and 
>>downlink. Since IP routing is asymmetric, I doubt that bi-directional 
>>reservations are possible with a single mechanism, but rather 
>>imply that 
>>there must be separate signalling for the two directions. 
>>Thus, eg. RSVP 
>>makes it possible to have asymmetric reservations on the two 
>>directions.
>>
>>	Cheers,
>>
>>	Jukka
>>
>>
>>_______________________________________________
>>nsis mailing list
>>nsis@ietf.org
>>https://www1.ietf.org/mailman/listinfo/nsis
>>
>>
>>------------------------------------------------------------------------
>>
>>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.
>>



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



From daemon@optimus.ietf.org  Thu Feb 21 02:47: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 CAA10342
	for <nsis-archive@odin.ietf.org>; Thu, 21 Feb 2002 02:47:34 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id CAA00914
	for nsis-archive@odin.ietf.org; Thu, 21 Feb 2002 02:47: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 CAA00849;
	Thu, 21 Feb 2002 02:45: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 CAA00816
	for <nsis@optimus.ietf.org>; Thu, 21 Feb 2002 02:45:08 -0500 (EST)
Received: from ish7.ericsson.com.au (ish7.ericsson.com.au [203.61.155.111])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10317
	for <nsis@ietf.org>; Thu, 21 Feb 2002 02:45:04 -0500 (EST)
Received: from brsf10.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10])
	by ish7.ericsson.com.au (8.11.6+Sun/8.11.6) with ESMTP id g1L7hcM16608;
	Thu, 21 Feb 2002 18:43:38 +1100 (EST)
Received: from eaubrnt019.epa.ericsson.se (eaubrnt019.epa.ericsson.se [146.11.9.165])
	by brsf10.epa.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id SAA04785;
	Thu, 21 Feb 2002 18:45:04 +1100 (EST)
Received: from localhost.localdomain (7-208.epa.ericsson.se [146.11.7.208]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id 133C4KJ5; Thu, 21 Feb 2002 18:45:02 +1100
Subject: RE: [NSIS] A few comments to draft-fodor-reqts-cellular-netwks-00
	.txt
From: Brian Williams <brian.williams@ericsson.com.au>
To: "Hancock, Robert" <robert.hancock@roke.co.uk>
Cc: "'Jukka Manner'" <jmanner@cs.Helsinki.FI>,
        Gabor Fodor
	 <Gabor.Fodor@era-t.ericsson.se>, nsis@ietf.org
In-Reply-To: <76C92FBBFB58D411AE760090271ED4181EA0F4@rsys002a.roke.co.uk>
References: <76C92FBBFB58D411AE760090271ED4181EA0F4@rsys002a.roke.co.uk>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Mailer: Evolution/1.0.1 
Date: 21 Feb 2002 18:40:53 +1100
Message-Id: <1014277255.2128.127.camel@mindy>
Mime-Version: 1.0
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 <nsis.ietf.org>
X-BeenThere: nsis@ietf.org
Content-Transfer-Encoding: 7bit

Hi Robert.
I would definitely agree that there are many different scenarios, and
one with the application node sitting behind a wireless router/gateway
is the most obvious situation which introduces signalling requirements.

I would also add though that even within one physical node, there can be
scenarios that effectively become an equivalent to this application node
behind a gateway router. For example, on my PC I have run multiple
virtual machines. The communication between these virtual machines
occurs over a virtual ethernet, but it is all within one node.

There can also be cases where a node works towards one logical interface
internally, which is then adapted one or more times until it reaches the
real interface such as with levels of tunneling.

And finally, we should not rule out that other wireless networks could
control the link layer signalling from the network instead of from the
terminal.  

In all of these cases, there are reasons to have additional information
important for the wireless operation available from the application
level QoS interface, and possibly carried in the IP level QoS protocol.
I do agree though that dependent on the exact scenario, this information
may not need to be transmitted over the wireless link.
/brian

On Thu, 2002-02-21 at 01:18, Hancock, Robert wrote:
> Hi Jukka, Gabor,
> 
> On the UDP-lite issue, my understanding is that UDP-lite only tells you that some of the packet is checksum protected and some isn't. The sophistication of signalling required for full UEP (e.g. to support AMR codec operation) is much greater. I guess if you had UEP QoS signalling you wouldn't need UDP-lite, you could just switch the checksum off altogether (at least for IPv4).
> 
> I was more concerned about whether the scenario as presented really justifies the need for wireless-related parameters at all. It seems to concentrate on the case where the wireless link is the last hop, directly connected to the node where the end application is running. In that case, it's clear that good quality IP QoS (fine grained, efficient, local etc.) is important, more so than in fixed networks. I think it's less clear that the IP layer signalling needs to have link (or 'link-ish') parameters in it. After all, the link layers already have their own signalling, and can tune the link to the required QoS even more tightly.
> 
> It's true that if applications use the IntServ classes to request QoS from their network stack, these classes need to be extended with wireless hints. But that's a comment on the deficiency of basing inter-layer interfaces on protocols, not a requirement to extend the protocol itself.
> 
> One reason we thought to be very careful here was that if you have wireless-related parameters being exchanged at both IP (RSVP) and link layers, it might be hard for independent implementors of each end to work out which layer to use for negotiation and in which order, and which layer was in charge. This was raised after SLC as an open issue on the list, but the argument wasn't really clear (partly my fault).
> 
> I think there _is_ actually a good case for having wireless related parameters, but that the justifying scenario is where the wireless link is 'interior' (e.g. 3G mobile acting as a wireless router for a local subnet), but in that case you might need take into account other considerations as well. Then you need to get the wireless-related information from the application into the router. But in either case, we need to have a clear model of how the link layer negotiation interacts with the IP layer negotiation.
> 
> Or did I miss something?
> 
> Robert H.
> 
> > -----Original Message-----
> > From: Jukka Manner [mailto:jmanner@cs.Helsinki.FI]
> > Sent: 20 February 2002 12:00
> > To: Gabor Fodor
> > Cc: nsis@ietf.org
> > Subject: [NSIS] A few comments to
> > draft-fodor-reqts-cellular-netwks-00.txt
> > 
> > 
> > 
> > 	Hi,
> > 
> > 	As I read the draft, two requirements left me wondering:
> > 
> > 	R2: how does this match with the UDP-lite proposal, 
> > where the UDP
> > header indicates the need for UEP. Thus, does the QoS primitives /
> > signalling need to indicate the need for UEP? If the 
> > transport protocol
> > does not support UEP, you won't get the packet sent to/accepted at the
> > receiver. Also, you don't even need any QoS mechanism to use UDP-lite.
> > 
> > 	R3: you seem to assume that doing bi-directional resource 
> > allocations also implies that routing is symmetric for uplink and 
> > downlink. Since IP routing is asymmetric, I doubt that bi-directional 
> > reservations are possible with a single mechanism, but rather 
> > imply that 
> > there must be separate signalling for the two directions. 
> > Thus, eg. RSVP 
> > makes it possible to have asymmetric reservations on the two 
> > directions.
> > 
> > 	Cheers,
> > 
> > 	Jukka
> > 
> > 
> > _______________________________________________
> > nsis mailing list
> > nsis@ietf.org
> > https://www1.ietf.org/mailman/listinfo/nsis
> > 
> 
> ----
> 

> 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.



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



From daemon@optimus.ietf.org  Thu Feb 21 04: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 EAA11371
	for <nsis-archive@odin.ietf.org>; Thu, 21 Feb 2002 04:05:59 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id EAA05638
	for nsis-archive@odin.ietf.org; Thu, 21 Feb 2002 04:06: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 EAA05500;
	Thu, 21 Feb 2002 04:03: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 EAA05460
	for <nsis@optimus.ietf.org>; Thu, 21 Feb 2002 04:03:21 -0500 (EST)
Received: from penguin-ext.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 EAA11337
	for <nsis@ietf.org>; Thu, 21 Feb 2002 04:03:18 -0500 (EST)
Received: from esealnt406.al.sw.ericsson.se (ESEALNT406.al.sw.ericsson.se [153.88.251.29])
	by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g1L92nB25626
	for <nsis@ietf.org>; Thu, 21 Feb 2002 10:02:49 +0100 (MET)
Received: FROM esealnt746.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Thu Feb 21 10:02:49 2002 +0100
Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <YHLJQ9BH>; Thu, 21 Feb 2002 10:02:03 +0100
Message-ID: <E244E44D6AB85E40AEEF7EAABE3545FA8234BC@enleent104.nl.eu.ericsson.se>
From: "Georgios Karagiannis (ELN)" <Georgios.Karagiannis@eln.ericsson.se>
To: "'Hancock, Robert'" <robert.hancock@roke.co.uk>,
        NSIS Mailing List
	 <nsis@ietf.org>
Subject: RE: [NSIS] Scenario for IP telephony (is about to become: signall
	 ing on or off the data path, again...)
Date: Thu, 21 Feb 2002 10:02:42 +0100
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 EAA05463
Sender: nsis-admin@ietf.org
Errors-To: nsis-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Next Steps in Signaling <nsis.ietf.org>
X-BeenThere: nsis@ietf.org
Content-Transfer-Encoding: 8bit

Hi Robert

Regarding your following remark:
[RH]> I also found that scenario interesting, especially as it 
[RH]> provides some structured thinking on the scalability issues, 
[RH]> like what information we would like/need to be able to ignore 
[RH]> and where. So more scenarios which tell us about aggregation 
[RH]> requirements (and how faithfully flows within aggregates 
[RH]> need to be treated) are certainly important.

I think you refer to the draft "NSIS QoS Signalling Requirements"
located at:
http://search.ietf.org/internet-drafts/draft-partain-nsis-requirements-00.txt

Yes, I agree with your remark, the goal of structuring the QoS requirements
is exactly the goal you mentioned in your remark!

Best Regards,
Georgios


-----Original Message-----
From: Hancock, Robert [mailto:robert.hancock@roke.co.uk]
Sent: dinsdag 19 februari 2002 22:23
To: Marcus Brunner; NSIS Mailing List
Subject: RE: [NSIS] Scenario for IP telephony (is about to become:
signall ing on or off the data path, again...)


Marcus,

I also found that scenario interesting, especially as it provides some structured thinking on the scalability issues, like what information we would like/need to be able to ignore and where. So more scenarios which tell us about aggregation requirements (and how faithfully flows within aggregates need to be treated) are certainly important.



If we generalise the scenario the way you are suggesting, I guess this will bring the signalling on/off data path question back to life. The characteristic of the PSTN gateway that seems to be emphasised in the draft is that it is the traffic source/sink. On the other hand, a SIP server might be nowhere near the traffic path (a server doing call redirection might easily not even be in the same administrative domain as any of the traffic).

I like the flexibility to support off-path signalling, but this seems to be going a bit far. Or are you suggesting less general situations like in a small corporate network where simple IP phones know that they have a local SIP server which they can cede QoS negotiation responsibility to?

Robert H.

> -----Original Message-----
> From: Marcus Brunner [mailto:brunner@ccrle.nec.de]
> Sent: 18 February 2002 02:28
> To: NSIS Mailing List
> Subject: [NSIS] Scenario for IP telephony
> 
> 
> I have shortly looked it over David and Co´s draft and found 
> the scenario on 
> QoS signaling between PSTN gateways and backbone routers particularly 
> interesting.
> 
> However IMHO the scenario could be broadend to something like 
> "IP telephony 
> signaling server to network QoS signaling" not only including 
> PSTN signaling 
> servers, but SIP servers as well. Opinions?
> 
> 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
> 

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



From daemon@optimus.ietf.org  Thu Feb 21 06:46: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 GAA13517
	for <nsis-archive@odin.ietf.org>; Thu, 21 Feb 2002 06:46:08 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id GAA14468
	for nsis-archive@odin.ietf.org; Thu, 21 Feb 2002 06:46:10 -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 GAA14386;
	Thu, 21 Feb 2002 06:43: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 GAA14355
	for <nsis@optimus.ietf.org>; Thu, 21 Feb 2002 06:43:43 -0500 (EST)
Received: from aifhs8.alcatel.fr (una200.alcatel.fr [212.208.74.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13493
	for <nsis@ietf.org>; Thu, 21 Feb 2002 06:43:40 -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 MAA06608;
        Thu, 21 Feb 2002 12:43:00 +0100 (MET)
Received: from alcatel.fr ([139.54.208.111])
          by frmail30.netfr.alcatel.fr (Lotus Domino Release 5.0.8)
          with ESMTP id 2002022112425915:2600 ;
          Thu, 21 Feb 2002 12:42:59 +0100 
Message-ID: <3C74DDBA.FA75ED79@alcatel.fr>
Date: Thu, 21 Feb 2002 12:44:58 +0100
Organization: Alcatel
X-Mailer: Mozilla 4.78 [fr] (Windows NT 5.0; U)
X-Accept-Language: fr
MIME-Version: 1.0
To: Marcus Brunner <brunner@ccrle.nec.de>
CC: NSIS Mailing List <nsis@ietf.org>
Subject: Re: [NSIS] Scenario for IP telephony
References: <1013999259.3c70669bf0f89@citadel.mobility.ccrle.nec.de>
X-MIMETrack: Itemize by SMTP Server on FRMAIL30/FR/ALCATEL(Release 5.0.8 |June 18, 2001) at
 02/21/2002 12:42:59,
	Serialize by Router on FRMAIL30/FR/ALCATEL(Release 5.0.8 |June 18, 2001) at
 02/21/2002 12:43:00,
	Serialize complete at 02/21/2002 12:43:00
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 GAA14356
Sender: nsis-admin@ietf.org
Errors-To: nsis-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Next Steps in Signaling <nsis.ietf.org>
X-BeenThere: nsis@ietf.org
Content-Transfer-Encoding: 8bit



Marcus Brunner a écrit :
> 
> I have shortly looked it over David and Co´s draft and found the scenario on
> QoS signaling between PSTN gateways and backbone routers particularly
> interesting.
> 
> However IMHO the scenario could be broadend to something like "IP telephony
> signaling server to network QoS signaling" not only including PSTN signaling
> servers, but SIP servers as well. Opinions?
>


I support the idea to think about SIP needs for NSIS. My guess is that
SIP based services will be the killer app for NSIS. That is why we
should think in priority about what can be asked by a SIP user agent for
making NSIS. Then we will know how to make NSIS well suited for SIP.
For instance, multimedia SIP users usually have two microflows (voice
and video). There is also an idea in SIP/SDP called grouping of media
flows: two micro flows can be used alternative by a terminal, for
example when the access network allows always one voice codec, but not
always a better voice codec using more bandwidth. 
And if the 2 microflow follow the same path, one network can request to
a transit network QoS for these microflows at the same time. 

This lead me to two new requirements for NSIS: it should be possible for
a user to request at the same time two (or more) QoS for two (or more)
microflows (especially if they have the same destination/origination
adresses), or even the same QoS that will be shared by two microflows.



-- 
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  Thu Feb 21 06:49: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 GAA13590
	for <nsis-archive@odin.ietf.org>; Thu, 21 Feb 2002 06:49:49 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id GAA14609
	for nsis-archive@odin.ietf.org; Thu, 21 Feb 2002 06:49: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 GAA14545;
	Thu, 21 Feb 2002 06:47: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 GAA14510
	for <nsis@optimus.ietf.org>; Thu, 21 Feb 2002 06:47:39 -0500 (EST)
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 GAA13535
	for <nsis@ietf.org>; Thu, 21 Feb 2002 06:47:35 -0500 (EST)
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.1.0/Switch-2.1.0) with ESMTP id g1LBm5i25206
	for <nsis@ietf.org>; Thu, 21 Feb 2002 13:48:05 +0200 (EET)
Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T59355b2925ac158f2116f@esvir01nok.ntc.nokia.com>;
 Thu, 21 Feb 2002 13:47:36 +0200
Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779);
	 Thu, 21 Feb 2002 13:47:35 +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] Scenario for IP telephony
Date: Thu, 21 Feb 2002 13:47:35 +0200
Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC649B6@esebe004.NOE.Nokia.com>
Thread-Topic: [NSIS] Scenario for IP telephony
Thread-Index: AcG6zSReFeWMRGRsTZSzL/BdaafZggAAAeZA
To: <Alban.Couturier@alcatel.fr>, <brunner@ccrle.nec.de>
Cc: <nsis@ietf.org>
X-OriginalArrivalTime: 21 Feb 2002 11:47:36.0057 (UTC) FILETIME=[8E3DEE90:01C1BACD]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id GAA14511
Sender: nsis-admin@ietf.org
Errors-To: nsis-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Next Steps in Signaling <nsis.ietf.org>
X-BeenThere: nsis@ietf.org
Content-Transfer-Encoding: 8bit

Hi all,

> I support the idea to think about SIP needs for NSIS. My guess is that
> SIP based services will be the killer app for NSIS. That is why we
> should think in priority about what can be asked by a SIP 
> user agent for making NSIS. 

Just to nip this in the bud, please refer to this document:

http://search.ietf.org/internet-drafts/draft-rosenberg-sip-unify-00.txt

My understanding is that this will be incorporated into the SIP-bis draft.
My general feeling is that the UNIFY draft (along with this draft)
http://search.ietf.org/internet-drafts/draft-ietf-sip-manyfolks-resource-03.txt
will be the primary way in which SIP can interact with QoS.

John

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



From daemon@optimus.ietf.org  Thu Feb 21 06:54: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 GAA13624
	for <nsis-archive@odin.ietf.org>; Thu, 21 Feb 2002 06:54:11 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id GAA14754
	for nsis-archive@odin.ietf.org; Thu, 21 Feb 2002 06:54: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 GAA14692;
	Thu, 21 Feb 2002 06:51: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 GAA14664
	for <nsis@optimus.ietf.org>; Thu, 21 Feb 2002 06:51:37 -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 GAA13611
	for <nsis@ietf.org>; Thu, 21 Feb 2002 06:51:33 -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.1.0/Switch-2.1.0) with ESMTP id g1LBphZ27598
	for <nsis@ietf.org>; Thu, 21 Feb 2002 13:51:43 +0200 (EET)
Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T59355ec9b2ac158f242fb@esvir04nok.ntc.nokia.com>;
 Thu, 21 Feb 2002 13:51:33 +0200
Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779);
	 Thu, 21 Feb 2002 13:51:33 +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] Scenario for IP telephony
Date: Thu, 21 Feb 2002 13:51:33 +0200
Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC649B7@esebe004.NOE.Nokia.com>
Thread-Topic: [NSIS] Scenario for IP telephony
Thread-Index: AcG6zSReFeWMRGRsTZSzL/BdaafZggAAJMSQ
To: <Alban.Couturier@alcatel.fr>, <brunner@ccrle.nec.de>
Cc: <nsis@ietf.org>
X-OriginalArrivalTime: 21 Feb 2002 11:51:33.0609 (UTC) FILETIME=[1BD57D90:01C1BACE]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id GAA14665
Sender: nsis-admin@ietf.org
Errors-To: nsis-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Next Steps in Signaling <nsis.ietf.org>
X-BeenThere: nsis@ietf.org
Content-Transfer-Encoding: 8bit

Hi Alban,

> This lead me to two new requirements for NSIS: it should be 
> possible for
> a user to request at the same time two (or more) QoS for two (or more)
> microflows (especially if they have the same destination/origination
> adresses), or even the same QoS that will be shared by two microflows.

Question to the working group on terminology.  Should we discuss
microflows or should we discuss sessions?  I'm a bit split on which
term is better.  

However, I think the requirement could be reworded to be:

 The NSIS protocol should be able to request QoS for different
 applications or different instances of the same application.

John

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



From daemon@optimus.ietf.org  Thu Feb 21 07:12: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 HAA14457
	for <nsis-archive@odin.ietf.org>; Thu, 21 Feb 2002 07:12:18 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id HAA15961
	for nsis-archive@odin.ietf.org; Thu, 21 Feb 2002 07:12:20 -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 HAA15877;
	Thu, 21 Feb 2002 07:10:04 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA15845
	for <nsis@optimus.ietf.org>; Thu, 21 Feb 2002 07:10:02 -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 HAA14435
	for <nsis@ietf.org>; Thu, 21 Feb 2002 07:09:59 -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 g1LCARj08350;
	Thu, 21 Feb 2002 13:10:27 +0100 (CET)
Received: by citadel.mobility.ccrle.nec.de (Postfix on SuSE eMail Server 2.0, from userid 30)
	id 88445C06C; Thu, 21 Feb 2002 13:09:16 +0100 (CET)
To: john.loughney@nokia.com
Subject: req to reqest QoS for more than one session at once (was RE: [NSIS] Scenario for IP telephony)
Message-ID: <1014293356.3c74e36c798d7@citadel.mobility.ccrle.nec.de>
Date: Thu, 21 Feb 2002 13:09:16 +0100 (CET)
From: Marcus Brunner <brunner@ccrle.nec.de>
Cc: Alban.Couturier@alcatel.fr, brunner@ccrle.nec.de, nsis@ietf.org
References: <0C1353ABB1DEB74DB067ADFF749C4EEFC649B7@esebe004.NOE.Nokia.com>
In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEFC649B7@esebe004.NOE.Nokia.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
User-Agent: IMP/PHP IMAP webmail program 2.2.3
X-Originating-IP: 192.168.102.83
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 <nsis.ietf.org>
X-BeenThere: nsis@ietf.org
Content-Transfer-Encoding: 8bit

I prefer the term session.


So the requirement:
The NSIS protocol should be able to request QoS for more than one
session at once. The sessions might originate at different applications or 
different instances of the same application, or the same appication. However, 
the data path MUST be the same, and the whole request MUST be granted at once 
or denyed at once.

Opinions?

Marcus

Zitiere john.loughney@nokia.com:

> Hi Alban,
> 
> > This lead me to two new requirements for NSIS: it should be 
> > possible for
> > a user to request at the same time two (or more) QoS for two (or
> more)
> > microflows (especially if they have the same destination/origination
> > adresses), or even the same QoS that will be shared by two
> microflows.
> 
> Question to the working group on terminology.  Should we discuss
> microflows or should we discuss sessions?  I'm a bit split on which
> term is better.  
> 
> However, I think the requirement could be reworded to be:
> 
>  The NSIS protocol should be able to request QoS for different
>  applications or different instances of the same application.
> 
> John
> 
> 



-------
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 Feb 21 07:16: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 HAA14647
	for <nsis-archive@odin.ietf.org>; Thu, 21 Feb 2002 07:16:55 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id HAA16252
	for nsis-archive@odin.ietf.org; Thu, 21 Feb 2002 07:16: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 HAA16078;
	Thu, 21 Feb 2002 07:14: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 HAA16042
	for <nsis@optimus.ietf.org>; Thu, 21 Feb 2002 07:14:16 -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 HAA14559
	for <nsis@ietf.org>; Thu, 21 Feb 2002 07:14:12 -0500 (EST)
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.1.0/Switch-2.1.0) with ESMTP id g1LCEMZ13434
	for <nsis@ietf.org>; Thu, 21 Feb 2002 14:14:22 +0200 (EET)
Received: from esebh003.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T5935738837ac158f22119@esvir02nok.ntc.nokia.com> for <nsis@ietf.org>;
 Thu, 21 Feb 2002 14:14:13 +0200
Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779);
	 Thu, 21 Feb 2002 14:14:12 +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"
Date: Thu, 21 Feb 2002 14:14:12 +0200
Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC649BB@esebe004.NOE.Nokia.com>
Thread-Topic: req to reqest QoS for more than one session at once (was RE: [NSIS] Scenario for IP telephony)
Thread-Index: AcG60LIoCDSzyL2TRNCBjB2aJMgjswAABDgw
To: <nsis@ietf.org>
X-OriginalArrivalTime: 21 Feb 2002 12:14:13.0188 (UTC) FILETIME=[4634C840:01C1BAD1]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id HAA16043
Subject: [NSIS] NSIS session in Minneapolis
Sender: nsis-admin@ietf.org
Errors-To: nsis-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Next Steps in Signaling <nsis.ietf.org>
X-BeenThere: nsis@ietf.org
Content-Transfer-Encoding: 8bit

Hello,

According the an updated scedule, we will be meeting on Tueday morning.
Any request for discussion time at the session, please email me with
the topic / Internet Draft name as well as how much time you require.

I suspect the bulk of our time should be spent on discussing the 
Requirements Draft.  

Additionally, remember that tomorrow is the deadline for all new
Internet Drafts to be submitted.

cheers,
John

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



From daemon@optimus.ietf.org  Thu Feb 21 07:29: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 HAA14891
	for <nsis-archive@odin.ietf.org>; Thu, 21 Feb 2002 07:29:20 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id HAA16868
	for nsis-archive@odin.ietf.org; Thu, 21 Feb 2002 07:29: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 HAA16771;
	Thu, 21 Feb 2002 07:26: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 HAA16683
	for <nsis@optimus.ietf.org>; Thu, 21 Feb 2002 07:26:41 -0500 (EST)
Received: from penguin-ext.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 HAA14846
	for <nsis@ietf.org>; Thu, 21 Feb 2002 07:26:37 -0500 (EST)
Received: from esealnt406.al.sw.ericsson.se (ESEALNT406.al.sw.ericsson.se [153.88.251.29])
	by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g1LCQ6B13365
	for <nsis@ietf.org>; Thu, 21 Feb 2002 13:26:06 +0100 (MET)
Received: FROM esealnt746.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Thu Feb 21 13:26:06 2002 +0100
Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <YHLJRAM2>; Thu, 21 Feb 2002 13:26:05 +0100
Message-ID: <E244E44D6AB85E40AEEF7EAABE3545FA8234C2@enleent104.nl.eu.ericsson.se>
From: "Georgios Karagiannis (ELN)" <Georgios.Karagiannis@eln.ericsson.se>
To: "'Marcus Brunner'" <brunner@ccrle.nec.de>
Cc: Alban.Couturier@alcatel.fr, nsis@ietf.org
Subject: RE: req to reqest QoS for more than one session at once (was RE: 
	[NSIS] Scenario for IP telephony)
Date: Thu, 21 Feb 2002 13:26:02 +0100
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 <nsis.ietf.org>
X-BeenThere: nsis@ietf.org

Hi Marcus

Do you mean that the same QoS request message
will signal QoS information to the network related to
more than one flow IDs?

I really do not know if this will make the NSIS protocol 
more efficient, but probably it will make it more complex!

Alban could you please motivate this requirement in more detail?

Best regards,
Georgios



-----Original Message-----
From: Marcus Brunner [mailto:brunner@ccrle.nec.de]
Sent: donderdag 21 februari 2002 13:09
To: john.loughney@nokia.com
Cc: Alban.Couturier@alcatel.fr; brunner@ccrle.nec.de; nsis@ietf.org
Subject: req to reqest QoS for more than one session at once (was RE:
[NSIS] Scenario for IP telephony)


I prefer the term session.


So the requirement:
The NSIS protocol should be able to request QoS for more than one
session at once. The sessions might originate at different applications or 
different instances of the same application, or the same appication. However, 
the data path MUST be the same, and the whole request MUST be granted at once 
or denyed at once.

Opinions?

Marcus

Zitiere john.loughney@nokia.com:

> Hi Alban,
> 
> > This lead me to two new requirements for NSIS: it should be 
> > possible for
> > a user to request at the same time two (or more) QoS for two (or
> more)
> > microflows (especially if they have the same destination/origination
> > adresses), or even the same QoS that will be shared by two
> microflows.
> 
> Question to the working group on terminology.  Should we discuss
> microflows or should we discuss sessions?  I'm a bit split on which
> term is better.  
> 
> However, I think the requirement could be reworded to be:
> 
>  The NSIS protocol should be able to request QoS for different
>  applications or different instances of the same application.
> 
> John
> 
> 



-------
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

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



From daemon@optimus.ietf.org  Thu Feb 21 07:37: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 HAA15047
	for <nsis-archive@odin.ietf.org>; Thu, 21 Feb 2002 07:37:58 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id HAA17602
	for nsis-archive@odin.ietf.org; Thu, 21 Feb 2002 07:38: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 HAA17547;
	Thu, 21 Feb 2002 07:35:40 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA17514
	for <nsis@optimus.ietf.org>; Thu, 21 Feb 2002 07:35:37 -0500 (EST)
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 HAA15004
	for <nsis@ietf.org>; Thu, 21 Feb 2002 07:35:33 -0500 (EST)
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);
	 Thu, 21 Feb 2002 13:35:35 +0100
content-class: urn:content-classes:message
Subject: RE: req to reqest QoS for more than one session at once (was RE: [NSIS] Scenario for IP telephony)
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Date: Thu, 21 Feb 2002 13:35:32 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
Message-ID: <1BF8A5964E4EFA41A094B835FCA7129110CB9E@TMS041MB.tcad.telia.se>
Thread-Topic: req to reqest QoS for more than one session at once (was RE: [NSIS] Scenario for IP telephony)
Thread-Index: AcG60OJS2aTxJvKuRRa5JoiCy17vOgAAV45Q
To: <brunner@ccrle.nec.de>, <john.loughney@nokia.com>
Cc: <Alban.Couturier@alcatel.fr>, <nsis@ietf.org>
X-OriginalArrivalTime: 21 Feb 2002 12:35:35.0166 (UTC) FILETIME=[425319E0:01C1BAD4]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id HAA17515
Sender: nsis-admin@ietf.org
Errors-To: nsis-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Next Steps in Signaling <nsis.ietf.org>
X-BeenThere: nsis@ietf.org
Content-Transfer-Encoding: 8bit

Marcus, 

> I prefer the term session.
> 
> 
> So the requirement:
> The NSIS protocol should be able to request QoS for more than one
> session at once. The sessions might originate at different 
> applications or 
> different instances of the same application, or the same 
> appication. However, 
> the data path MUST be the same, and the whole request MUST be 
> granted at once 
> or denyed at once.
> 
> Opinions?
Assume that the instantiation of the nsis signaling in this case will be an end-terminal. 

In this case the requirement would state that the end terminal must know that the data path is the same for all micro-flows, ie that no load balancing or anything is happening in the network. This is impossible for the end-terminal to know. I understand why you would like to state such a requirement but I do not see how you could implement it.

An alternativ is for the network to take care of the problem, which forces complexity in the network (as Georgios indicated as well). Another alternative is to force per-microflow signaling (which we probably want to avoid). And yet another, to accept that the host does not know the path and the network does not want the compexity to split and merge signaling packets and thus accept that the signaling and data path is not the same. With all the implications this have.

Anders

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



From daemon@optimus.ietf.org  Thu Feb 21 07:43: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 HAA15175
	for <nsis-archive@odin.ietf.org>; Thu, 21 Feb 2002 07:43:04 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id HAA17810
	for nsis-archive@odin.ietf.org; Thu, 21 Feb 2002 07:43: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 HAA17711;
	Thu, 21 Feb 2002 07:40:52 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA17680
	for <nsis@optimus.ietf.org>; Thu, 21 Feb 2002 07:40:50 -0500 (EST)
Received: from aifhs8.alcatel.fr (una200.alcatel.fr [212.208.74.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15120
	for <nsis@ietf.org>; Thu, 21 Feb 2002 07:40:47 -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 NAA14818;
        Thu, 21 Feb 2002 13:40:10 +0100 (MET)
Received: from alcatel.fr ([139.54.208.111])
          by frmail30.netfr.alcatel.fr (Lotus Domino Release 5.0.8)
          with ESMTP id 2002022113400958:2872 ;
          Thu, 21 Feb 2002 13:40:09 +0100 
Message-ID: <3C74EB21.7FDCC865@alcatel.fr>
Date: Thu, 21 Feb 2002 13:42:09 +0100
Organization: Alcatel
X-Mailer: Mozilla 4.78 [fr] (Windows NT 5.0; U)
X-Accept-Language: fr
MIME-Version: 1.0
To: Marcus Brunner <brunner@ccrle.nec.de>,
        "Georgios Karagiannis (ELN)" <Georgios.Karagiannis@eln.ericsson.se>
Cc: john.loughney@nokia.com, nsis@ietf.org
References: <0C1353ABB1DEB74DB067ADFF749C4EEFC649B7@esebe004.NOE.Nokia.com> <1014293356.3c74e36c798d7@citadel.mobility.ccrle.nec.de>
X-MIMETrack: Itemize by SMTP Server on FRMAIL30/FR/ALCATEL(Release 5.0.8 |June 18, 2001) at
 02/21/2002 13:40:09,
	Serialize by Router on FRMAIL30/FR/ALCATEL(Release 5.0.8 |June 18, 2001) at
 02/21/2002 13:40:10,
	Serialize complete at 02/21/2002 13:40:10
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 HAA17681
Subject: [NSIS] Re: req to reqest QoS for more than one session at once (was RE: [NSIS]
 Scenario for IP telephony)
Sender: nsis-admin@ietf.org
Errors-To: nsis-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Next Steps in Signaling <nsis.ietf.org>
X-BeenThere: nsis@ietf.org
Content-Transfer-Encoding: 8bit


Hello Marcus , John, and Georgios

If this is only a question of wording, agreement should come fast.

Marcus Brunner a écrit :
> 
> I prefer the term session.

Agreed, by anyhow, I think definition session could be usefull (Anyway,
what I would like is that an NSIS session can be an RTP session)

> 
> So the requirement:
> The NSIS protocol should be able to request QoS for more than one
> session at once. The sessions might originate at different applications or
> different instances of the same application, or the same appication. However,
> the data path MUST be the same, and the whole request MUST be granted at once
> or denyed at once.

Yes, the last sentence sounds good to me. This is a good motivation for
grouping requests. 
Marcus, don't you think we could have a parameter saying that the
request is "transactional" as you propose, or not? But I agree inserting
this option complexify again a little bit the requirements (and maybe
the protocol)


Why not? Because I see advantages just in grouping requests, and here is
my answer to Georgios. The main task of a QoS controller is to check if
there is bandwith for sessions. It must see where there are possible
bandwidth shortages, and to forward the request to another QoS
Controller if needed.
If the two flows goes in the same directions, there are chances that
checking the possible QoS shortages will be in the same ressources, and
the request will be forward to the same QoS controller. I see here a lot
of common tasks in the handling of the grouped request. So this
requirement is good for the QoS initiator (if it is SIP aware, it is
simpler), and also enhance the efficiency of the request processing. The
SIP QoS initiator will get its answer back quickly.



> Opinions?
> 
> Marcus
> 
> Zitiere john.loughney@nokia.com:
> 
> > Hi Alban,
> >
> > > This lead me to two new requirements for NSIS: it should be
> > > possible for
> > > a user to request at the same time two (or more) QoS for two (or
> > more)
> > > microflows (especially if they have the same destination/origination
> > > adresses), or even the same QoS that will be shared by two
> > microflows.
> >
> > Question to the working group on terminology.  Should we discuss
> > microflows or should we discuss sessions?  I'm a bit split on which
> > term is better.
> >
> > However, I think the requirement could be reworded to be:
> >
> >  The NSIS protocol should be able to request QoS for different
> >  applications or different instances of the same application.
> >
> > John
> >
> >
> 
> -------
> Marcus Brunner
> Network Labs
> NEC Europe Ltd
> Heidelberg, Germany
> 
> E-Mail: brunner@ccrle.nec.de
> WWW: www.brubers.org/marcus

-- 
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  Thu Feb 21 07:56: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 HAA15575
	for <nsis-archive@odin.ietf.org>; Thu, 21 Feb 2002 07:56:17 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id HAA18412
	for nsis-archive@odin.ietf.org; Thu, 21 Feb 2002 07:56:20 -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 HAA18324;
	Thu, 21 Feb 2002 07:53:20 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA18297
	for <nsis@optimus.ietf.org>; Thu, 21 Feb 2002 07:53:17 -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 HAA15497
	for <nsis@ietf.org>; Thu, 21 Feb 2002 07:53:13 -0500 (EST)
Received: from irams1.ira.uka.de ([129.13.10.5])
	by iraun2.uka.de with esmtp (Exim 3.30 #7 (Debian))
	id 16dsin-0002mW-00; Thu, 21 Feb 2002 13:53:13 +0100
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 16dsin-0005mF-00; Thu, 21 Feb 2002 13:53:13 +0100
Received: from i72pc127.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 g1LCrDW12290;
	Thu, 21 Feb 2002 13:53:13 +0100
Message-Id: <200202211253.g1LCrDW12290@i72pc127.tm.uka.de>
X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4+dev
To: Marcus Brunner <brunner@ccrle.nec.de>
Cc: nsis@ietf.org
Subject: Re: req to reqest QoS for more than one session at once (was RE: [NSIS] Scenario for IP telephony) 
In-Reply-To: Your message of "Thu, 21 Feb 2002 13:09:16 +0100."
             <1014293356.3c74e36c798d7@citadel.mobility.ccrle.nec.de> 
References: <0C1353ABB1DEB74DB067ADFF749C4EEFC649B7@esebe004.NOE.Nokia.com>  <1014293356.3c74e36c798d7@citadel.mobility.ccrle.nec.de> 
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Date: Thu, 21 Feb 2002 13:53:13 +0100
From: Roland Bless <bless@tm.uka.de>
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 <nsis.ietf.org>
X-BeenThere: nsis@ietf.org
Content-Transfer-Encoding: 8bit

Hi Marcus,

> So the requirement:
> The NSIS protocol should be able to request QoS for more than one
> session at once. The sessions might originate at different applications or 
> different instances of the same application, or the same appication. However, 
> the data path MUST be the same, and the whole request MUST be granted at once 
> or denyed at once.
> 
> Opinions?

I think it would be better to keep the protocol simple and let the end
systems decide what a failed reservation request means in relation to
other respective requests. Your suggested AND operation on successful
reservation is just one possible scenario. In others you might request
resources for an audio flow and a video flow, but if the latter
fails you'll be happy get the audio stream at least. Moreover, doesn't
it require to have a centralized instance for signaling (disallowing
an application level library implementation for the signaling protocol) 
when requests for different applications should be aggregated into one 
single request (this is also a very application-specific case)?

I'm also not sure about the requirement that the data path should be the
same. The paths could be different as long as your flows' QoS
requirements are met (thinking of applying QoS routing methods etc.).

IMHO it is a good point to apply the end-to-end arguments in system
design here and keep complexity out of the network control plane.
Let's concentrate on making signaling fast and scalable.

Just my 2 cents.

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 Feb 21 08:02: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 IAA15770
	for <nsis-archive@odin.ietf.org>; Thu, 21 Feb 2002 08:02:18 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id IAA19159
	for nsis-archive@odin.ietf.org; Thu, 21 Feb 2002 08:02: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 HAA18642;
	Thu, 21 Feb 2002 07:59: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 HAA18610
	for <nsis@optimus.ietf.org>; Thu, 21 Feb 2002 07:59:41 -0500 (EST)
Received: from penguin-ext.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 HAA15688
	for <nsis@ietf.org>; Thu, 21 Feb 2002 07:59:28 -0500 (EST)
Received: from esealnt406.al.sw.ericsson.se (ESEALNT406.al.sw.ericsson.se [153.88.251.29])
	by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g1LCwuB10725
	for <nsis@ietf.org>; Thu, 21 Feb 2002 13:58:56 +0100 (MET)
Received: FROM esealnt747.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Thu Feb 21 13:58:56 2002 +0100
Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <YHKTQJJ0>; Thu, 21 Feb 2002 13:58:55 +0100
Message-ID: <E244E44D6AB85E40AEEF7EAABE3545FA8234C3@enleent104.nl.eu.ericsson.se>
From: "Georgios Karagiannis (ELN)" <Georgios.Karagiannis@eln.ericsson.se>
To: "'Alban.Couturier@alcatel.fr'" <Alban.Couturier@alcatel.fr>,
        Marcus Brunner <brunner@ccrle.nec.de>
Cc: john.loughney@nokia.com, nsis@ietf.org
Subject: RE: req to reqest QoS for more than one session at once (was RE: 
	[NSIS]  Scenario for IP telephony)
Date: Thu, 21 Feb 2002 13:58:51 +0100
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 HAA18613
Sender: nsis-admin@ietf.org
Errors-To: nsis-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Next Steps in Signaling <nsis.ietf.org>
X-BeenThere: nsis@ietf.org
Content-Transfer-Encoding: 8bit

Hi Alban

Regarding the motivation you just gave!
I think you could achieve the same results by
just sending two (or more) independent QoS requests.
In this way each QoS signaling procedure 
it will be much more simple and will be processed much more 
faster. I also think that the completion of the 
session (that should relate two or more flow IDs) will
also be completed much faster in the way that I described above
than in the way you described.

Best Regards,
Georgios

-----Original Message-----
From: Alban.Couturier@alcatel.fr [mailto:Alban.Couturier@alcatel.fr]
Sent: donderdag 21 februari 2002 13:42
To: Marcus Brunner; Georgios Karagiannis (ELN)
Cc: john.loughney@nokia.com; nsis@ietf.org
Subject: Re: req to reqest QoS for more than one session at once (was
RE: [NSIS] Scenario for IP telephony)



Hello Marcus , John, and Georgios

If this is only a question of wording, agreement should come fast.

Marcus Brunner a écrit :
> 
> I prefer the term session.

Agreed, by anyhow, I think definition session could be usefull (Anyway,
what I would like is that an NSIS session can be an RTP session)

> 
> So the requirement:
> The NSIS protocol should be able to request QoS for more than one
> session at once. The sessions might originate at different applications or
> different instances of the same application, or the same appication. However,
> the data path MUST be the same, and the whole request MUST be granted at once
> or denyed at once.

Yes, the last sentence sounds good to me. This is a good motivation for
grouping requests. 
Marcus, don't you think we could have a parameter saying that the
request is "transactional" as you propose, or not? But I agree inserting
this option complexify again a little bit the requirements (and maybe
the protocol)


Why not? Because I see advantages just in grouping requests, and here is
my answer to Georgios. The main task of a QoS controller is to check if
there is bandwith for sessions. It must see where there are possible
bandwidth shortages, and to forward the request to another QoS
Controller if needed.
If the two flows goes in the same directions, there are chances that
checking the possible QoS shortages will be in the same ressources, and
the request will be forward to the same QoS controller. I see here a lot
of common tasks in the handling of the grouped request. So this
requirement is good for the QoS initiator (if it is SIP aware, it is
simpler), and also enhance the efficiency of the request processing. The
SIP QoS initiator will get its answer back quickly.



> Opinions?
> 
> Marcus
> 
> Zitiere john.loughney@nokia.com:
> 
> > Hi Alban,
> >
> > > This lead me to two new requirements for NSIS: it should be
> > > possible for
> > > a user to request at the same time two (or more) QoS for two (or
> > more)
> > > microflows (especially if they have the same destination/origination
> > > adresses), or even the same QoS that will be shared by two
> > microflows.
> >
> > Question to the working group on terminology.  Should we discuss
> > microflows or should we discuss sessions?  I'm a bit split on which
> > term is better.
> >
> > However, I think the requirement could be reworded to be:
> >
> >  The NSIS protocol should be able to request QoS for different
> >  applications or different instances of the same application.
> >
> > John
> >
> >
> 
> -------
> Marcus Brunner
> Network Labs
> NEC Europe Ltd
> Heidelberg, Germany
> 
> E-Mail: brunner@ccrle.nec.de
> WWW: www.brubers.org/marcus

-- 
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  Thu Feb 21 08:13: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 IAA16003
	for <nsis-archive@odin.ietf.org>; Thu, 21 Feb 2002 08:13:47 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id IAA19595
	for nsis-archive@odin.ietf.org; Thu, 21 Feb 2002 08:13: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 IAA19446;
	Thu, 21 Feb 2002 08:11: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 IAA19413
	for <nsis@optimus.ietf.org>; Thu, 21 Feb 2002 08:11:10 -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 IAA15954
	for <nsis@ietf.org>; Thu, 21 Feb 2002 08:11:02 -0500 (EST)
Received: from irams1.ira.uka.de ([129.13.10.5])
	by iraun2.uka.de with esmtp (Exim 3.30 #7 (Debian))
	id 16dszX-0002rk-00; Thu, 21 Feb 2002 14:10:31 +0100
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 16dszW-0006H7-00; Thu, 21 Feb 2002 14:10:30 +0100
Received: from i72pc127.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 g1LDAUW12417;
	Thu, 21 Feb 2002 14:10:30 +0100
Message-Id: <200202211310.g1LDAUW12417@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: brunner@ccrle.nec.de, john.loughney@nokia.com, Alban.Couturier@alcatel.fr,
        nsis@ietf.org
Subject: Re: req to reqest QoS for more than one session at once (was RE: [NSIS] Scenario for IP telephony) 
In-Reply-To: Message from Anders.P.Bergsten@telia.se 
   of "Thu, 21 Feb 2002 13:35:32 +0100." <1BF8A5964E4EFA41A094B835FCA7129110CB9E@TMS041MB.tcad.telia.se> 
References: <1BF8A5964E4EFA41A094B835FCA7129110CB9E@TMS041MB.tcad.telia.se> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 21 Feb 2002 14:10:30 +0100
From: Roland Bless <bless@tm.uka.de>
Sender: nsis-admin@ietf.org
Errors-To: nsis-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Next Steps in Signaling <nsis.ietf.org>
X-BeenThere: nsis@ietf.org


> An alternativ is for the network to take care of the problem, which
> forces complexity in the network (as Georgios indicated as well).

I agree.

> Another alternative is to force per-microflow signaling (which we
> probably want to avoid). And yet another, to accept that the host does

Per-microflow signaling is possible when you use aggregation of
reservations. In this case the number of reservation states and
signaling requests can be reduced for all ASs which are covered by the
aggregate (except the aggregate start- and endpoints) to a scalable
amount. However, this requires nsis support for reservation aggregation.

> not know the path and the network does not want the compexity to split
> and merge signaling packets and thus accept that the signaling and data
> path is not the same. With all the implications this have.

Right. I also thought about the idea some time ago. But processing
logically dependent requests by the control entities requires a lot
of extra complexity. So let the end-systems implement their 
application-specific logic for deciding about the results of 
multiple requests.

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 Feb 21 08:28: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 IAA16371
	for <nsis-archive@odin.ietf.org>; Thu, 21 Feb 2002 08:28:11 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id IAA20254
	for nsis-archive@odin.ietf.org; Thu, 21 Feb 2002 08:28:14 -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 IAA19992;
	Thu, 21 Feb 2002 08:25: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 IAA19965
	for <nsis@optimus.ietf.org>; Thu, 21 Feb 2002 08:25:22 -0500 (EST)
Received: from vs.informatik.uni-ulm.de (vs.informatik.uni-ulm.de [134.60.77.243])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16247
	for <nsis@ietf.org>; Thu, 21 Feb 2002 08:25:12 -0500 (EST)
Received: from lamagra (lamagra.informatik.uni-ulm.de [134.60.77.31])
	by vs.informatik.uni-ulm.de (8.11.0/8.11.0/SuSE Linux 8.11.0-0.4) with SMTP id g1LDQ4v07028;
	Thu, 21 Feb 2002 14:26:04 +0100
X-Authentication-Warning: vs.informatik.uni-ulm.de: Host lamagra.informatik.uni-ulm.de [134.60.77.31] claimed to be lamagra
Message-ID: <017b01c1badd$433fadb0$1f4d3c86@informatik.uniulm.de>
From: "Andreas Kassler" <kassler@informatik.uni-ulm.de>
To: <Alban.Couturier@alcatel.fr>, "Marcus Brunner" <brunner@ccrle.nec.de>
Cc: "NSIS Mailing List" <nsis@ietf.org>
References: <1013999259.3c70669bf0f89@citadel.mobility.ccrle.nec.de> <3C74DDBA.FA75ED79@alcatel.fr>
Subject: Re: [NSIS] Scenario for IP telephony
Date: Thu, 21 Feb 2002 14:40:02 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
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: 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 <nsis.ietf.org>
X-BeenThere: nsis@ietf.org
Content-Transfer-Encoding: 8bit


----- Original Message -----
From: <Alban.Couturier@alcatel.fr>
To: "Marcus Brunner" <brunner@ccrle.nec.de>
Cc: "NSIS Mailing List" <nsis@ietf.org>
Sent: Thursday, February 21, 2002 12:44 PM
Subject: Re: [NSIS] Scenario for IP telephony


>
>
> Marcus Brunner a écrit :
> >
> > I have shortly looked it over David and Co´s draft and found the
scenario on
> > QoS signaling between PSTN gateways and backbone routers particularly
> > interesting.
> >
> > However IMHO the scenario could be broadend to something like "IP
telephony
> > signaling server to network QoS signaling" not only including PSTN
signaling
> > servers, but SIP servers as well. Opinions?
> >
>
>
> I support the idea to think about SIP needs for NSIS. My guess is that
> SIP based services will be the killer app for NSIS. That is why we
> should think in priority about what can be asked by a SIP user agent for
> making NSIS. Then we will know how to make NSIS well suited for SIP.

I also support the idea that it should be possible to reserve the ressources
for SIP sessions using NSIS. However, there is more out there than SIP.
But I don't like the idea that NSIS should be designed to fit nicely to SIP.
We should rather think about requirements that come from SIP. When you look
at
the manyfolks draft
(http://search.ietf.org/internet-drafts/draft-ietf-sip-manyfolks-resource-03
.txt),
which is the base for SIP - network ressource interaction, it says:

   "A User Agent with an active session that desires to change the media
   flows prepares an SDP message body for the re-INVITE describing the
   desired QoS and security preconditions for the revised media flows
   and the desired directions.  The procedures for the re-INVITE, and
   the subsequent message exchanges, are identical to those of an
   initial INVITE. "

So the idea is to use re-Invite, and update your reservations, when the
sender switches
to new media coding. Having multiple QoS levels per flow would complicate
the things,
because you have to signal to which QoS levels to switch. Nevertheless, this
is then
a question how the QoS parameters look like, that the app requests, either a
single value,
some sort of interval, or a set of intervals.

Andreas.

> For instance, multimedia SIP users usually have two microflows (voice
> and video). There is also an idea in SIP/SDP called grouping of media
> flows: two micro flows can be used alternative by a terminal, for
> example when the access network allows always one voice codec, but not
> always a better voice codec using more bandwidth.
> And if the 2 microflow follow the same path, one network can request to
> a transit network QoS for these microflows at the same time.

>
> This lead me to two new requirements for NSIS: it should be possible for
> a user to request at the same time two (or more) QoS for two (or more)
> microflows (especially if they have the same destination/origination
> adresses), or even the same QoS that will be shared by two microflows.
>
>
>
> --
> 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  Thu Feb 21 09:17: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 JAA17965
	for <nsis-archive@odin.ietf.org>; Thu, 21 Feb 2002 09:17:10 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id JAA23848
	for nsis-archive@odin.ietf.org; Thu, 21 Feb 2002 09:17: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 JAA23575;
	Thu, 21 Feb 2002 09:10:19 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA23541
	for <nsis@optimus.ietf.org>; Thu, 21 Feb 2002 09:10:17 -0500 (EST)
Received: from aifhs8.alcatel.fr (una200.alcatel.fr [212.208.74.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17822
	for <nsis@ietf.org>; Thu, 21 Feb 2002 09:10:13 -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 PAA08058;
        Thu, 21 Feb 2002 15:08:59 +0100 (MET)
Received: from alcatel.fr ([139.54.208.111])
          by frmail30.netfr.alcatel.fr (Lotus Domino Release 5.0.8)
          with ESMTP id 2002022115085813:3499 ;
          Thu, 21 Feb 2002 15:08:58 +0100 
Message-ID: <3C74FFF1.36290CF1@alcatel.fr>
Date: Thu, 21 Feb 2002 15:10:57 +0100
Organization: Alcatel
X-Mailer: Mozilla 4.78 [fr] (Windows NT 5.0; U)
X-Accept-Language: fr
MIME-Version: 1.0
To: Roland Bless <bless@tm.uka.de>
Cc: Marcus Brunner <brunner@ccrle.nec.de>, nsis@ietf.org
References: <0C1353ABB1DEB74DB067ADFF749C4EEFC649B7@esebe004.NOE.Nokia.com>  <1014293356.3c74e36c798d7@citadel.mobility.ccrle.nec.de> <200202211253.g1LCrDW12290@i72pc127.tm.uka.de>
X-MIMETrack: Itemize by SMTP Server on FRMAIL30/FR/ALCATEL(Release 5.0.8 |June 18, 2001) at
 02/21/2002 15:08:58,
	Serialize by Router on FRMAIL30/FR/ALCATEL(Release 5.0.8 |June 18, 2001) at
 02/21/2002 15:08:59,
	Serialize complete at 02/21/2002 15:08:59
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 JAA23542
Subject: [NSIS] Re: req to reqest QoS for more than one session at once (was RE: [NSIS]
 Scenario for IP telephony)
Sender: nsis-admin@ietf.org
Errors-To: nsis-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Next Steps in Signaling <nsis.ietf.org>
X-BeenThere: nsis@ietf.org
Content-Transfer-Encoding: 8bit

Hello Roland,

Roland Bless a écrit :
> 
> Hi Marcus,
> 
> > So the requirement:
> > The NSIS protocol should be able to request QoS for more than one
> > session at once. The sessions might originate at different applications or
> > different instances of the same application, or the same appication. However,
> > the data path MUST be the same, and the whole request MUST be granted at once
> > or denyed at once.
> >
> > Opinions?
> 
> I think it would be better to keep the protocol simple and let the end
> systems decide what a failed reservation request means in relation to
> other respective requests. Your suggested AND operation on successful
> reservation is just one possible scenario. In others you might request
> resources for an audio flow and a video flow, but if the latter
> fails you'll be happy get the audio stream at least. Moreover, doesn't
> it require to have a centralized instance for signaling (disallowing
> an application level library implementation for the signaling protocol)
> when requests for different applications should be aggregated into one
> single request (this is also a very application-specific case)?

The only requirement I see is the SIp terminal to know the two sessions
can be requested at once. But I don't see a consequence forcing a
centralized instance for signalling in the network.


 
> I'm also not sure about the requirement that the data path should be the
> same. The paths could be different as long as your flows' QoS
> requirements are met (thinking of applying QoS routing methods etc.).
 
> IMHO it is a good point to apply the end-to-end arguments in system
> design here and keep complexity out of the network control plane.
> Let's concentrate on making signaling fast and scalable.

If the two streams come from the same IP adress and go the same IP
adress, and in case the network is making diffserv in a usual way, I see
the burden of the signalling divided by two, and the processing of the
request factorized.
If there is QoS based routing, and if the two streams does not follow
the same path, yes the signalling should be splitted. Does this implies
to bring a lot of complexity? My guess is that it is not so much.

Regards

-- 
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  Thu Feb 21 10:10: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 KAA19674
	for <nsis-archive@odin.ietf.org>; Thu, 21 Feb 2002 10:10:33 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id KAA27432
	for nsis-archive@odin.ietf.org; Thu, 21 Feb 2002 10:10:37 -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 KAA27373;
	Thu, 21 Feb 2002 10:08: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 KAA27346
	for <nsis@optimus.ietf.org>; Thu, 21 Feb 2002 10:08:19 -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 KAA19607
	for <nsis@ietf.org>; Thu, 21 Feb 2002 10:08:11 -0500 (EST)
Received: from irams1.ira.uka.de ([129.13.10.5])
	by iraun2.uka.de with esmtp (Exim 3.30 #7 (Debian))
	id 16dupN-0003WF-00; Thu, 21 Feb 2002 16:08:09 +0100
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 16dupN-0001D1-00; Thu, 21 Feb 2002 16:08:09 +0100
Received: from i72pc127.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 g1LF88W13307;
	Thu, 21 Feb 2002 16:08:08 +0100
Message-Id: <200202211508.g1LF88W13307@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: Marcus Brunner <brunner@ccrle.nec.de>, nsis@ietf.org
Subject: Re: req to reqest QoS for more than one session at once (was RE: [NSIS] Scenario for IP telephony) 
In-Reply-To: Message from Alban.Couturier@alcatel.fr 
   of "Thu, 21 Feb 2002 15:10:57 +0100." <3C74FFF1.36290CF1@alcatel.fr> 
References: <0C1353ABB1DEB74DB067ADFF749C4EEFC649B7@esebe004.NOE.Nokia.com> <1014293356.3c74e36c798d7@citadel.mobility.ccrle.nec.de> <200202211253.g1LCrDW12290@i72pc127.tm.uka.de>  <3C74FFF1.36290CF1@alcatel.fr> 
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Date: Thu, 21 Feb 2002 16:08:08 +0100
From: Roland Bless <bless@tm.uka.de>
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 <nsis.ietf.org>
X-BeenThere: nsis@ietf.org
Content-Transfer-Encoding: 8bit

Hello Alban,

> The only requirement I see is the SIp terminal to know the two sessions
> can be requested at once. But I don't see a consequence forcing a
> centralized instance for signalling in the network.

Sorry, maybe I wasn't clear enough. I meant the _implementation_ within
a terminal or end-system. If the signaling protocol instance in the
terminal/system should group reservation requests of different
applications into a single request, no application can use an own nsis
protocol instance (e.g. as library implementation) independently of 
others.

> > IMHO it is a good point to apply the end-to-end arguments in system
> > design here and keep complexity out of the network control plane.
> > Let's concentrate on making signaling fast and scalable.
> 
> If the two streams come from the same IP adress and go the same IP
> adress, and in case the network is making diffserv in a usual way, I see
> the burden of the signalling divided by two, and the processing of the
> request factorized.
> If there is QoS based routing, and if the two streams does not follow
> the same path, yes the signalling should be splitted. Does this implies
> to bring a lot of complexity? My guess is that it is not so much.

Yes, IMO it does mean a lot of complexity, because the split point has
to keep track of the splitted (now) "independent" signaling transactions
and it must somehow combine the different answers back into the third
original transaction. The complexity lies in the possibility of
combining the answers in case of unsuccessful or failed requests. Marcus
suggested an AND operator. But others such as OR might also be useful.
So if you want the signaling to be flexible, we have to support an
arbitrary number of grouped sessions/flows and also several logical
operators expressing the logical relationship between the sessions
(which have to be specified in the signaling message, too!). 

I understand that it would be nice for a user/terminal to send only one
request. But in case of a negative response the application may have to
try a new request with a subset of the previous flows anyway. So let
the terminal send "independent" requests instead and let the
application decide about the further actions according to its own logic
in case of failure of any request.

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 Feb 21 10:41: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 KAA20836
	for <nsis-archive@odin.ietf.org>; Thu, 21 Feb 2002 10:41:19 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id KAA29668
	for nsis-archive@odin.ietf.org; Thu, 21 Feb 2002 10:41: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 KAA29593;
	Thu, 21 Feb 2002 10:40:08 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA29560
	for <nsis@optimus.ietf.org>; Thu, 21 Feb 2002 10:40:05 -0500 (EST)
Received: from aifhs8.alcatel.fr (una200.alcatel.fr [212.208.74.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20800
	for <nsis@ietf.org>; Thu, 21 Feb 2002 10:40:02 -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 QAA02812;
        Thu, 21 Feb 2002 16:38:41 +0100 (MET)
Received: from alcatel.fr ([139.54.208.111])
          by frmail30.netfr.alcatel.fr (Lotus Domino Release 5.0.8)
          with ESMTP id 2002022116383996:4242 ;
          Thu, 21 Feb 2002 16:38:39 +0100 
Message-ID: <3C7514F6.94A435DB@alcatel.fr>
Date: Thu, 21 Feb 2002 16:40:38 +0100
Organization: Alcatel
X-Mailer: Mozilla 4.78 [fr] (Windows NT 5.0; U)
X-Accept-Language: fr
MIME-Version: 1.0
To: Andreas Kassler <kassler@informatik.uni-ulm.de>
Cc: Marcus Brunner <brunner@ccrle.nec.de>, NSIS Mailing List <nsis@ietf.org>
Subject: Re: [NSIS] Scenario for IP telephony
References: <1013999259.3c70669bf0f89@citadel.mobility.ccrle.nec.de> <3C74DDBA.FA75ED79@alcatel.fr> <017b01c1badd$433fadb0$1f4d3c86@informatik.uniulm.de>
X-MIMETrack: Itemize by SMTP Server on FRMAIL30/FR/ALCATEL(Release 5.0.8 |June 18, 2001) at
 02/21/2002 16:38:39,
	Serialize by Router on FRMAIL30/FR/ALCATEL(Release 5.0.8 |June 18, 2001) at
 02/21/2002 16:38:44,
	Serialize complete at 02/21/2002 16:38:44
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 KAA29561
Sender: nsis-admin@ietf.org
Errors-To: nsis-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Next Steps in Signaling <nsis.ietf.org>
X-BeenThere: nsis@ietf.org
Content-Transfer-Encoding: 8bit

Hello Andreas,


Andreas Kassler a écrit :
> 
> ----- Original Message -----
> From: <Alban.Couturier@alcatel.fr>
> To: "Marcus Brunner" <brunner@ccrle.nec.de>
> Cc: "NSIS Mailing List" <nsis@ietf.org>
> Sent: Thursday, February 21, 2002 12:44 PM
> Subject: Re: [NSIS] Scenario for IP telephony
> 
> >
> >
> > Marcus Brunner a écrit :
> > >
> > > I have shortly looked it over David and Co´s draft and found the
> scenario on
> > > QoS signaling between PSTN gateways and backbone routers particularly
> > > interesting.
> > >
> > > However IMHO the scenario could be broadend to something like "IP
> telephony
> > > signaling server to network QoS signaling" not only including PSTN
> signaling
> > > servers, but SIP servers as well. Opinions?
> > >
> >
> >
> > I support the idea to think about SIP needs for NSIS. My guess is that
> > SIP based services will be the killer app for NSIS. That is why we
> > should think in priority about what can be asked by a SIP user agent for
> > making NSIS. Then we will know how to make NSIS well suited for SIP.
> 
> I also support the idea that it should be possible to reserve the ressources
> for SIP sessions using NSIS. However, there is more out there than SIP.
> But I don't like the idea that NSIS should be designed to fit nicely to SIP.

I just propose to the work group a requirement that is useful for SIP
users. But I agree that the NSIS protocol must not be done only for SIP
users.

> We should rather think about requirements that come from SIP. When you look
> at
> the manyfolks draft
> (http://search.ietf.org/internet-drafts/draft-ietf-sip-manyfolks-resource-03
> .txt),
> which is the base for SIP - network ressource interaction, it says:
> 
>    "A User Agent with an active session that desires to change the media
>    flows prepares an SDP message body for the re-INVITE describing the
>    desired QoS and security preconditions for the revised media flows
>    and the desired directions.  The procedures for the re-INVITE, and
>    the subsequent message exchanges, are identical to those of an
>    initial INVITE. "
> 
> So the idea is to use re-Invite, and update your reservations, when the
> sender switches
> to new media coding. Having multiple QoS levels per flow would complicate
> the things,
> because you have to signal to which QoS levels to switch. Nevertheless, this
> is then
> a question how the QoS parameters look like, that the app requests, either a
> single value,
> some sort of interval, or a set of intervals.

Andreas, I was refering to the SDP fid tag. This allow not to resend a
SIP invite each time your access network capacity changes (typically
when your radio access capacity changes during some handovers).    

Kind regards

-- 
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  Thu Feb 21 10:55: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 KAA21614
	for <nsis-archive@odin.ietf.org>; Thu, 21 Feb 2002 10:55:21 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id KAA00542
	for nsis-archive@odin.ietf.org; Thu, 21 Feb 2002 10:55: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 KAA00434;
	Thu, 21 Feb 2002 10:54: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 KAA00351
	for <nsis@optimus.ietf.org>; Thu, 21 Feb 2002 10:54:13 -0500 (EST)
Received: from aifhs8.alcatel.fr (una200.alcatel.fr [212.208.74.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21516
	for <nsis@ietf.org>; Thu, 21 Feb 2002 10:54:05 -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 QAA06599;
        Thu, 21 Feb 2002 16:53:01 +0100 (MET)
Received: from alcatel.fr ([139.54.208.111])
          by frmail30.netfr.alcatel.fr (Lotus Domino Release 5.0.8)
          with ESMTP id 2002022116525918:4369 ;
          Thu, 21 Feb 2002 16:52:59 +0100 
Message-ID: <3C751851.D3FF699A@alcatel.fr>
Date: Thu, 21 Feb 2002 16:54:57 +0100
Organization: Alcatel
X-Mailer: Mozilla 4.78 [fr] (Windows NT 5.0; U)
X-Accept-Language: fr
MIME-Version: 1.0
To: Roland Bless <bless@tm.uka.de>
Cc: Marcus Brunner <brunner@ccrle.nec.de>, nsis@ietf.org
References: <0C1353ABB1DEB74DB067ADFF749C4EEFC649B7@esebe004.NOE.Nokia.com> <1014293356.3c74e36c798d7@citadel.mobility.ccrle.nec.de> <200202211253.g1LCrDW12290@i72pc127.tm.uka.de>  <3C74FFF1.36290CF1@alcatel.fr> <200202211508.g1LF88W13307@i72pc127.tm.uka.de>
X-MIMETrack: Itemize by SMTP Server on FRMAIL30/FR/ALCATEL(Release 5.0.8 |June 18, 2001) at
 02/21/2002 16:52:59,
	Serialize by Router on FRMAIL30/FR/ALCATEL(Release 5.0.8 |June 18, 2001) at
 02/21/2002 16:53:00,
	Serialize complete at 02/21/2002 16:53:00
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 KAA00352
Subject: [NSIS] Re: req to reqest QoS for more than one session at once (was RE: [NSIS]
 Scenario for IP telephony)
Sender: nsis-admin@ietf.org
Errors-To: nsis-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Next Steps in Signaling <nsis.ietf.org>
X-BeenThere: nsis@ietf.org
Content-Transfer-Encoding: 8bit

Roland,

Roland Bless a écrit :
> 
> Hello Alban,
> 
> > The only requirement I see is the SIp terminal to know the two sessions
> > can be requested at once. But I don't see a consequence forcing a
> > centralized instance for signalling in the network.
> 
> Sorry, maybe I wasn't clear enough. I meant the _implementation_ within
> a terminal or end-system. If the signaling protocol instance in the
> terminal/system should group reservation requests of different
> applications into a single request, no application can use an own nsis
> protocol instance (e.g. as library implementation) independently of
> others.


A SIP application knowing the SDP knows the 2 or three microflows it
generates, and COULD signal it in  a grouped request. I don't claim it
is a SHOULD.
Other applications, especially sending flows in other directions don't
need share the signaling with the SIP application.  

> 
> > > IMHO it is a good point to apply the end-to-end arguments in system
> > > design here and keep complexity out of the network control plane.
> > > Let's concentrate on making signaling fast and scalable.
> >
> > If the two streams come from the same IP adress and go the same IP
> > adress, and in case the network is making diffserv in a usual way, I see
> > the burden of the signalling divided by two, and the processing of the
> > request factorized.
> > If there is QoS based routing, and if the two streams does not follow
> > the same path, yes the signalling should be splitted. Does this implies
> > to bring a lot of complexity? My guess is that it is not so much.
> 
> Yes, IMO it does mean a lot of complexity, because the split point has
> to keep track of the splitted (now) "independent" signaling transactions
> and it must somehow combine the different answers back into the third
> original transaction. The complexity lies in the possibility of
> combining the answers in case of unsuccessful or failed requests. Marcus
> suggested an AND operator. But others such as OR might also be useful.
> So if you want the signaling to be flexible, we have to support an
> arbitrary number of grouped sessions/flows and also several logical
> operators expressing the logical relationship between the sessions
> (which have to be specified in the signaling message, too!).

Well, Marcus suggested an AND inconditionnaly. This limits the problem.
We could also have a parameter in the signalling in order to choose if
this is an AND or an OR. May be this is too complex. But for me, this
was not as the fixed shared filters of RSVP  ;)
My proposition comes from SIP world: we have two, three, very seldomly
more, microflows coming from the same terminal, going to the same
destination. The fact there is one OR or AND (or always one AND) for
them gives a very simple formula.

But do you think that flows having the same origination and destination
IP adresses will be often separated in different routes? My guess is
that this will happen not so often. That is why I don't think my
proposition is not so complex.
 

 
> I understand that it would be nice for a user/terminal to send only one
> request. But in case of a negative response the application may have to
> try a new request with a subset of the previous flows anyway. So let
> the terminal send "independent" requests instead and let the
> application decide about the further actions according to its own logic
> in case of failure of any request.

It is a possibility. But for me, in 98% of the cases, it doubles
signaling and its processing, in the terminal and in the network.

Best regards,
-- 
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@ns.ietf.org  Thu Feb 21 23:27: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 XAA12996
	for <nsis-archive@odin.ietf.org>; Thu, 21 Feb 2002 23:27:54 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id XAA15293
	for nsis-archive@odin.ietf.org; Thu, 21 Feb 2002 23:27:58 -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 XAA15256;
	Thu, 21 Feb 2002 23:26:49 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA15223
	for <nsis@ns.ietf.org>; Thu, 21 Feb 2002 23:26:46 -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 XAA12966
	for <nsis@ietf.org>; Thu, 21 Feb 2002 23:26:41 -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 g1M4RDI12303
	for <nsis@ietf.org>; Fri, 22 Feb 2002 05:27:13 +0100 (CET)
Received: by citadel.mobility.ccrle.nec.de (Postfix on SuSE eMail Server 2.0, from userid 30)
	id B0179C040; Fri, 22 Feb 2002 05:25:56 +0100 (CET)
To: nsis@ietf.org
Message-ID: <1014351956.3c75c8549903a@citadel.mobility.ccrle.nec.de>
Date: Fri, 22 Feb 2002 05:25:56 +0100 (CET)
From: Marcus Brunner <brunner@ccrle.nec.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
User-Agent: IMP/PHP IMAP webmail program 2.2.3
X-Originating-IP: 192.168.102.83
Content-Transfer-Encoding: 8bit
Subject: [NSIS] Summary Req on QoS for more than one session at o
Sender: nsis-admin@ietf.org
Errors-To: nsis-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Next Steps in Signaling <nsis.ietf.org>
X-BeenThere: nsis@ietf.org
Content-Transfer-Encoding: 8bit

The voices I heard about allowing for grouping QoS requests for multiple flows 
together arre the following.

- the end terminal must know that the data path is the same for all micro-
flows/sessions/...

- a lot of common tasks in the handling of the grouped request. 

- let the end-systems decide what a failed reservation request 

- processing logically dependent requests by the control entities requires a lot
of extra complexity

I have not not see enough support for the requirement so I do not integrate it 
into the draft.

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@ns.ietf.org  Fri Feb 22 00:38: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 AAA14665
	for <nsis-archive@odin.ietf.org>; Fri, 22 Feb 2002 00:38:50 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id AAA17988
	for nsis-archive@odin.ietf.org; Fri, 22 Feb 2002 00:38: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 AAA17841;
	Fri, 22 Feb 2002 00:34: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 AAA17809
	for <nsis@ns.ietf.org>; Fri, 22 Feb 2002 00:34:11 -0500 (EST)
Received: from arb-exchange1.cetaceannetworks.com ([63.127.199.207])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14637
	for <nsis@ietf.org>; Fri, 22 Feb 2002 00:34:07 -0500 (EST)
Received: by mail.cetaceannetworks.com with Internet Mail Service (5.5.2653.19)
	id <1GGAPR2B>; Fri, 22 Feb 2002 00:30:16 -0500
Message-ID: <6D8664171C38D511B5AD0002B325CE6633ED69@mail.cetaceannetworks.com>
From: "Freytsis, Ilya" <ifreytsis@cetacean.com>
To: "'nsis@ietf.org'" <nsis@ietf.org>
Date: Fri, 22 Feb 2002 00:30:07 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [NSIS] req to reqest QoS for more than one session at once (was RE: [NSI
 S] Scenario for IP telephony)
Sender: nsis-admin@ietf.org
Errors-To: nsis-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Next Steps in Signaling <nsis.ietf.org>
X-BeenThere: nsis@ietf.org

Marcus,

I'd like to suggest different wording for your requirement:
NSIS protocol should allow requesting QoS for more than one session with the
same originating and terminating points within the same transaction.

I think this requirement should be review from the perspective how easy it
can be supported by various existing QoS mechanisms and base our judgment at
least on this analysis.

The statement about different applications can be understood in two ways:
1. There should be some sort of cross awareness between applications and
they will coordinate requests themselves. I think it is far beyond the
protocol requirement and probably unrealistic anyway
2. The protocol implementation can be smart enough to make this kind of
aggregation. This is a requirement for the implementation rather than
protocol and probably should not be discussed here.

I share the point of view that NSIS should not be influenced too much by any
single application protocol however hot and promising it may look right now
but be rather application (signaling) neutral.

Ilya

To: john.loughney@nokia.com
Subject: req to reqest QoS for more than one session at once (was RE: [NSIS]
Scenario for IP telephony)
Date: Thu, 21 Feb 2002 13:09:16 +0100 (CET)
From: Marcus Brunner <brunner@ccrle.nec.de>
Cc: Alban.Couturier@alcatel.fr, brunner@ccrle.nec.de, nsis@ietf.org

I prefer the term session.


So the requirement:
The NSIS protocol should be able to request QoS for more than one
session at once. The sessions might originate at different applications or 
different instances of the same application, or the same appication.
However, 
the data path MUST be the same, and the whole request MUST be granted at
once 
or denyed at once.

Opinions?

Marcus


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



From daemon@ns.ietf.org  Fri Feb 22 02:34: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 CAA23813
	for <nsis-archive@odin.ietf.org>; Fri, 22 Feb 2002 02:34:57 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id CAA02346
	for nsis-archive@odin.ietf.org; Fri, 22 Feb 2002 02:34:59 -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 CAA02287;
	Fri, 22 Feb 2002 02:33: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 CAA02256
	for <nsis@ns.ietf.org>; Fri, 22 Feb 2002 02:33:43 -0500 (EST)
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23796
	for <nsis@ietf.org>; Fri, 22 Feb 2002 02:33:39 -0500 (EST)
Received: from juniper.net (pptp133.static.jnpr.net [172.24.248.133])
	by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g1M7X9i62133;
	Thu, 21 Feb 2002 23:33:09 -0800 (PST)
	(envelope-from pingpan@juniper.net)
Message-ID: <3C75F49C.5040104@juniper.net>
Date: Thu, 21 Feb 2002 23:34:52 -0800
From: Ping Pan <pingpan@juniper.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1
X-Accept-Language: en-us
MIME-Version: 1.0
To: "Freytsis, Ilya" <ifreytsis@cetacean.com>
CC: "'nsis@ietf.org'" <nsis@ietf.org>
Subject: Re: [NSIS] req to reqest QoS for more than one session at once (was RE: [NSI S] Scenario for IP telephony)
References: <6D8664171C38D511B5AD0002B325CE6633ED69@mail.cetaceannetworks.com>
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 <nsis.ietf.org>
X-BeenThere: nsis@ietf.org
Content-Transfer-Encoding: 7bit

Freytsis, Ilya wrote:

> Marcus,
> 
> I'd like to suggest different wording for your requirement:
> NSIS protocol should allow requesting QoS for more than one session with the
> same originating and terminating points within the same transaction.
> 


Hi,

Just curious, what's the gain of setting up one reservation session for 
multiple application flows here? You may argue that one reservation is 
cheap to process compare with multiple reservation sessions. However, it 
looks to me that the application flows may be quite dynamic, then the 
reservation needs to be modified constantly anyway. As a result, I argue 
  that the processing overhead for supporting one-reservation-per-flow 
vs. one-reservation-per-multiple-flows would be pretty close.

The aggregation argument in NSIS is quite different from what we have 
seen in the backbone environment, where "static" reservations are 
established based on how the network providers are arranging their 
interval network resources. the "static" reservations that multiple 
flows can aggregate into don't change a lot (if ever), and will last for 
days and months. In the case of NSIS, the reservations are triggered by 
the applications and can be rather dynamic.

In conclusion, IMHO, one reservation per flow may not be as complex and 
expensive as people think.

> 
> I share the point of view that NSIS should not be influenced too much by any
> single application protocol however hot and promising it may look right now
> but be rather application (signaling) neutral.
> 


Excuse me. I had a conversation with a wise man the other day. He was 
telling me how some people work toward a technical solution: It's like 
making ice-cream cake in a very hot day. One approach is to argue how to 
make a perfect cake that everyone will like. The only problem is by the 
time it makes everybody happy, everything will melt. The other approach 
is to look at the customer's order, and make a cake!

Back to your application neutral solution, are you recommending to 
define a signaling protocol that is compatible for the past, the present 
and the future applications? ;-) I suggest the following: look where a 
signaling is needed (aka, who will use it and how it gets used), define 
and develop a workable solution real fast, and get it done. Would the 
solution be perfect? Well... the main thing is to make it working, not 
to debate it!

2 cents,


- Ping



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



From daemon@ns.ietf.org  Fri Feb 22 04:00: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 EAA24806
	for <nsis-archive@odin.ietf.org>; Fri, 22 Feb 2002 04:00:01 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id EAA06345
	for nsis-archive@odin.ietf.org; Fri, 22 Feb 2002 04:00:03 -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 DAA06285;
	Fri, 22 Feb 2002 03:58: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 DAA06256
	for <nsis@ns.ietf.org>; Fri, 22 Feb 2002 03:58:43 -0500 (EST)
Received: from mail.icu.ac.kr (mail.icu.ac.kr [210.107.128.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24759
	for <nsis@ietf.org>; Fri, 22 Feb 2002 03:58:39 -0500 (EST)
Received: from jkyoungxp (v33-184.icu.ac.kr [210.107.133.184])
	by mail.icu.ac.kr (8.11.0/8.11.0) with SMTP id g1M8pdM28421;
	Fri, 22 Feb 2002 17:51:39 +0900 (KST)
Message-ID: <002c01c1bb7f$130cef20$b8856bd2@jkyoungxp>
From: "Ki Young Jung" <jjungki@icu.ac.kr>
To: "Ping Pan" <pingpan@juniper.net>
Cc: <nsis@ietf.org>
References: <6D8664171C38D511B5AD0002B325CE6633ED69@mail.cetaceannetworks.com> <3C75F49C.5040104@juniper.net>
Subject: Re: [NSIS] req to reqest QoS for more than one session at once (was RE: [NSI S] Scenario for IP telephony)
Date: Fri, 22 Feb 2002 17:58:18 +0900
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 <nsis.ietf.org>
X-BeenThere: nsis@ietf.org
Content-Transfer-Encoding: 7bit

Hi, Ping.
First, please forgive my poor English.

I have different opinion with with you.

> Just curious, what's the gain of setting up one reservation session for
> multiple application flows here? You may argue that one reservation is
> cheap to process compare with multiple reservation sessions. However, it
> looks to me that the application flows may be quite dynamic, then the
> reservation needs to be modified constantly anyway. As a result, I argue
>  that the processing overhead for supporting one-reservation-per-flow
> vs. one-reservation-per-multiple-flows would be pretty close.

I think that making dynamic management with aggregated flow path whenever
a flow in that path is changed is somewhat overkilled work.
In backbone situation, if a flow need 500KB bandwidth in a path,
then we can make (or add)  2MB bandwidth in that path.
We can use residual 2MB with other 4 flow without additional signaling.
The amout of residual BW and signaling cose have a trade-off relation.

My opinion is that  we can use the benefit of aggregate flow management
in backbone network in the signaling view point and it should be considered
in this WG.

I expect the comment from anyone.

----------------------------------------------------
Ki Young Jung (jjungki@icu.ac.kr)
Information and Communications University(ICU)
Broadband Network Laboratory (http://bnlab.icu.ac.kr)
58-4 Hwaam-dong, Yusong-gu, Taejon, 305-732, KOREA
Tel)+82-42-866-6182, 016-370-1751 Fax)+82-42-866-6110


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



From daemon@ns.ietf.org  Fri Feb 22 04:06: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 EAA24854
	for <nsis-archive@odin.ietf.org>; Fri, 22 Feb 2002 04:06:42 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id EAA06901
	for nsis-archive@odin.ietf.org; Fri, 22 Feb 2002 04:06: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 EAA06865;
	Fri, 22 Feb 2002 04:05: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 EAA06837
	for <nsis@ns.ietf.org>; Fri, 22 Feb 2002 04:05:52 -0500 (EST)
Received: from penguin-ext.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 EAA24845
	for <nsis@ietf.org>; Fri, 22 Feb 2002 04:05:49 -0500 (EST)
Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62])
	by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g1M95KB13671
	for <nsis@ietf.org>; Fri, 22 Feb 2002 10:05:20 +0100 (MET)
Received: FROM esealnt746.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Fri Feb 22 10:05:20 2002 +0100
Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <YHLJR19R>; Fri, 22 Feb 2002 10:05:19 +0100
Message-ID: <E244E44D6AB85E40AEEF7EAABE3545FA8234CB@enleent104.nl.eu.ericsson.se>
From: "Georgios Karagiannis (ELN)" <Georgios.Karagiannis@eln.ericsson.se>
To: "'Marcus Brunner'" <brunner@ccrle.nec.de>, nsis@ietf.org
Subject: RE: [NSIS] Summary Req on QoS for more than one session at o
Date: Fri, 22 Feb 2002 10:04:46 +0100
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 <nsis.ietf.org>
X-BeenThere: nsis@ietf.org

Hi Marcus

I agree with your decision!

Best Regards,
Georgios

-----Original Message-----
From: Marcus Brunner [mailto:brunner@ccrle.nec.de]
Sent: vrijdag 22 februari 2002 5:26
To: nsis@ietf.org
Subject: [NSIS] Summary Req on QoS for more than one session at o


The voices I heard about allowing for grouping QoS requests for multiple flows 
together arre the following.

- the end terminal must know that the data path is the same for all micro-
flows/sessions/...

- a lot of common tasks in the handling of the grouped request. 

- let the end-systems decide what a failed reservation request 

- processing logically dependent requests by the control entities requires a lot
of extra complexity

I have not not see enough support for the requirement so I do not integrate it 
into the draft.

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

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



From daemon@ns.ietf.org  Fri Feb 22 04:44: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 EAA25263
	for <nsis-archive@odin.ietf.org>; Fri, 22 Feb 2002 04:44:19 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id EAA08890
	for nsis-archive@odin.ietf.org; Fri, 22 Feb 2002 04:44: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 EAA08756;
	Fri, 22 Feb 2002 04:42: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 EAA08723
	for <nsis@ns.ietf.org>; Fri, 22 Feb 2002 04:42:26 -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 EAA25222
	for <nsis@ietf.org>; Fri, 22 Feb 2002 04:42:22 -0500 (EST)
From: suresh.leroy@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 g1M9fs925217
	for <nsis@ietf.org>; Fri, 22 Feb 2002 10:41:54 +0100 (MET)
Received: from alcatel.be ([138.203.33.40])
          by bemail04.net.alcatel.be (Lotus Domino Release 5.0.8)
          with ESMTP id 2002022210415171:357 ;
          Fri, 22 Feb 2002 10:41:51 +0100 
Message-ID: <3C76125F.7029A634@alcatel.be>
Date: Fri, 22 Feb 2002 10:41:51 +0100
Organization: Alcatel
X-Mailer: Mozilla 4.72 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: nsis@ietf.org
Subject: Re: [NSIS] Scenario for IP telephony
References: <OF2C377856.08D437D7-ONC1256B67.0040D0EB@alcatel.be>
X-MIMETrack: Itemize by SMTP Server on BEMAIL04/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at
 02/22/2002 10:41:51,
	Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at
 02/22/2002 10:41:53,
	Serialize complete at 02/22/2002 10:41:53
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
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 <nsis.ietf.org>
X-BeenThere: nsis@ietf.org
Content-Transfer-Encoding: 7bit

Hi all,

One thing the refered SIP documents don't specify is the actual QoS to be used for
the media streams in a session.
The unify draft describes the negotiation of the media components and their
corresponding codecs.
The manyfolks draft provides a way to ensure the resources (QoS & security) are
available before accepting the session, what it doesn't mention is what QoS (level)

is needed.

Therefor we submitted yesterday a new draft (draft-bos-mmusic-sdpng-qos-00.txt) for
the
MMUSIC group describing QoS extensions for SDPng.
This QoS negotiation takes place prior to the QoS provisioning (NSIS protocol) so
the SDPng QoS negotiation occurs independently of and prior to the QoS
provisioning. The SDPng QoS information can be very usefull to know the QoS level
to be requested in for example the  'NSIS protocol'.

P.S.: I suppose the draft should be available soon on the IETF directories,
otherwise people who are interested
can always send me a mail.

Regards,
    Suresh

john.loughney@nokia.com wrote:

> Hi all,
>
> > I support the idea to think about SIP needs for NSIS. My guess is that
> > SIP based services will be the killer app for NSIS. That is why we
> > should think in priority about what can be asked by a SIP
> > user agent for making NSIS.
>
> Just to nip this in the bud, please refer to this document:
>
> http://search.ietf.org/internet-drafts/draft-rosenberg-sip-unify-00.txt
>
> My understanding is that this will be incorporated into the SIP-bis draft.
> My general feeling is that the UNIFY draft (along with this draft)
> http://search.ietf.org/internet-drafts/draft-ietf-sip-manyfolks-resource-03.txt
> will be the primary way in which SIP can interact with QoS.
>
> 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 Feb 22 08:03: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 IAA00320
	for <nsis-archive@odin.ietf.org>; Fri, 22 Feb 2002 08:03:10 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id IAA20455
	for nsis-archive@odin.ietf.org; Fri, 22 Feb 2002 08:03: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 HAA19839;
	Fri, 22 Feb 2002 07:56: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 HAA19807
	for <nsis@optimus.ietf.org>; Fri, 22 Feb 2002 07:56:34 -0500 (EST)
Received: from aifhs8.alcatel.fr (una200.alcatel.fr [212.208.74.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00135
	for <nsis@ietf.org>; Fri, 22 Feb 2002 07:56:26 -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 NAA29304;
        Fri, 22 Feb 2002 13:55:53 +0100 (MET)
Received: from alcatel.fr ([139.54.208.111])
          by frmail30.netfr.alcatel.fr (Lotus Domino Release 5.0.8)
          with ESMTP id 2002022213555239:2618 ;
          Fri, 22 Feb 2002 13:55:52 +0100 
Message-ID: <3C764051.51F08990@alcatel.fr>
Date: Fri, 22 Feb 2002 13:57:53 +0100
Organization: Alcatel
X-Mailer: Mozilla 4.78 [fr] (Windows NT 5.0; U)
X-Accept-Language: fr
MIME-Version: 1.0
To: Ping Pan <pingpan@juniper.net>
Cc: "Freytsis, Ilya" <ifreytsis@cetacean.com>,
        "'nsis@ietf.org'" <nsis@ietf.org>
Subject: Re: [NSIS] req to reqest QoS for more than one session at once (was RE: 
 [NSI S] Scenario for IP telephony)
References: <6D8664171C38D511B5AD0002B325CE6633ED69@mail.cetaceannetworks.com> <3C75F49C.5040104@juniper.net>
X-MIMETrack: Itemize by SMTP Server on FRMAIL30/FR/ALCATEL(Release 5.0.8 |June 18, 2001) at
 02/22/2002 13:55:52,
	Serialize by Router on FRMAIL30/FR/ALCATEL(Release 5.0.8 |June 18, 2001) at
 02/22/2002 13:55:53,
	Serialize complete at 02/22/2002 13:55:53
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 HAA19808
Sender: nsis-admin@ietf.org
Errors-To: nsis-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Next Steps in Signaling <nsis.ietf.org>
X-BeenThere: nsis@ietf.org
Content-Transfer-Encoding: 8bit

Hello Ping



I respect Marcus's decision, but would like to answer your question

Ping Pan a écrit :
> 
> Freytsis, Ilya wrote:
> 
> > Marcus,
> >
> > I'd like to suggest different wording for your requirement:
> > NSIS protocol should allow requesting QoS for more than one session with the
> > same originating and terminating points within the same transaction.
> >
> 
> Hi,
> 
> Just curious, what's the gain of setting up one reservation session for
> multiple application flows here? You may argue that one reservation is
> cheap to process compare with multiple reservation sessions. However, it
> looks to me that the application flows may be quite dynamic, then the
> reservation needs to be modified constantly anyway. As a result, I argue
>   that the processing overhead for supporting one-reservation-per-flow
> vs. one-reservation-per-multiple-flows would be pretty close.
> 

Application dynamicity depends on the time scale considered of course.
We could say a interractive multimedia call lasts something like 5
minutes, and could reach hours. For you, is is dynamic, or not? 
But anyway, a reservation for a session does not change previous
reservations, so they won't be modified constantly. 

If I send 3 reservations (audio, video and data), the third one being
rejected and then I cancel the two firsts, and then redo 3 other
reservations, this is a mess, and increases the signalling burden. There
would be in this case 2 simple use cases for the draft: simple
reservation, simple cancellation. But you see the scenario for SIP calls
would be complex, and requires multiple processings inside the network.
On the other hand, one reservation per multiple flow would give two
requests. 

I mean, this type of thinking was adopted in SIP/SDP: in a SIP
invitation, the whole multimedia session context is guathered in one
packet, instead of the verbose H.323 way of doing. But maybe thing that
applies for SIP are not so well suited for signalling...
And maybe my proposition was not a requirement, but an implementation
choice.


> The aggregation argument in NSIS is quite different from what we have
> seen in the backbone environment, where "static" reservations are
> established based on how the network providers are arranging their
> interval network resources. the "static" reservations that multiple
> flows can aggregate into don't change a lot (if ever), and will last for
> days and months. In the case of NSIS, the reservations are triggered by
> the applications and can be rather dynamic.
> 
> In conclusion, IMHO, one reservation per flow may not be as complex and
> expensive as people think.
>


Best regards

-- 
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 Feb 22 08:18: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 IAA00829
	for <nsis-archive@odin.ietf.org>; Fri, 22 Feb 2002 08:18:36 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id IAA21285
	for nsis-archive@odin.ietf.org; Fri, 22 Feb 2002 08:18: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 IAA20912;
	Fri, 22 Feb 2002 08:12:44 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA20877
	for <nsis@optimus.ietf.org>; Fri, 22 Feb 2002 08:12:42 -0500 (EST)
Received: from vs.informatik.uni-ulm.de (vs.informatik.uni-ulm.de [134.60.77.243])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00625
	for <nsis@ietf.org>; Fri, 22 Feb 2002 08:12:38 -0500 (EST)
Received: from lamagra (lamagra.informatik.uni-ulm.de [134.60.77.31])
	by vs.informatik.uni-ulm.de (8.11.0/8.11.0/SuSE Linux 8.11.0-0.4) with SMTP id g1MDDbv13793;
	Fri, 22 Feb 2002 14:13:37 +0100
X-Authentication-Warning: vs.informatik.uni-ulm.de: Host lamagra.informatik.uni-ulm.de [134.60.77.31] claimed to be lamagra
Message-ID: <032d01c1bba4$b2792900$1f4d3c86@informatik.uniulm.de>
From: "Andreas Kassler" <kassler@informatik.uni-ulm.de>
To: <Alban.Couturier@alcatel.fr>, "Ping Pan" <pingpan@juniper.net>
Cc: "Freytsis, Ilya" <ifreytsis@cetacean.com>, <nsis@ietf.org>
References: <6D8664171C38D511B5AD0002B325CE6633ED69@mail.cetaceannetworks.com> <3C75F49C.5040104@juniper.net> <3C764051.51F08990@alcatel.fr>
Subject: Re: [NSIS] req to reqest QoS for more than one session at once (was RE:  [NSI S] Scenario for IP telephony)
Date: Fri, 22 Feb 2002 14:27:38 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
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: 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 <nsis.ietf.org>
X-BeenThere: nsis@ietf.org
Content-Transfer-Encoding: 8bit

Hello Alban,

I would like to add here something:

> Hello Ping
>
>
>
> I respect Marcus's decision, but would like to answer your question
>
> Ping Pan a écrit :
> >
> > Freytsis, Ilya wrote:
> >
> > > Marcus,
> > >
> > > I'd like to suggest different wording for your requirement:
> > > NSIS protocol should allow requesting QoS for more than one session
with the
> > > same originating and terminating points within the same transaction.
> > >
> >
> > Hi,
> >
> > Just curious, what's the gain of setting up one reservation session for
> > multiple application flows here? You may argue that one reservation is
> > cheap to process compare with multiple reservation sessions. However, it
> > looks to me that the application flows may be quite dynamic, then the
> > reservation needs to be modified constantly anyway. As a result, I argue
> >   that the processing overhead for supporting one-reservation-per-flow
> > vs. one-reservation-per-multiple-flows would be pretty close.
> >
>
> Application dynamicity depends on the time scale considered of course.
> We could say a interractive multimedia call lasts something like 5
> minutes, and could reach hours. For you, is is dynamic, or not?
> But anyway, a reservation for a session does not change previous
> reservations, so they won't be modified constantly.

I slightly disagree. We have scenarios, for example video transmission, that
have very dynamic bandwidth
variation. There are several proposals how to implement this using for
example renegotiated CBR like
reservations, where you approximate the dynamic variation in bandwidth by
piecewise constant amount of
bandwidth. Clearly there is a tradeoff between re-negotiation interval and
accuracy. However what I want to
point out is that there might be situation where the reservations from the
endsystem point of view may be updated
frequently, say every 10 seconds. Consider a scene break with significant
amount of motion afterwards.
At least from the application point of view there should not be a
restriction on how frequently the app
wants to re-negotiate QoS for an already existing reservation.

>
> If I send 3 reservations (audio, video and data), the third one being
> rejected and then I cancel the two firsts, and then redo 3 other
> reservations, this is a mess, and increases the signalling burden. There

This is application strategy, right? If the applications wants to react in
this way, fine.
However, the application can react in any other way and say, ok, I'm
satisfied with audio alone.

> would be in this case 2 simple use cases for the draft: simple
> reservation, simple cancellation. But you see the scenario for SIP calls
> would be complex, and requires multiple processings inside the network.
> On the other hand, one reservation per multiple flow would give two
> requests.
>
> I mean, this type of thinking was adopted in SIP/SDP: in a SIP
> invitation, the whole multimedia session context is guathered in one
> packet, instead of the verbose H.323 way of doing. But maybe thing that
> applies for SIP are not so well suited for signalling...
> And maybe my proposition was not a requirement, but an implementation
> choice.
>


Just my two cents, Andreas.



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



From daemon@optimus.ietf.org  Fri Feb 22 10: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 KAA05211
	for <nsis-archive@odin.ietf.org>; Fri, 22 Feb 2002 10:14:44 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id KAA28510
	for nsis-archive@odin.ietf.org; Fri, 22 Feb 2002 10:14:36 -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 KAA28053;
	Fri, 22 Feb 2002 10:05: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 KAA27987
	for <nsis@optimus.ietf.org>; Fri, 22 Feb 2002 10:05:06 -0500 (EST)
Received: from arb-exchange1.cetaceannetworks.com ([63.127.199.215])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04873
	for <nsis@ietf.org>; Fri, 22 Feb 2002 10:05:00 -0500 (EST)
Received: by mail.cetaceannetworks.com with Internet Mail Service (5.5.2653.19)
	id <1GGAPRTK>; Fri, 22 Feb 2002 10:01:07 -0500
Message-ID: <6D8664171C38D511B5AD0002B325CE6633ED6A@mail.cetaceannetworks.com>
From: "Freytsis, Ilya" <ifreytsis@cetacean.com>
To: "'Ping Pan'" <pingpan@juniper.net>,
        "Freytsis, Ilya"
	 <ifreytsis@cetacean.com>
Cc: "'nsis@ietf.org'" <nsis@ietf.org>
Subject: RE: [NSIS] req to reqest QoS for more than one session at once (w
	as RE: [NSI S] Scenario for IP telephony)
Date: Fri, 22 Feb 2002 10:01:07 -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 <nsis.ietf.org>
X-BeenThere: nsis@ietf.org

Ping,

I have the same doubts that multiple reservations per transaction have any
advantage I've just found the previous wording not precise and confusing.

Ilya

-----Original Message-----
From: Ping Pan [mailto:pingpan@juniper.net]
Sent: Friday, February 22, 2002 2:35 AM
To: Freytsis, Ilya
Cc: 'nsis@ietf.org'
Subject: Re: [NSIS] req to reqest QoS for more than one session at once (was
RE: [NSI S] Scenario for IP telephony)

Freytsis, Ilya wrote:

> Marcus,
>
> I'd like to suggest different wording for your requirement:
> NSIS protocol should allow requesting QoS for more than one session with
the
> same originating and terminating points within the same transaction.
>


Hi,

Just curious, what's the gain of setting up one reservation session for
multiple application flows here? You may argue that one reservation is
cheap to process compare with multiple reservation sessions. However, it
looks to me that the application flows may be quite dynamic, then the
reservation needs to be modified constantly anyway. As a result, I argue
  that the processing overhead for supporting one-reservation-per-flow
vs. one-reservation-per-multiple-flows would be pretty close.

The aggregation argument in NSIS is quite different from what we have
seen in the backbone environment, where "static" reservations are
established based on how the network providers are arranging their
interval network resources. the "static" reservations that multiple
flows can aggregate into don't change a lot (if ever), and will last for
days and months. In the case of NSIS, the reservations are triggered by
the applications and can be rather dynamic.

In conclusion, IMHO, one reservation per flow may not be as complex and
expensive as people think.

>
> I share the point of view that NSIS should not be influenced too much by
any
> single application protocol however hot and promising it may look right
now
> but be rather application (signaling) neutral.
>


Excuse me. I had a conversation with a wise man the other day. He was
telling me how some people work toward a technical solution: It's like
making ice-cream cake in a very hot day. One approach is to argue how to
make a perfect cake that everyone will like. The only problem is by the
time it makes everybody happy, everything will melt. The other approach
is to look at the customer's order, and make a cake!

Back to your application neutral solution, are you recommending to
define a signaling protocol that is compatible for the past, the present
and the future applications? ;-) I suggest the following: look where a
signaling is needed (aka, who will use it and how it gets used), define
and develop a workable solution real fast, and get it done. Would the
solution be perfect? Well... the main thing is to make it working, not
to debate it!

2 cents,


- Ping

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



From daemon@optimus.ietf.org  Fri Feb 22 10:36: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 KAA06154
	for <nsis-archive@odin.ietf.org>; Fri, 22 Feb 2002 10:36:22 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id KAA29765
	for nsis-archive@odin.ietf.org; Fri, 22 Feb 2002 10:36: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 KAA28861;
	Fri, 22 Feb 2002 10:27: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 KAA28828
	for <nsis@optimus.ietf.org>; Fri, 22 Feb 2002 10:27:05 -0500 (EST)
Received: from aifhs8.alcatel.fr (una200.alcatel.fr [212.208.74.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05771
	for <nsis@ietf.org>; Fri, 22 Feb 2002 10:26:55 -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 PAA19023;
        Fri, 22 Feb 2002 15:34:56 +0100 (MET)
Received: from alcatel.fr ([139.54.208.111])
          by frmail30.netfr.alcatel.fr (Lotus Domino Release 5.0.8)
          with ESMTP id 2002022215345404:3452 ;
          Fri, 22 Feb 2002 15:34:54 +0100 
Message-ID: <3C765785.896F5F0B@alcatel.fr>
Date: Fri, 22 Feb 2002 15:36:53 +0100
Organization: Alcatel
X-Mailer: Mozilla 4.78 [fr] (Windows NT 5.0; U)
X-Accept-Language: fr
MIME-Version: 1.0
To: Andreas Kassler <kassler@informatik.uni-ulm.de>
Cc: Ping Pan <pingpan@juniper.net>, "Freytsis, Ilya" <ifreytsis@cetacean.com>,
        nsis@ietf.org
Subject: Re: [NSIS] req to reqest QoS for more than one session at once (was RE:  
 [NSI S] Scenario for IP telephony)
References: <6D8664171C38D511B5AD0002B325CE6633ED69@mail.cetaceannetworks.com> <3C75F49C.5040104@juniper.net> <3C764051.51F08990@alcatel.fr> <032d01c1bba4$b2792900$1f4d3c86@informatik.uniulm.de>
X-MIMETrack: Itemize by SMTP Server on FRMAIL30/FR/ALCATEL(Release 5.0.8 |June 18, 2001) at
 02/22/2002 15:34:54,
	Serialize by Router on FRMAIL30/FR/ALCATEL(Release 5.0.8 |June 18, 2001) at
 02/22/2002 15:34:56,
	Serialize complete at 02/22/2002 15:34:56
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 KAA28829
Sender: nsis-admin@ietf.org
Errors-To: nsis-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Next Steps in Signaling <nsis.ietf.org>
X-BeenThere: nsis@ietf.org
Content-Transfer-Encoding: 8bit

Hello Andreas,

Thank for your feedback.
First, I apologize for talking about something which is now obsoleted in
the discussion. 

Andreas Kassler a écrit :

> > Application dynamicity depends on the time scale considered of course.
> > We could say a interractive multimedia call lasts something like 5
> > minutes, and could reach hours. For you, is is dynamic, or not?
> > But anyway, a reservation for a session does not change previous
> > reservations, so they won't be modified constantly.
> 
> I slightly disagree. We have scenarios, for example video transmission, that
> have very dynamic bandwidth
> variation. There are several proposals how to implement this using for
> example renegotiated CBR like
> reservations, where you approximate the dynamic variation in bandwidth by
> piecewise constant amount of
> bandwidth. Clearly there is a tradeoff between re-negotiation interval and
> accuracy. However what I want to
> point out is that there might be situation where the reservations from the
> endsystem point of view may be updated
> frequently, say every 10 seconds. Consider a scene break with significant
> amount of motion afterwards.
> At least from the application point of view there should not be a
> restriction on how frequently the app
> wants to re-negotiate QoS for an already existing reservation.


I don't see really the relationship with grouping of microflows, which
is an option, and doesn't prevent a user to modify only a part of the
group. It does not prevent people to use groups of one session, either. 
And again, if you want to update QoS for an RTP session, I don't see the
impact on the reservations for other RTP (or other) sessions, even if
they have been initiated in the same group. So you can send as many
requests as you want, update them etc, grouping of micro flows would
have been just an nice option that can help you, it would be never an
overhead (OK, the improbable split of request, which is not so complex,
compared to RSVP or even SIP forking).



Concerning the video transmission, I understand your point Ilya. The
video traffic is indeed very difficult to model. 
I don't really think there is an impact on NSIS, wrt the video rate
fluctuations.  What I assume for interractive multi media services, is
that nobody -even the video codec in the terminal- can predict that the
max bit rate of the codec will be reached one second later. Simply
because a bird in the sky or a unexpected move can generate (there are a
lot of reasons) a big change in the codec throughput.
So, what a interractive multimedia user needs, is the guarantee that the
pictures he sends will arrive at destination, being simple compressed
picture or a complex one. (he has of course an idea of the max bit rate,
and the mean bit rate, knowing the codec, the screen size, the
performance of his machine, the persons he talks with, etc... ). For SIP
terminal with video (SIP, H.323, anything which is interractive) , my
view is that a user wants a quantity of service's availability. He can
not follow precisely the rate of its codec(s) and requests in real time
the exact quantity of bandwidth. So the user should pay also for
bandwidth he does not use, but may use the very micro second after). 





> > If I send 3 reservations (audio, video and data), the third one being
> > rejected and then I cancel the two firsts, and then redo 3 other
> > reservations, this is a mess, and increases the signalling burden. There
> 
> This is application strategy, right? If the applications wants to react in
> this way, fine.
> However, the application can react in any other way and say, ok, I'm
> satisfied with audio alone.

True. This was an example. Mine was that stereo, or high sound quality
is not needed anymore without video. Question was ("was" since it is
over): do we think that NSIS users would use often the "transaction"
capabilities (I answer SIP users will), or not (because NSIS users would
be in majority non interractive video on demand services).


 
> > would be in this case 2 simple use cases for the draft: simple
> > reservation, simple cancellation. But you see the scenario for SIP calls
> > would be complex, and requires multiple processings inside the network.
> > On the other hand, one reservation per multiple flow would give two
> > requests.
> >
> > I mean, this type of thinking was adopted in SIP/SDP: in a SIP
> > invitation, the whole multimedia session context is guathered in one
> > packet, instead of the verbose H.323 way of doing. But maybe thing that
> > applies for SIP are not so well suited for signalling...
> > And maybe my proposition was not a requirement, but an implementation
> > choice.
> >
> 
> Just my two cents, Andreas.

Here are my two euro cents,

Kind regards

-- 
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@ns.ietf.org  Fri Feb 22 11:41: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 LAA09645
	for <nsis-archive@odin.ietf.org>; Fri, 22 Feb 2002 11:41:48 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id LAA05019
	for nsis-archive@odin.ietf.org; Fri, 22 Feb 2002 11:41: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 LAA03419;
	Fri, 22 Feb 2002 11:23:04 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA03386
	for <nsis@ns.ietf.org>; Fri, 22 Feb 2002 11:23:01 -0500 (EST)
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 LAA08563
	for <nsis@ietf.org>; Fri, 22 Feb 2002 11:22:58 -0500 (EST)
Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19)
	id <1S9WNPAS>; Fri, 22 Feb 2002 16:22:26 -0000
Message-ID: <76C92FBBFB58D411AE760090271ED4181EA143@rsys002a.roke.co.uk>
From: "Hancock, Robert" <robert.hancock@roke.co.uk>
To: nsis@ietf.org
Cc: "Marcus Brunner (E-mail)" <brunner@ccrle.nec.de>
Date: Fri, 22 Feb 2002 16:22:25 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/mixed;
	boundary="------------InterScan_NT_MIME_Boundary"
Subject: [NSIS] WG Requirements Draft first version
Sender: nsis-admin@ietf.org
Errors-To: nsis-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Next Steps in Signaling <nsis.ietf.org>
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,

Marcus Brunner has finished the editing of the 00 requirements draft, and it should now be wending its way through the i-d queue to a mailing list near you.

For those that cannot wait, in the meantime it is available at:
http://www.epic.roke.co.uk/epic/draft-ietf-nsis-req-00.txt

Have a nice weekend,

Robert Hancock

--------------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@ns.ietf.org  Fri Feb 22 12:23: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 MAA12333
	for <nsis-archive@odin.ietf.org>; Fri, 22 Feb 2002 12:23:11 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id MAA08997
	for nsis-archive@odin.ietf.org; Fri, 22 Feb 2002 12:23: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 MAA08349;
	Fri, 22 Feb 2002 12:10: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 MAA08316
	for <nsis@ns.ietf.org>; Fri, 22 Feb 2002 12:10:09 -0500 (EST)
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11426
	for <nsis@ietf.org>; Fri, 22 Feb 2002 12:10:04 -0500 (EST)
Received: from garnet.juniper.net (garnet.juniper.net [172.17.28.17])
	by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g1MH9Ti80197;
	Fri, 22 Feb 2002 09:09:29 -0800 (PST)
	(envelope-from pingpan@juniper.net)
Date: Fri, 22 Feb 2002 09:09:29 -0800 (PST)
From: Ping Pan <pingpan@juniper.net>
To: <Alban.Couturier@alcatel.fr>
cc: "Freytsis, Ilya" <ifreytsis@cetacean.com>,
        "'nsis@ietf.org'" <nsis@ietf.org>
Subject: Re: [NSIS] req to reqest QoS for more than one session at once (was
 RE:  [NSI S] Scenario for IP telephony)
In-Reply-To: <3C764051.51F08990@alcatel.fr>
Message-ID: <20020222090207.H37870-100000@garnet.juniper.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=X-UNKNOWN
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by optimus.ietf.org id MAA08317
Sender: nsis-admin@ietf.org
Errors-To: nsis-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Next Steps in Signaling <nsis.ietf.org>
X-BeenThere: nsis@ietf.org
Content-Transfer-Encoding: 8bit


On Fri, 22 Feb 2002 Alban.Couturier@alcatel.fr wrote:

> Hello Ping
>
>
>
> I respect Marcus's decision, but would like to answer your question
>
> Ping Pan a écrit :
> >
> > Freytsis, Ilya wrote:
> >
> > > Marcus,
> > >
> > > I'd like to suggest different wording for your requirement:
> > > NSIS protocol should allow requesting QoS for more than one session with the
> > > same originating and terminating points within the same transaction.
> > >
> >
> > Hi,
> >
> > Just curious, what's the gain of setting up one reservation session for
> > multiple application flows here? You may argue that one reservation is
> > cheap to process compare with multiple reservation sessions. However, it
> > looks to me that the application flows may be quite dynamic, then the
> > reservation needs to be modified constantly anyway. As a result, I argue
> >   that the processing overhead for supporting one-reservation-per-flow
> > vs. one-reservation-per-multiple-flows would be pretty close.
> >
>
> Application dynamicity depends on the time scale considered of course.
> We could say a interractive multimedia call lasts something like 5
> minutes, and could reach hours. For you, is is dynamic, or not?
> But anyway, a reservation for a session does not change previous
> reservations, so they won't be modified constantly.
>

That's exactly my point. One reservation per session does not seem to be a
bad idea in the first place. So why bother with managing multiple flows
per session. One-to-many reservation looks good on paper, but in
implementation it can be quite complex...

> If I send 3 reservations (audio, video and data), the third one being
> rejected and then I cancel the two firsts, and then redo 3 other
> reservations, this is a mess, and increases the signalling burden. There
> would be in this case 2 simple use cases for the draft: simple
> reservation, simple cancellation. But you see the scenario for SIP calls
> would be complex, and requires multiple processings inside the network.
> On the other hand, one reservation per multiple flow would give two
> requests.
>
> I mean, this type of thinking was adopted in SIP/SDP: in a SIP
> invitation, the whole multimedia session context is guathered in one
> packet, instead of the verbose H.323 way of doing. But maybe thing that
> applies for SIP are not so well suited for signalling...
> And maybe my proposition was not a requirement, but an implementation
> choice.
>

IMHO, SIP is e2e signaling protocol that may trigger another signaling
protocol to setup reservations inside the network. The reservation
signaling should be independent from whoever is calling it, however it
must provide enough functionality to make the users (e.g. SIP) happy.

2 more cents,

- Ping



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



From daemon@ns.ietf.org  Fri Feb 22 12:38: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 MAA13028
	for <nsis-archive@odin.ietf.org>; Fri, 22 Feb 2002 12:38:32 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id MAA10064
	for nsis-archive@odin.ietf.org; Fri, 22 Feb 2002 12:38:36 -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 MAA08710;
	Fri, 22 Feb 2002 12:17:25 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA08677
	for <nsis@ns.ietf.org>; Fri, 22 Feb 2002 12:17:23 -0500 (EST)
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11916
	for <nsis@ietf.org>; Fri, 22 Feb 2002 12:17:19 -0500 (EST)
Received: from garnet.juniper.net (garnet.juniper.net [172.17.28.17])
	by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g1MHGIi80550;
	Fri, 22 Feb 2002 09:16:18 -0800 (PST)
	(envelope-from pingpan@juniper.net)
Date: Fri, 22 Feb 2002 09:16:18 -0800 (PST)
From: Ping Pan <pingpan@juniper.net>
To: Andreas Kassler <kassler@informatik.uni-ulm.de>
cc: <Alban.Couturier@alcatel.fr>, "Freytsis, Ilya" <ifreytsis@cetacean.com>,
        <nsis@ietf.org>
Subject: Re: [NSIS] req to reqest QoS for more than one session at once (was
 RE:  [NSI S] Scenario for IP telephony)
In-Reply-To: <032d01c1bba4$b2792900$1f4d3c86@informatik.uniulm.de>
Message-ID: <20020222091030.B37870-100000@garnet.juniper.net>
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 <nsis.ietf.org>
X-BeenThere: nsis@ietf.org


On Fri, 22 Feb 2002, Andreas Kassler wrote:

> > Application dynamicity depends on the time scale considered of course.
> > We could say a interractive multimedia call lasts something like 5
> > minutes, and could reach hours. For you, is is dynamic, or not?
> > But anyway, a reservation for a session does not change previous
> > reservations, so they won't be modified constantly.
>
> I slightly disagree. We have scenarios, for example video transmission, that
> have very dynamic bandwidth
> variation. There are several proposals how to implement this using for
> example renegotiated CBR like
> reservations, where you approximate the dynamic variation in bandwidth by
> piecewise constant amount of
> bandwidth. Clearly there is a tradeoff between re-negotiation interval and
> accuracy. However what I want to
> point out is that there might be situation where the reservations from the
> endsystem point of view may be updated
> frequently, say every 10 seconds. Consider a scene break with significant
> amount of motion afterwards.
> At least from the application point of view there should not be a
> restriction on how frequently the app
> wants to re-negotiate QoS for an already existing reservation.
>

Andreas,

It looks like what you have described above can be solved via Steve
McCanne's multi-layer approach. Except you set up reservations from the
sender's direction for each of the layers that you want to protect... At
worst it is a many-reservations to one user-session....

- Ping


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



From daemon@optimus.ietf.org  Mon Feb 25 04: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 EAA03562
	for <nsis-archive@odin.ietf.org>; Mon, 25 Feb 2002 04:48:50 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id EAA07717
	for nsis-archive@odin.ietf.org; Mon, 25 Feb 2002 04:48: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 EAA07477;
	Mon, 25 Feb 2002 04:39: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 EAA07445
	for <nsis@optimus.ietf.org>; Mon, 25 Feb 2002 04:39:33 -0500 (EST)
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 EAA03487
	for <nsis@ietf.org>; Mon, 25 Feb 2002 04:39:28 -0500 (EST)
Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19)
	id <1S9WNQF0>; Mon, 25 Feb 2002 09:38:48 -0000
Message-ID: <76C92FBBFB58D411AE760090271ED4181EA157@rsys002a.roke.co.uk>
From: "Hancock, Robert" <robert.hancock@roke.co.uk>
To: nsis@ietf.org
Date: Mon, 25 Feb 2002 09:38:42 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/mixed;
	boundary="------------InterScan_NT_MIME_Boundary"
Subject: [NSIS] i-d on NSIS framework
Sender: nsis-admin@ietf.org
Errors-To: nsis-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Next Steps in Signaling <nsis.ietf.org>
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,

In parallel with the requirements work, we have also spent some time gathering thoughts on an actual design framework for NSIS. Among other things, we think this should be helpful to clarify thinking about what some of the requirements could (or should) mean.

The draft was submitted quite close to the cut off time and so might be a little time getting through the processing queues. In the meantime, it is available for the impatient at
http://www.epic.roke.co.uk/epic/draft-hancock-nsis-framework-00.txt

The complete document is quite long, but the conclusions section contains a more concise summary of the open issues we discovered (many security related). Enjoy!

Robert Hancock, Siemens/RMR

Abstract:

   This Internet Draft presents a framework for further development of 
   QoS signaling in the Internet. We give a basic model for the 
   entities involved in QoS signaling, which is intended to be 
   applicable to a very wide range of networking environments, while 
   still retaining the flexibility to allow lightweight implementations 
   in particular environments and incremental deployment in the 
   Internet as a whole. 
    
   As well as the details of the framework itself, we also relate it to 
   the NSIS requirements work by mapping the framework to the 
   requirements themselves. We also present an initial assessment of 
   the applicability of existing QoS mechanisms to be used within the 
   framework. Security, scalability, and resilience are considered as 
   special issues. The framework leaves open a number of questions 
   relating to tradeoffs between simplicity and flexibility, and these 
   are summarized in the conclusions.

--------------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 Feb 26 03:34: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 DAA20644
	for <nsis-archive@odin.ietf.org>; Tue, 26 Feb 2002 03:34:59 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id DAA26898
	for nsis-archive@odin.ietf.org; Tue, 26 Feb 2002 03:35:02 -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 DAA26843;
	Tue, 26 Feb 2002 03:33: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 DAA26812
	for <nsis@optimus.ietf.org>; Tue, 26 Feb 2002 03:33:52 -0500 (EST)
Received: from penguin-ext.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 DAA20607
	for <nsis@ietf.org>; Tue, 26 Feb 2002 03:33:48 -0500 (EST)
Received: from mbb5.ericsson.se (mbb5.ericsson.se [136.225.151.210])
	by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id g1Q8XnB01892
	for <nsis@ietf.org>; Tue, 26 Feb 2002 09:33:49 +0100 (MET)
Received: from lm6068 (lm6068.lmera.ericsson.se [150.132.106.68])
 by mbb1.ericsson.se (PMDF V5.2-29 #39352)
 with ESMTP id <0GS4007UIT4DQG@mbb1.ericsson.se> for nsis@ietf.org; Tue,
 26 Feb 2002 09:33:49 +0100 (MET)
Date: Tue, 26 Feb 2002 09:33:48 +0100
From: David Partain <David.Partain@ericsson.com>
To: NSIS Mailing List <nsis@ietf.org>
Reply-to: David.Partain@ericsson.com
Message-id: <200202260933.48402.David.Partain@ericsson.com>
MIME-version: 1.0
X-Mailer: KMail [version 1.3.9]
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 DAA26813
Subject: [NSIS] WG requirements 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 <nsis.ietf.org>
X-BeenThere: nsis@ietf.org
Content-Transfer-Encoding: 8bit

Hi all,

After having glanced at the new draft, I want to see whether the
working group is "on board" with the model that this draft uses
for approaching the requirements.  The requirements are based
very heavily on the model which includes the "QoS initiator"
and the "QoS controller" rather than, as I see it, growing
out of the scenarios being used.

I'm rather uncomfortable with the whole QoS initiator/controller
model, since it seems to head right down the path of bandwidth
brokering with centralized "smarts" that make a decision.
While there may be places where this is appropriate, I don't
think we should be building requirements on this model.

I haven't seen the QoS initiator/controller model discussed much
here, and I don't think there's consensus one way or another,
so I'm asking:  Should the WG use this model as the basis for
our requirements?  I certainly have my doubts about that.

Cheers,

dlp


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



From daemon@optimus.ietf.org  Tue Feb 26 04:02: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 EAA21070
	for <nsis-archive@odin.ietf.org>; Tue, 26 Feb 2002 04:02:21 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id EAA28811
	for nsis-archive@odin.ietf.org; Tue, 26 Feb 2002 04:02: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 DAA28214;
	Tue, 26 Feb 2002 03:59: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 DAA28170
	for <nsis@optimus.ietf.org>; Tue, 26 Feb 2002 03:59:11 -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 DAA21012
	for <nsis@ietf.org>; Tue, 26 Feb 2002 03:59:03 -0500 (EST)
From: maarten.buchli@alcatel.be
Received: from bemail05.net.alcatel.be (localhost [127.0.0.1])
	by relay1.alcatel.be (8.10.1/8.10.1) with ESMTP id g1Q8wYd12456
	for <nsis@ietf.org>; Tue, 26 Feb 2002 09:58:34 +0100 (MET)
To: nsis@ietf.org
Date: Tue, 26 Feb 2002 09:58:32 +0100
Message-ID: <OFFA9534B0.A8C48685-ONC1256B6C.003122D9@net.alcatel.be>
X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at
 02/26/2002 09:58:34
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Subject: [NSIS] Draft submitted: draft-buchli-nsis-req-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 <nsis.ietf.org>
X-BeenThere: nsis@ietf.org

Dear all,

We have submitted a draft containing requirements for the NSIS working group based on an
architecture that is derived from two use cases. The draft is available at
http://users.skynet.be/besvand1/draft-buchli-nsis-req-00.txt and will soon be available in
the IETF internet-draft directory.

We are very much aware that currently a lot of work has been done by the team of Brunner and
by the people of the draft of David Partain. We submitted our draft because we have been
working on it for a while and we believe it offers a different perspective on the approach
presented in draft-brunner. In this way we think it can be useful to further prioritize the
requirements in this draft.

----------------------------------------------
   Title     : QoS signaling requirements, interfaces and architecture
   Author(s) : Maarten Buchli, Danny Goderis, Sven Van den Bosch,
               Juan-Carlos Rojas, Stefan Custers
   Filename  : draft-buchli-nsis-req-00.txt
   Pages     : 21
   Date      : February 2002

Abstract

This draft gives evidence for the existence of different QoS
signaling interfaces based on a reference architecture that is
derived from two use cases. The main purpose is to refine the
requirements for the signaling interface that is being considered in
scope of NSIS.

The two use cases are the interconnection of PSTN trunking gateways
over an IP core network and the connection of an UMTS access network
to an IP core network. From these use cases a QoS reference
architecture is derived containing QoS Initiator (QI) and QoS
Controller (QC) entities, as defined in draft-brunner-nsis-req-
00.txt. The architecture encompasses the inter-connection of any
type of access networks over an IP DiffServ core network and does
not require any upgrade of the existing (and deployed) DiffServ
routers.

The proposed architecture identifies four relevant signaling
interfaces between functional entities. We believe the interface
between QI and QC to be of particular interest in the context of
NSIS. Based on our architecture, the signaling protocol over this
interface can be kept simple.

Looking forward to your comments.


Kind regards,

Maarten Buchli
Danny Goderis
Sven Van den Bosch
Juan-Carlos Rojas
Stefan Custers


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



From daemon@optimus.ietf.org  Tue Feb 26 04:05: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 EAA21100
	for <nsis-archive@odin.ietf.org>; Tue, 26 Feb 2002 04:05:36 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id EAA28924
	for nsis-archive@odin.ietf.org; Tue, 26 Feb 2002 04:05: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 DAA28057;
	Tue, 26 Feb 2002 03:57: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 DAA28029
	for <nsis@optimus.ietf.org>; Tue, 26 Feb 2002 03:57:13 -0500 (EST)
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 DAA20984
	for <nsis@ietf.org>; Tue, 26 Feb 2002 03:57:10 -0500 (EST)
Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19)
	id <1S9WNRZL>; Tue, 26 Feb 2002 08:55:56 -0000
Message-ID: <76C92FBBFB58D411AE760090271ED4181EA166@rsys002a.roke.co.uk>
From: "Hancock, Robert" <robert.hancock@roke.co.uk>
To: "'David.Partain@ericsson.com'" <David.Partain@ericsson.com>,
        NSIS Mailing List <nsis@ietf.org>
Subject: RE: [NSIS] WG requirements draft
Date: Tue, 26 Feb 2002 08:55:56 -0000
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 <nsis.ietf.org>
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"

David,

Some notes:
*) The requirements model is not supposed to constrain solutions to any particular approach, it's supposed to provide language in which to discuss the requirements. If you feel that the model favours one approach over another, then we obviously failed in that area. However ...
*) We found that the original (draft-brunner-...) did give the impression (section 4) that QCs were basically bandwidth brokers, mainly because the diagrams showed them operating that way. **That was not the intention** (not my intention, anyway), and the draft-ietf-... adds some text to emphasise that. The QCs could be at every node and QIs at every host, and then you would have classical RSVP. Maybe this is still unclear?
*) It's true on the other hand that we wanted terminology that could be used to describe the BB scenario, and other interesting scenarios (e.g. the 'local SIP server takes charge of QoS signalling' scenario introduced recently, which is just captured by saying that the QI and traffic endpoint might not be in the same place). We certainly wanted to avoid a model that _implicitly_ ruled these scenarios out.
*) Of course, people might still want to restrict the allowed design space to say that things like disjoint QI/endpoint or BBs were not in NSIS scope, which is something that we can discuss. The terminology can then be used to capture that restriction _explicitly_.
*) So if any scenario can be covered by the QI/QC terms, what are they for? We wanted to be able to capture issues about how and where NSIS interacted with non-NSIS things, like where the application interactions took place, and where the interactions with QoS provisioning took place. We also wanted to have hooks to describe what entities had what security relationships with each other (which is also something that has been under-discussed on the mailing list).

We need words for 'the things that take part in NSIS signalling'. But that's all that QI and QC are supposed to be.

Yours,

Robert H.

> -----Original Message-----
> From: David Partain [mailto:David.Partain@ericsson.com]
> Sent: 26 February 2002 08:34
> To: NSIS Mailing List
> Subject: [NSIS] WG requirements draft
> 
> 
> Hi all,
> 
> After having glanced at the new draft, I want to see whether the
> working group is "on board" with the model that this draft uses
> for approaching the requirements.  The requirements are based
> very heavily on the model which includes the "QoS initiator"
> and the "QoS controller" rather than, as I see it, growing
> out of the scenarios being used.
> 
> I'm rather uncomfortable with the whole QoS initiator/controller
> model, since it seems to head right down the path of bandwidth
> brokering with centralized "smarts" that make a decision.
> While there may be places where this is appropriate, I don't
> think we should be building requirements on this model.
> 
> I haven't seen the QoS initiator/controller model discussed much
> here, and I don't think there's consensus one way or another,
> so I'm asking:  Should the WG use this model as the basis for
> our requirements?  I certainly have my doubts about that.
> 
> Cheers,
> 
> dlp
> 
> 
> _______________________________________________
> 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  Tue Feb 26 04:05: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 EAA21116
	for <nsis-archive@odin.ietf.org>; Tue, 26 Feb 2002 04:05:43 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id EAA28938
	for nsis-archive@odin.ietf.org; Tue, 26 Feb 2002 04:05: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 EAA28734;
	Tue, 26 Feb 2002 04:01: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 EAA28693
	for <nsis@optimus.ietf.org>; Tue, 26 Feb 2002 04:01:33 -0500 (EST)
Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21051
	for <nsis@ietf.org>; Tue, 26 Feb 2002 04:01:30 -0500 (EST)
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 g1Q91WZc009194
	for <nsis@ietf.org>; Tue, 26 Feb 2002 10:01:32 +0100 (MET)
Received: FROM esealnt747.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Tue Feb 26 10:01:23 2002 +0100
Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <F4H1672D>; Tue, 26 Feb 2002 10:01:22 +0100
Message-ID: <E244E44D6AB85E40AEEF7EAABE3545FAF7844D@enleent104.nl.eu.ericsson.se>
From: "Vlora Rexhepi (ELN)" <Vlora.Rexhepi@eln.ericsson.se>
To: "'David.Partain@ericsson.com'" <David.Partain@ericsson.com>,
        NSIS Mailing List <nsis@ietf.org>
Subject: RE: [NSIS] WG requirements draft
Date: Tue, 26 Feb 2002 10:01:19 +0100
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 <nsis.ietf.org>
X-BeenThere: nsis@ietf.org

Hi,
 
I think that the NSIS WG should certainly not use this model 
as the basis for the requirements. I believe that initially
the NSIS WG should derive the requirements from typical scenarios/use
cases as it also stated in the [NSIS] WG requirements draft without
any assumptions/relations to any kind of a model. In fact a 
model/framework should be developed based on the derived 
requirements.
I think, the problem with the "discussion model" described in 
Section 4.1, is that it does not seem to be generic enough to 
derive requirements for all the use cases, even though 
introduced for this purpose.
What I mean is that it can not be straightforwardly seen
how this model would apply to typical scenarios/use cases. This 
is due to the fact that the scenarios/use cases described in the
draft are not common as it is considered that there is an
centralized entity for the resource management, i.e. "access 
network manager" ("Scenario 1: Terminal Mobility"), bandwidth 
broker ("Scenario 2: Cellular networks"). Typically this is not the
case since many existing scenarios are using distributed resource 
management concepts, e.g. RSVPv1, RSVP Aggregation, etc. where the
resource management is provided on a distributed manner by 
many nodes (e.g. RSVP-aware nodes) along the communication path.
Without the assumption of having this centralized resource
management entity it is very difficult to see how this model 
is applied efficiently. For example if there is no such centralized 
entity in the access network such as "access network manager" how
would this model be applied? 
In my understanding  of the model you would need to have on
each node on the communication path a "QoS Initiator" and a 
"QoS controller". This I believe will be a very complex system 
which would deteriorate severely the scalability and performance
of the protocol. This kind of scenario/use case on Terminal 
Mobility, which in my opinion is typical use case, is missing from  
the draft.
As far as I know, centralized resource management is not a goal
of NSIS and it has not been discussed in other individual drafts
submitted to NSIS WG.
So, firstly it looks kind of strange to derive the requirements 
based on a model and also unusual to base them on this specific
model?! 
Furthermore, there are several requirements which are specifically
related to the entities of this model, i.e. QoS
Initiator and QoS controller, such as e.g. requirement on
"Automatic notification on available resources not been granted 
before" (section 5.3.7) where the QoS Initiator would like to 
have notification of resources he requested in the past time... 
To conclude regarding this issue I would appreciate that:
- the NSIS WG derives first the requirements from the scenarios/use
  cases without any assumptions/relations to any kind of a model. 
- the requirements should be based on typical scenarios/use cases
- the requirements should not be dependent on the model entities such
  as "QoS initiator" and the "QoS controller", but should be related to 
  typical scenarios/use cases network entities/nodes, e.g. host, border
  nodes, interior nodes, etc. 
- the requirements should not be constrained to specific resource
  management schemes, i.e. NSIS protocol  should fulfil the QoS 
  requirements independently of the resource management scheme 
  used (centralized or distributed) 

Regards,
Vlora

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



From daemon@optimus.ietf.org  Tue Feb 26 04:18: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 EAA21305
	for <nsis-archive@odin.ietf.org>; Tue, 26 Feb 2002 04:18:19 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id EAA29445
	for nsis-archive@odin.ietf.org; Tue, 26 Feb 2002 04:18: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 EAA29387;
	Tue, 26 Feb 2002 04:17:20 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA29356
	for <nsis@optimus.ietf.org>; Tue, 26 Feb 2002 04:17:18 -0500 (EST)
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 EAA21284
	for <nsis@ietf.org>; Tue, 26 Feb 2002 04:17:14 -0500 (EST)
Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19)
	id <1S9WNR6G>; Tue, 26 Feb 2002 09:13:42 -0000
Message-ID: <76C92FBBFB58D411AE760090271ED4181EA168@rsys002a.roke.co.uk>
From: "Hancock, Robert" <robert.hancock@roke.co.uk>
To: "'Vlora Rexhepi (ELN)'" <Vlora.Rexhepi@eln.ericsson.se>,
        "'David.Partain@ericsson.com'" <David.Partain@ericsson.com>,
        NSIS Mailing List <nsis@ietf.org>
Subject: RE: [NSIS] WG requirements draft
Date: Tue, 26 Feb 2002 09:13:40 -0000
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 <nsis.ietf.org>
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"

Vlora,

For most of your points, please see my earlier reply to your colleague. Some particular aspects:

*) You would like more scenarios. Me too. People have to provide them.

*) To be most useful, I believe that these scenarios need to be described with some common core terminology to describe the entities taking part in NSIS related signalling. Otherwise, it will be hard to tell from a plain text description what aspect of the scenario is part of the problem we are trying to solve, and what is not.

*) Having said which, I really fail to see how the act of giving the names 'QoS initiator' and 'QoS controller' to these entities leads to "a very complex system which would deteriorate severely the scalability and performance of the protocol" as you put it.

Yours,

Robert H.

> -----Original Message-----
> From: Vlora Rexhepi (ELN) [mailto:Vlora.Rexhepi@eln.ericsson.se]
> Sent: 26 February 2002 09:01
> To: 'David.Partain@ericsson.com'; NSIS Mailing List
> Subject: RE: [NSIS] WG requirements draft
> 
> 
> Hi,
>  
> I think that the NSIS WG should certainly not use this model 
> as the basis for the requirements. I believe that initially
> the NSIS WG should derive the requirements from typical scenarios/use
> cases as it also stated in the [NSIS] WG requirements draft without
> any assumptions/relations to any kind of a model. In fact a 
> model/framework should be developed based on the derived 
> requirements.
> I think, the problem with the "discussion model" described in 
> Section 4.1, is that it does not seem to be generic enough to 
> derive requirements for all the use cases, even though 
> introduced for this purpose.
> What I mean is that it can not be straightforwardly seen
> how this model would apply to typical scenarios/use cases. This 
> is due to the fact that the scenarios/use cases described in the
> draft are not common as it is considered that there is an
> centralized entity for the resource management, i.e. "access 
> network manager" ("Scenario 1: Terminal Mobility"), bandwidth 
> broker ("Scenario 2: Cellular networks"). Typically this is not the
> case since many existing scenarios are using distributed resource 
> management concepts, e.g. RSVPv1, RSVP Aggregation, etc. where the
> resource management is provided on a distributed manner by 
> many nodes (e.g. RSVP-aware nodes) along the communication path.
> Without the assumption of having this centralized resource
> management entity it is very difficult to see how this model 
> is applied efficiently. For example if there is no such centralized 
> entity in the access network such as "access network manager" how
> would this model be applied? 
> In my understanding  of the model you would need to have on
> each node on the communication path a "QoS Initiator" and a 
> "QoS controller". This I believe will be a very complex system 
> which would deteriorate severely the scalability and performance
> of the protocol. This kind of scenario/use case on Terminal 
> Mobility, which in my opinion is typical use case, is missing from  
> the draft.
> As far as I know, centralized resource management is not a goal
> of NSIS and it has not been discussed in other individual drafts
> submitted to NSIS WG.
> So, firstly it looks kind of strange to derive the requirements 
> based on a model and also unusual to base them on this specific
> model?! 
> Furthermore, there are several requirements which are specifically
> related to the entities of this model, i.e. QoS
> Initiator and QoS controller, such as e.g. requirement on
> "Automatic notification on available resources not been granted 
> before" (section 5.3.7) where the QoS Initiator would like to 
> have notification of resources he requested in the past time... 
> To conclude regarding this issue I would appreciate that:
> - the NSIS WG derives first the requirements from the scenarios/use
>   cases without any assumptions/relations to any kind of a model. 
> - the requirements should be based on typical scenarios/use cases
> - the requirements should not be dependent on the model entities such
>   as "QoS initiator" and the "QoS controller", but should be 
> related to 
>   typical scenarios/use cases network entities/nodes, e.g. 
> host, border
>   nodes, interior nodes, etc. 
> - the requirements should not be constrained to specific resource
>   management schemes, i.e. NSIS protocol  should fulfil the QoS 
>   requirements independently of the resource management scheme 
>   used (centralized or distributed) 
> 
> Regards,
> Vlora
> 
> _______________________________________________
> 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  Tue Feb 26 04:22: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 EAA21407
	for <nsis-archive@odin.ietf.org>; Tue, 26 Feb 2002 04:22:40 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id EAA29731
	for nsis-archive@odin.ietf.org; Tue, 26 Feb 2002 04:22:42 -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 EAA29680;
	Tue, 26 Feb 2002 04:21: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 EAA29645
	for <nsis@optimus.ietf.org>; Tue, 26 Feb 2002 04:21:43 -0500 (EST)
Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21376
	for <nsis@ietf.org>; Tue, 26 Feb 2002 04:21:39 -0500 (EST)
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 g1Q9LfZc023907
	for <nsis@ietf.org>; Tue, 26 Feb 2002 10:21:41 +0100 (MET)
Received: FROM esealnt746.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Tue Feb 26 10:21:39 2002 +0100
Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <F4HC91AD>; Tue, 26 Feb 2002 10:21:39 +0100
Message-ID: <E244E44D6AB85E40AEEF7EAABE3545FA8234E6@enleent104.nl.eu.ericsson.se>
From: "Georgios Karagiannis (ELN)" <Georgios.Karagiannis@eln.ericsson.se>
To: "'Hancock, Robert'" <robert.hancock@roke.co.uk>,
        "'David.Partain@ericsson.com'" <David.Partain@ericsson.com>,
        NSIS Mailing List <nsis@ietf.org>
Subject: RE: [NSIS] WG requirements draft
Date: Tue, 26 Feb 2002 10:21:35 +0100
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 <nsis.ietf.org>
X-BeenThere: nsis@ietf.org

Hi Robert 

Please see my comments in line!
[RH]> *) The requirements model is not supposed to constrain
[RH]>  solutions to any particular approach, it's supposed to provide 
[RH]> language in which to discuss the requirements. If you feel that 
[RH]> the model favours one approach over another, then we obviously 
[RH]>  failed in that area. However ...

Sorry Robert, but in my opinion this model favours the centralised 
resource management approach.
If such a model would be used in a distributed approach, then it will mean that
there will be a lot of QoS initiators and QoS controllers, that will probably
make the life very complex and the protocol non-scalable and too slow!

[RH]> *) We found that the original (draft-brunner-...) did give the 
[RH]> impression (section 4) that QCs were basically bandwidth brokers, 
[RH]> mainly because the diagrams showed them operating that way. **That was 
[RH]> not the intention** (not my intention, anyway), and the draft-ietf-... 
[RH]> adds some text to emphasise that. The QCs could be at every node 
[RH]> and QIs at every host, and then you would have classical RSVP. 
[RH]> Maybe this is still unclear?

I believe that this scenario will become very complex, non-scalable and 
very slow!

[RH]> *) It's true on the other hand that we wanted terminology 
[RH]> that could be used to describe the BB scenario, and other 
[RH]> interesting scenarios (e.g. the 'local SIP server takes charge 
[RH]> of QoS signalling' scenario introduced recently, which is 
[RH]> just captured by saying that the QI and traffic endpoint 
[RH]> might not be in the same place). We certainly wanted to 
[RH]> avoid a model that _implicitly_ [RH]>  ruled these scenarios out.

Yes, but I think that this model rules out common scenarios, for example such the 
ones described in:
http://search.ietf.org/internet-drafts/draft-partain-nsis-requirements-00.txt


[RH]> *) Of course, people might still want to restrict the allowed 
[RH]> design space to say that things like disjoint QI/endpoint or 
[RH]> BBs were not in NSIS scope, which is something that we can 
[RH]> discuss. The terminology can then be used to capture that 
[RH]> restriction _explicitly_.
[RH]> *) So if any scenario can be covered by the QI/QC terms, 
[RH]> what are they for? We wanted to be able to capture issues 
[RH]> about how and where NSIS interacted with non-NSIS things, 
[RH]> like where the application interactions took place, and where 
[RH]> the interactions with QoS provisioning took place. We also 
[RH]> wanted to have hooks to describe what entities had what 
[RH]> security relationships with each other (which is also something 
[RH]> that has been under-discussed on the mailing list).
[RH]> We need words for 'the things that take part in NSIS 
[RH]> signalling'. But that's all that QI and QC are supposed to be.

I think that the best terms that one could use to describe the 
entities used by the NSIS protocol are network entities, such as:
hosts, routers, edge routers, interior routers, proxies, etc.,

best regards,
Georgios

-----Original Message-----
From: Hancock, Robert [mailto:robert.hancock@roke.co.uk]
Sent: dinsdag 26 februari 2002 9:56
To: 'David.Partain@ericsson.com'; NSIS Mailing List
Subject: RE: [NSIS] WG requirements draft


David,

Some notes:
*) The requirements model is not supposed to constrain solutions to any particular approach, it's supposed to provide language in which to discuss the requirements. If you feel that the model favours one approach over another, then we obviously failed in that area. However ...
*) We found that the original (draft-brunner-...) did give the impression (section 4) that QCs were basically bandwidth brokers, mainly because the diagrams showed them operating that way. **That was not the intention** (not my intention, anyway), and the draft-ietf-... adds some text to emphasise that. The QCs could be at every node and QIs at every host, and then you would have classical RSVP. Maybe this is still unclear?
*) It's true on the other hand that we wanted terminology that could be used to describe the BB scenario, and other interesting scenarios (e.g. the 'local SIP server takes charge of QoS signalling' scenario introduced recently, which is just captured by saying that the QI and traffic endpoint might not be in the same place). We certainly wanted to avoid a model that _implicitly_ ruled these scenarios out.
*) Of course, people might still want to restrict the allowed design space to say that things like disjoint QI/endpoint or BBs were not in NSIS scope, which is something that we can discuss. The terminology can then be used to capture that restriction _explicitly_.
*) So if any scenario can be covered by the QI/QC terms, what are they for? We wanted to be able to capture issues about how and where NSIS interacted with non-NSIS things, like where the application interactions took place, and where the interactions with QoS provisioning took place. We also wanted to have hooks to describe what entities had what security relationships with each other (which is also something that has been under-discussed on the mailing list).

We need words for 'the things that take part in NSIS signalling'. But that's all that QI and QC are supposed to be.

Yours,

Robert H.

> -----Original Message-----
> From: David Partain [mailto:David.Partain@ericsson.com]
> Sent: 26 February 2002 08:34
> To: NSIS Mailing List
> Subject: [NSIS] WG requirements draft
> 
> 
> Hi all,
> 
> After having glanced at the new draft, I want to see whether the
> working group is "on board" with the model that this draft uses
> for approaching the requirements.  The requirements are based
> very heavily on the model which includes the "QoS initiator"
> and the "QoS controller" rather than, as I see it, growing
> out of the scenarios being used.
> 
> I'm rather uncomfortable with the whole QoS initiator/controller
> model, since it seems to head right down the path of bandwidth
> brokering with centralized "smarts" that make a decision.
> While there may be places where this is appropriate, I don't
> think we should be building requirements on this model.
> 
> I haven't seen the QoS initiator/controller model discussed much
> here, and I don't think there's consensus one way or another,
> so I'm asking:  Should the WG use this model as the basis for
> our requirements?  I certainly have my doubts about that.
> 
> Cheers,
> 
> dlp
> 
> 
> _______________________________________________
> 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 Feb 26 04:38: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 EAA21722
	for <nsis-archive@odin.ietf.org>; Tue, 26 Feb 2002 04:38:01 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id EAA00753
	for nsis-archive@odin.ietf.org; Tue, 26 Feb 2002 04:38: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 EAA00637;
	Tue, 26 Feb 2002 04:36:40 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA00598
	for <nsis@optimus.ietf.org>; Tue, 26 Feb 2002 04:36:37 -0500 (EST)
Received: from penguin-ext.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 EAA21684
	for <nsis@ietf.org>; Tue, 26 Feb 2002 04:36:33 -0500 (EST)
Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62])
	by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g1Q9aaB24486
	for <nsis@ietf.org>; Tue, 26 Feb 2002 10:36:36 +0100 (MET)
Received: FROM esealnt746.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Tue Feb 26 10:36:28 2002 +0100
Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <F4HC91GH>; Tue, 26 Feb 2002 10:36:28 +0100
Message-ID: <E244E44D6AB85E40AEEF7EAABE3545FAF7844F@enleent104.nl.eu.ericsson.se>
From: "Vlora Rexhepi (ELN)" <Vlora.Rexhepi@eln.ericsson.se>
To: NSIS Mailing List <nsis@ietf.org>
Subject: RE: [NSIS] WG requirements draft
Date: Tue, 26 Feb 2002 10:36:24 +0100
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 <nsis.ietf.org>
X-BeenThere: nsis@ietf.org

Hi Robert,

|*) You would like more scenarios. Me too. People have to provide them.
I would very much like to have some typical scenarios/use cases. 
These are missing from the current draft.

|*) To be most useful, I believe that these scenarios need to 
|be described with some common core terminology to describe the 
|entities taking part in NSIS related signalling. Otherwise, it 
|will be hard to tell from a plain text description what aspect 
|of the scenario is part of the problem we are trying to solve, 
|and what is not.
I think that we should relate the requirements to network entities
(e.g. host, border node, proxies,etc) and not use abstract concepts
to do so.

|*) Having said which, I really fail to see how the act of 
|giving the names 'QoS initiator' and 'QoS controller' to these 
|entities leads to "a very complex system which would 
|deteriorate severely the scalability and performance of the 
|protocol" as you put it.
Well it is not about the names it is about the functionality of
these entities when applied into every node. Just to recall here
the definition of these two entities as given in the draft:
"
   QoS Initiator: this is responsible for generating the QSCs for
   traffic flow(s) based on user or application requirements and
   signaling them to the network as well as invoking local QoS
   provisioning mechanisms.  This can be located in the end system, but
   may reside elsewhere in network.

   QoS Controller: this is responsible for interpreting the signaling
   carrying the user QoS parameters, optionally inserting/modifying the
   parameters according to local network QoS management policy, and
   invoking local QoS provisioning mechanisms.
"
If you would want this functionality in every node on the 
communication path it will be a very complex system that will not
scale and that will perform poorly.
   

Regards,
Vlora

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



From daemon@optimus.ietf.org  Tue Feb 26 05:01: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 FAA22090
	for <nsis-archive@odin.ietf.org>; Tue, 26 Feb 2002 05:01:05 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id FAA02181
	for nsis-archive@odin.ietf.org; Tue, 26 Feb 2002 05:01:08 -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 EAA01639;
	Tue, 26 Feb 2002 04:59: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 EAA01549
	for <nsis@optimus.ietf.org>; Tue, 26 Feb 2002 04:59:28 -0500 (EST)
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 EAA22058
	for <nsis@ietf.org>; Tue, 26 Feb 2002 04:59:24 -0500 (EST)
Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19)
	id <1S9WNR0D>; Tue, 26 Feb 2002 09:58:03 -0000
Message-ID: <76C92FBBFB58D411AE760090271ED4181EA16B@rsys002a.roke.co.uk>
From: "Hancock, Robert" <robert.hancock@roke.co.uk>
To: "'Vlora Rexhepi (ELN)'" <Vlora.Rexhepi@eln.ericsson.se>,
        NSIS Mailing List <nsis@ietf.org>
Subject: RE: [NSIS] WG requirements draft
Date: Tue, 26 Feb 2002 09:58:02 -0000
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 <nsis.ietf.org>
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"

Hi Vlora/Georgios,

On the functionality of QI/QC issue, do you believe that the functionality as defined in the draft is anything more than the minimum possible? In particular
*) do you believe that it is possible to have a QoS signalling exchange without someone interpreting higher layer QoS requests to decide what QoS to request? This is all that the QoS initiator does.
*) do you believe that it makes sense to have QoS signalling being interpreted by an entity which then doesn't apply any provisioning to make sure it is supported? This is all that the QoS controller does. (Actually, we did identify other cases in our framework document draft-hancock-..., where the QC does even less - they're all to do with optional capabilities like hooking into accounting and so on. So in fact, the QC can do as little as you like. Maybe the definition needs a tweak.)

On the 'appropriate terminology' issue, the options you & Georgios suggest actually seem to constrain the possible solutions. It seems to imply that QoS signalling can *only* be handled by [end?] hosts and routers, it distinguishes special types of routers, which may not apply to every scenario (Is my home gateway a host? Does my network provider see it as a router? If it is CPE, is it an edge or interior router?). I think the term 'proxy' is itself so generic that further definition is required. At a minimum, we would have to decorate these terms with 'NSIS-aware' and 'NSIS-unaware' and so on.

On the specific issue of BBs/centralised resource management (which people seem particularly concerned about), it is also not my (personal) field of interest to define algorithms/protocols to support this specific approach. However, I think we do have to at least consider how NSIS interacts with networks using such an approach. Saying that NSIS signalling has to follow the data path and that there is a special type of edge router that proxies this signalling into the BB by some private mechanism is one option (probably a good one), but it strikes me that restricting the terminology so that this is the only solution that can even be described is going some way into the design stage.

Yours,

Robert H.

> -----Original Message-----
> From: Vlora Rexhepi (ELN) [mailto:Vlora.Rexhepi@eln.ericsson.se]
> Sent: 26 February 2002 09:36
> To: NSIS Mailing List
> Subject: RE: [NSIS] WG requirements draft
> 
> 
> Hi Robert,
> 
> |*) You would like more scenarios. Me too. People have to 
> provide them.
> I would very much like to have some typical scenarios/use cases. 
> These are missing from the current draft.
> 
> |*) To be most useful, I believe that these scenarios need to 
> |be described with some common core terminology to describe the 
> |entities taking part in NSIS related signalling. Otherwise, it 
> |will be hard to tell from a plain text description what aspect 
> |of the scenario is part of the problem we are trying to solve, 
> |and what is not.
> I think that we should relate the requirements to network entities
> (e.g. host, border node, proxies,etc) and not use abstract concepts
> to do so.
> 
> |*) Having said which, I really fail to see how the act of 
> |giving the names 'QoS initiator' and 'QoS controller' to these 
> |entities leads to "a very complex system which would 
> |deteriorate severely the scalability and performance of the 
> |protocol" as you put it.
> Well it is not about the names it is about the functionality of
> these entities when applied into every node. Just to recall here
> the definition of these two entities as given in the draft:
> "
>    QoS Initiator: this is responsible for generating the QSCs for
>    traffic flow(s) based on user or application requirements and
>    signaling them to the network as well as invoking local QoS
>    provisioning mechanisms.  This can be located in the end 
> system, but
>    may reside elsewhere in network.
> 
>    QoS Controller: this is responsible for interpreting the signaling
>    carrying the user QoS parameters, optionally 
> inserting/modifying the
>    parameters according to local network QoS management policy, and
>    invoking local QoS provisioning mechanisms.
> "
> If you would want this functionality in every node on the 
> communication path it will be a very complex system that will not
> scale and that will perform poorly.
>    
> 
> Regards,
> Vlora
> 
> _______________________________________________
> 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  Tue Feb 26 05: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 FAA22275
	for <nsis-archive@odin.ietf.org>; Tue, 26 Feb 2002 05:18:11 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id FAA02777
	for nsis-archive@odin.ietf.org; Tue, 26 Feb 2002 05:18:14 -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 FAA02715;
	Tue, 26 Feb 2002 05:16:59 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA02685
	for <nsis@optimus.ietf.org>; Tue, 26 Feb 2002 05:16:58 -0500 (EST)
Received: from mail1.telekom.de ([62.225.183.235])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22263
	for <nsis@ietf.org>; Tue, 26 Feb 2002 05:16:52 -0500 (EST)
Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Tue, 26 Feb 2002 11:14:46 +0100
Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19)
	id <F3BACRFH>; Tue, 26 Feb 2002 11:16:21 +0100
Message-Id: <DFD875E85664D3118FA6080006277DE70362C8CE@U8PN2>
From: "Geib, Ruediger" <Ruediger.Geib@t-systems.com>
To: Vlora.Rexhepi@eln.ericsson.se
Cc: nsis@ietf.org
Subject: RE: [NSIS] WG requirements draft
Date: Tue, 26 Feb 2002 11:16:16 +0100
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 FAA02686
Sender: nsis-admin@ietf.org
Errors-To: nsis-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Next Steps in Signaling <nsis.ietf.org>
X-BeenThere: nsis@ietf.org
Content-Transfer-Encoding: 8bit

Hello Vlora,

I'd suggest people to create NSIS usage scenarios with whatever terminology they like. In a later stage, NSIS may define a terminology and than re-edit the scenarios accordingly. I don't think that the terminology has much influence on the initial NSIS requirements.
As I further don't believe in the single best NSIS architecture, I dislike the idea of restrictions in creativity on a signaling architecture by now too. IETF always left the decision on the best way to operate a system to the market and I'd prefer to leave it that way. 

> "
>    QoS Initiator: this is responsible for generating the QSCs for
>    traffic flow(s) based on user or application requirements and
>    signaling them to the network as well as invoking local QoS
>    provisioning mechanisms.  This can be located in the end 
>    system, but may reside elsewhere in network.
> 
>    QoS Controller: this is responsible for interpreting the signaling
>    carrying the user QoS parameters, optionally inserting/modifying
>    the parameters according to local network QoS management policy,
>    and invoking local QoS provisioning mechanisms.
> "
> If you would want this functionality in every node on the 
> communication path it will be a very complex system that will not
> scale and that will perform poorly.

The text says that the QoS Initiator could be one (or more) proxies or the end system and the QoS Controller could be a specialised single node (e.g. edge), all nodes or a centralised system or any hybrid solution. If we all feel happier if all possibilities are mentioned explicitely, let's do that. I personally don't have a problem with this text. It covers the solution I prefer as well as the one I don't.

Regards, Rüdiger   

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



From daemon@optimus.ietf.org  Tue Feb 26 05:27: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 FAA22430
	for <nsis-archive@odin.ietf.org>; Tue, 26 Feb 2002 05:27:42 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id FAA03120
	for nsis-archive@odin.ietf.org; Tue, 26 Feb 2002 05:27: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 FAA03019;
	Tue, 26 Feb 2002 05:26: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 FAA02986
	for <nsis@optimus.ietf.org>; Tue, 26 Feb 2002 05:26:21 -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 FAA22401
	for <nsis@ietf.org>; Tue, 26 Feb 2002 05:26:17 -0500 (EST)
From: danny.goderis@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 g1QAPdG09851;
	Tue, 26 Feb 2002 11:25:39 +0100 (MET)
Received: from alcatel.be ([138.203.67.19])
          by bemail04.net.alcatel.be (Lotus Domino Release 5.0.8)
          with ESMTP id 2002022611253716:533 ;
          Tue, 26 Feb 2002 11:25:37 +0100 
Message-ID: <3C7B62A0.FB5B7838@alcatel.be>
Date: Tue, 26 Feb 2002 11:25:36 +0100
Organization: Alcatel CRC Antwerp
X-Mailer: Mozilla 4.72 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: "Hancock, Robert" <robert.hancock@roke.co.uk>
Cc: "'David.Partain@ericsson.com'" <David.Partain@ericsson.com>,
        NSIS Mailing List <nsis@ietf.org>
Subject: Re: [NSIS] WG requirements draft
References: <OFC4E34520.31D37A85-ONC1256B6C.00313A13@alcatel.be>
X-MIMETrack: Itemize by SMTP Server on BEMAIL04/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at
 02/26/2002 11:25:37,
	Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at
 02/26/2002 11:25:39,
	Serialize complete at 02/26/2002 11:25:39
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
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 <nsis.ietf.org>
X-BeenThere: nsis@ietf.org
Content-Transfer-Encoding: 7bit

Hi Hancock, David and all,

Just some reflection on requirements, models, etc

Clearly at the current stage of NSIS WG, it is too early to derive
requirements from one model/framework. However I agree with Hancock that
we should (try to) define the basic functions involved in end-to-end QoS
signaling. From this persperctive, the definition of QoSInitiator and
QoSController as in draft-brunner-... is for me a useful first step. 

Of course, the definitions need further work, and certain
characteristics may be "universal", while other QI/QC features may
depend on their actual place in the end-to-end signaling path. 

Second, the number of "models/frameworks" to dervice requirements. 

What I like in the draft-brunner-... is that depending on the actual
network segment (access, core, etc), or simply the deployed network, the
QoS approach may be different. Clearly different access technologies
have different QoS approaches (e.g. UMTS PDP signaling ,PacketCable
RSVP+ signaling, etc) and this is totally different from e.g. IP
DiffServ.  This may give two "high-level" requirements derived from
observation of today networks:

- First, different QOS approaches may co-exist  and QoS signaling should
allow their interworking. 
- Second, the NSIS approach should allow for a gradual deployment on
existing , mainstream network equipment. Up to know, this high-level
requirement was always one of the basic QoS show-stoppers (see e.g. RFC
2990 for an analysis of IntServ & DiffServ). 

This may yield two signaling requirements:

- at certain points in the end-to-end signaling path (e.g. at the edge)
one has a "QoS mapping" function. For example, it could be that in UMTS
networks (from terminal to GGSN edge), the QoS signaling and reservation
is still done by the existing UMTS PDP protocol or via session SIP
signaling, then the QoS parameters are captured at the network edge and
the QI-edge generates "NSIS" signaling further downstream.
- An out-of-band NSIS agent could exist in same parts of the network,
because a network provider is not likely to upgrade all its routers for
participating in the QoS Internet. This may yield the requirement that
in-band and out-of-band signaling should be able to interwork.

I think at current stage, we should have no restriction regarding
models, etc but try to identify the two/three key (mainstream)
approaches that are actually in place or proposed today. 

Regards,
Danny

"Hancock, Robert" wrote:
> 
> David,
> 
> Some notes:
> *) The requirements model is not supposed to constrain solutions to any particular approach, it's supposed to provide language in which to discuss the requirements. If you feel that the model favours one approach over another, then we obviously failed in that area. However ...
> *) We found that the original (draft-brunner-...) did give the impression (section 4) that QCs were basically bandwidth brokers, mainly because the diagrams showed them operating that way. **That was not the intention** (not my intention, anyway), and the draft-ietf-... adds some text to emphasise that. The QCs could be at every node and QIs at every host, and then you would have classical RSVP. Maybe this is still unclear?
> *) It's true on the other hand that we wanted terminology that could be used to describe the BB scenario, and other interesting scenarios (e.g. the 'local SIP server takes charge of QoS signalling' scenario introduced recently, which is just captured by saying that the QI and traffic endpoint might not be in the same place). We certainly wanted to avoid a model that _implicitly_ ruled these scenarios out.
> *) Of course, people might still want to restrict the allowed design space to say that things like disjoint QI/endpoint or BBs were not in NSIS scope, which is something that we can discuss. The terminology can then be used to capture that restriction _explicitly_.
> *) So if any scenario can be covered by the QI/QC terms, what are they for? We wanted to be able to capture issues about how and where NSIS interacted with non-NSIS things, like where the application interactions took place, and where the interactions with QoS provisioning took place. We also wanted to have hooks to describe what entities had what security relationships with each other (which is also something that has been under-discussed on the mailing list).
> 
> We need words for 'the things that take part in NSIS signalling'. But that's all that QI and QC are supposed to be.
> 
> Yours,
> 
> Robert H.
> 
> > -----Original Message-----
> > From: David Partain [mailto:David.Partain@ericsson.com]
> > Sent: 26 February 2002 08:34
> > To: NSIS Mailing List
> > Subject: [NSIS] WG requirements draft
> >
> >
> > Hi all,
> >
> > After having glanced at the new draft, I want to see whether the
> > working group is "on board" with the model that this draft uses
> > for approaching the requirements.  The requirements are based
> > very heavily on the model which includes the "QoS initiator"
> > and the "QoS controller" rather than, as I see it, growing
> > out of the scenarios being used.
> >
> > I'm rather uncomfortable with the whole QoS initiator/controller
> > model, since it seems to head right down the path of bandwidth
> > brokering with centralized "smarts" that make a decision.
> > While there may be places where this is appropriate, I don't
> > think we should be building requirements on this model.
> >
> > I haven't seen the QoS initiator/controller model discussed much
> > here, and I don't think there's consensus one way or another,
> > so I'm asking:  Should the WG use this model as the basis for
> > our requirements?  I certainly have my doubts about that.
> >
> > Cheers,
> >
> > dlp
> >
> >
> > _______________________________________________
> > nsis mailing list
> > nsis@ietf.org
> > https://www1.ietf.org/mailman/listinfo/nsis
> >
> 
>   ------------------------------------------------------------------------
>                           Name: RMRL-Disclaimer.txt
>    RMRL-Disclaimer.txt    Type: Plain Text (text/plain)
>                       Encoding: 7bit

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



From daemon@optimus.ietf.org  Tue Feb 26 05:28: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 FAA22453
	for <nsis-archive@odin.ietf.org>; Tue, 26 Feb 2002 05:28:11 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id FAA03139
	for nsis-archive@odin.ietf.org; Tue, 26 Feb 2002 05:28:14 -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 FAA02971;
	Tue, 26 Feb 2002 05:26:04 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA02940
	for <nsis@optimus.ietf.org>; Tue, 26 Feb 2002 05:26:02 -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 FAA22399
	for <nsis@ietf.org>; Tue, 26 Feb 2002 05:25:57 -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 g1QAPQX09767;
	Tue, 26 Feb 2002 11:25:26 +0100 (MET)
Subject: RE: [NSIS] WG requirements draft
To: Vlora.Rexhepi@eln.ericsson.se
Cc: nsis@ietf.org
X-Mailer: Lotus Notes Release 5.0.5  September 22, 2000
Message-ID: <OF84F3A28E.2B900F35-ONC1256B6C.00392604@net.alcatel.be>
Date: Tue, 26 Feb 2002 11:25:24 +0100
X-MIMETrack: Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at
 02/26/2002 11:25:26
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 <nsis.ietf.org>
X-BeenThere: nsis@ietf.org

Hi Vlora,

Allow me to jump into this discussion. I believe that the QI, QC controller
model at least has the merit of clearly identifying the interfaces that we
are deriving requirements for. When applied to various use cases, it allows
to discover functionality that is common between different entities in the
different use cases. In this way, we are looking for common functionality
which will lead to the core nsis requirements.
I am a bit surprised to see the discussion emphasize on centralised or
distributed resource management. While both obviously should be allowed,
resource management is clearly a local (intra-domain) matter and as such it
should probably be decoupled from the end-to-end issues. For this reason,
we have introduced a two-level approach with preprovisioned bandwidth
pipes, allowing simple admission control and both distributed and
centralised resource management.

Cheers,
Sven.





"Vlora Rexhepi (ELN)" <Vlora.Rexhepi@eln.ericsson.se> on 26/02/2002
10:01:19
                                                              
                                                              
                                                              
  To:          "'David.Partain@ericsson.com'"                 
               <David.Partain@ericsson.com>, NSIS Mailing     
               List <nsis@ietf.org>                           
                                                              
  cc:          (bcc: Sven VAN DEN BOSCH/BE/ALCATEL)           
                                                              
                                                              
                                                              
  Subject      RE: [NSIS] WG requirements draft               
  :                                                           
                                                              





Hi,

I think that the NSIS WG should certainly not use this model
as the basis for the requirements. I believe that initially
the NSIS WG should derive the requirements from typical scenarios/use
cases as it also stated in the [NSIS] WG requirements draft without
any assumptions/relations to any kind of a model. In fact a
model/framework should be developed based on the derived
requirements.
I think, the problem with the "discussion model" described in
Section 4.1, is that it does not seem to be generic enough to
derive requirements for all the use cases, even though
introduced for this purpose.
What I mean is that it can not be straightforwardly seen
how this model would apply to typical scenarios/use cases. This
is due to the fact that the scenarios/use cases described in the
draft are not common as it is considered that there is an
centralized entity for the resource management, i.e. "access
network manager" ("Scenario 1: Terminal Mobility"), bandwidth
broker ("Scenario 2: Cellular networks"). Typically this is not the
case since many existing scenarios are using distributed resource
management concepts, e.g. RSVPv1, RSVP Aggregation, etc. where the
resource management is provided on a distributed manner by
many nodes (e.g. RSVP-aware nodes) along the communication path.
Without the assumption of having this centralized resource
management entity it is very difficult to see how this model
is applied efficiently. For example if there is no such centralized
entity in the access network such as "access network manager" how
would this model be applied?
In my understanding  of the model you would need to have on
each node on the communication path a "QoS Initiator" and a
"QoS controller". This I believe will be a very complex system
which would deteriorate severely the scalability and performance
of the protocol. This kind of scenario/use case on Terminal
Mobility, which in my opinion is typical use case, is missing from
the draft.
As far as I know, centralized resource management is not a goal
of NSIS and it has not been discussed in other individual drafts
submitted to NSIS WG.
So, firstly it looks kind of strange to derive the requirements
based on a model and also unusual to base them on this specific
model?!
Furthermore, there are several requirements which are specifically
related to the entities of this model, i.e. QoS
Initiator and QoS controller, such as e.g. requirement on
"Automatic notification on available resources not been granted
before" (section 5.3.7) where the QoS Initiator would like to
have notification of resources he requested in the past time...
To conclude regarding this issue I would appreciate that:
- the NSIS WG derives first the requirements from the scenarios/use
  cases without any assumptions/relations to any kind of a model.
- the requirements should be based on typical scenarios/use cases
- the requirements should not be dependent on the model entities such
  as "QoS initiator" and the "QoS controller", but should be related to
  typical scenarios/use cases network entities/nodes, e.g. host, border
  nodes, interior nodes, etc.
- the requirements should not be constrained to specific resource
  management schemes, i.e. NSIS protocol  should fulfil the QoS
  requirements independently of the resource management scheme
  used (centralized or distributed)

Regards,
Vlora

_______________________________________________
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 Feb 26 05:34: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 FAA22590
	for <nsis-archive@odin.ietf.org>; Tue, 26 Feb 2002 05:34:39 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id FAA03790
	for nsis-archive@odin.ietf.org; Tue, 26 Feb 2002 05:34: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 FAA03725;
	Tue, 26 Feb 2002 05:33:44 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA03694
	for <nsis@optimus.ietf.org>; Tue, 26 Feb 2002 05:33:41 -0500 (EST)
Received: from beamer.mchh.siemens.de (beamer.mchh.siemens.de [194.138.158.163])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22569
	for <nsis@ietf.org>; Tue, 26 Feb 2002 05:33:36 -0500 (EST)
Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226])
	by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id LAA25311;
	Tue, 26 Feb 2002 11:33:28 +0100 (MET)
Received: from mchh246e.demchh201e.icn.siemens.de ([139.21.200.56])
	by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id LAA01907;
	Tue, 26 Feb 2002 11:33:24 +0100 (MET)
Received: by MCHH246E with Internet Mail Service (5.5.2653.19)
	id <FGJX2JQM>; Tue, 26 Feb 2002 11:33:33 +0100
Message-ID: <4D486782CA36D4118A530000D11EA42A01265622@blns204e.bln.icn.siemens.de>
From: Kappler Cornelia <Cornelia.Kappler@icn.siemens.de>
To: "'Georgios Karagiannis (ELN)'" <Georgios.Karagiannis@eln.ericsson.se>,
        Hancock Robert <robert.hancock@roke.co.uk>,
        "'David.Partain@ericsson.com'" <David.Partain@ericsson.com>,
        NSIS Mailing List <nsis@ietf.org>
Subject: RE: [NSIS] WG requirements draft
Date: Tue, 26 Feb 2002 11:33:25 +0100
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 <nsis.ietf.org>
X-BeenThere: nsis@ietf.org

Hi Georgios and Vlora, 

the basic idea of QoS Initiator and QoS Controller is_just_ giving a name to the entity _intitiating_ QoS signaling, and another name to entities _processing_ QoS signalling (we believe their functionality is sufficiently distinct as to give them different names) This is all there is to it!!!!! Doesn't this make perfect sense?

Of course we then tried defining more precisely what QIs and QCs are. In fact we updated the definition somewhat in the framework draft http://www.epic.roke.co.uk/epic/draft-hancock-nsis-framework-00.txt. We are happy to amend it when somebody comes up with something better! (I append the updated definition to this mail)

As opposed to restricting possible scenarios and architectures, the goal is having general, abstract language that integrates as may of them as NSIS deems reasonable! (I.e. the Definition of QI and QC must such that this goal is met)

In a second step, these entities should of course be mapped on "hosts, routers, edge routers, interior routers, proxies, etc.," I think it makes sense to describe the QoS functionality performed by these entities via some common term, rather than identifying and describing individually how each of them acts when it initiates / processes QoS signaling - just because there is lot's of communality! This will make fixing the actual protocol much easier. And stating the requirements too.

_Of course_ it is important to have detailed scenarios describing how QoS signaling works with each of these entities (hosts, routers, edge routers etc). And in fact we see no problem in performing this mapping. Please see the framework draft cited above, in which we worked out different signalling scenarios involving proxies, edge routers, RSVP... and how they can be mapped or integrated in to this common "language".

I fail to see how this will make anything more complicated....

More comments inline.


> -----Original Message-----
> From:	Georgios Karagiannis (ELN) [SMTP:Georgios.Karagiannis@eln.ericsson.se]
> Sent:	Tuesday, February 26, 2002 10:22 AM
> To:	'Hancock, Robert'; 'David.Partain@ericsson.com'; NSIS Mailing List
> Subject:	RE: [NSIS] WG requirements draft
> 
> Hi Robert 
> Sorry Robert, but in my opinion this model favours the centralised 
> resource management approach.
> 
To re-iterate Robert's point: this terminology does not at all favor centralized bandwith-broker-like approaches. It as easily translates into edge-to-edge signaling or even hop-by-hop signaling (for an illustration see framework draft)

> If such a model would be used in a distributed approach, then it will mean that
> there will be a lot of QoS initiators and QoS controllers, that will probably
> make the life very complex and the protocol non-scalable and too slow!
> 
Only to the extent that distributed approaches are slow by their very nature... You seem to be concerned introducing QIs and QCs will add lots of extra functionality. Just re-naming something doesnt do this, does it? 

> [RH]> *) We found that the original (draft-brunner-...) did give the 
> [RH]> impression (section 4) that QCs were basically bandwidth brokers, 
> [RH]> mainly because the diagrams showed them operating that way. **That was 
> [RH]> not the intention** (not my intention, anyway), and the draft-ietf-... 
> [RH]> adds some text to emphasise that. The QCs could be at every node 
> [RH]> and QIs at every host, and then you would have classical RSVP. 
> [RH]> Maybe this is still unclear?
> 
> I believe that this scenario will become very complex, non-scalable and 
> very slow!
> 
	See above.

> [RH]> *) It's true on the other hand that we wanted terminology 
> [RH]> that could be used to describe the BB scenario, and other 
> [RH]> interesting scenarios (e.g. the 'local SIP server takes charge > 
> [RH]> of QoS signalling' scenario introduced recently, which is > 
> [RH]> just captured by saying that the QI and traffic endpoint 
> [RH]> might not be in the same place). We certainly wanted to 
> [RH]> avoid a model that _implicitly_ [RH]>  ruled these scenarios out.
> 
> Yes, but I think that this model rules out common scenarios, for example such the 
> ones described in:
> http://search.ietf.org/internet-drafts/draft-partain-nsis-requirements-00.txt
> 
	I have to check that one out. It's been on my reading list for since you posted it. Comments later.

> I think that the best terms that one could use to describe the 
> entities used by the NSIS protocol are network entities, such as:
> hosts, routers, edge routers, interior routers, proxies, etc.,
> 
	See above. Of course one should do this, too. But also point to their common functionality.

	Best regards, Cornelia

	-------------------------------------------------------------------

	Definition of QI and QC from framework draft:

	   The QoS initiator starts the request for QoS for a user flow.  It 
	   might be located in the end system or within some part of the 
	   network, such as the edge router for an access network, or even an 
	   application layer proxy. The distinguishing feature of the QoS 
	   initiator is that it acts on triggers coming (directly or 
	   indirectly) from the higher layers in the end systems, mapping the 
	   QoS requested by them. It also provides feedback information to the 
	   higher layers which might be used by transport layer rate management 
	   or adaptive applications. 
	    
	   In our model, the QoS initiator is a particular instance of the 
	   generic NSIS agent shown in Figure 1, which will have 
	   *) Triggers from and feedback to upper layer applications 
	   *) Typically, no incoming QoS requests 
	   *) Typically, one outgoing QoS request per application data flow 
	   *) Local QoS provisioning functions for the first hop (for both the 
	   IP and link layers) 
	    
	   Likewise, the QoS controller manages and enforces QoS further along 
	   the path. It might be located in some or all routers, or in a 
	   separate network element, e.g. in a bandwidth broker (note therefore 
	   that QoS controllers are not constrained to lie on the traffic 
	   path). If QoS is to be provisioned on a path segment, there must be 
	   at least one QoS controller to do this (but this would not be needed 
	   for example in overprovisioned QoS subdomains). The QoS controller 
	   does not interact with higher layers, but interacts with the QoS 
	   initiator and possibly more QoS controllers further along the path. 
	    
	   In our model, the QoS controller is another particular instance of 
	   the generic NSIS agent, which will have: 
	   *) Incoming and outgoing QoS requests. Incoming QoS requests are 
	   interworked to outgoing requests. The interworking might consist of 
	   managing additional flows (e.g. aggregation or disaggregation), or 
	   interpreting the QoS requested by the user in terms of the QoS 
	   allowed by some SLA (e.g. on inter-domain links). 
	   *) If the local QoS cannot be provisioned by sending the appropriate 
	   outgoing QoS request, subdomain-specific QoS provisioning signaling 
	   can be invoked. In this case, the provisioning mechanism is opaque 
	   to NSIS and can be locally implementation specific. 
	   *) Accounting and authentication information may be exchanged with 
	   local AAA nodes. The precise protocol used to do this is again 
	   outside the scope of NSIS signaling. 

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



From daemon@optimus.ietf.org  Tue Feb 26 05:39: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 FAA22677
	for <nsis-archive@odin.ietf.org>; Tue, 26 Feb 2002 05:39:03 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id FAA04035
	for nsis-archive@odin.ietf.org; Tue, 26 Feb 2002 05:39: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 FAA03861;
	Tue, 26 Feb 2002 05:36:59 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA03830
	for <nsis@optimus.ietf.org>; Tue, 26 Feb 2002 05:36:57 -0500 (EST)
Received: from operax.com (aurorum86-0.aurorum.se [213.88.249.86])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA22624
	for <nsis@ietf.org>; Tue, 26 Feb 2002 05:36:52 -0500 (EST)
Received: (qmail 38214 invoked by uid 0); 26 Feb 2002 10:36:25 -0000
Received: from detrol.operax.com (HELO operax.com) (192.168.1.15)
  by treo.operax.com with SMTP; 26 Feb 2002 10:36:25 -0000
Message-ID: <3C7B651C.7C52CF9E@operax.com>
Date: Tue, 26 Feb 2002 11:36:12 +0100
From: Olov Schelen <olov.schelen@operax.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.9 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: NSIS Mailing List <nsis@ietf.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [NSIS] Allow both signalled and centralised solution
Sender: nsis-admin@ietf.org
Errors-To: nsis-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Next Steps in Signaling <nsis.ietf.org>
X-BeenThere: nsis@ietf.org
Content-Transfer-Encoding: 7bit

Hi all,

- an advantage with a logically centralised  QoS controller is that the
network operator gets necessary control of what is going on in their
network. In implementation, however, the QoS controller may be
distributed or clustered.
- all solutions, including in-path signalling, need policy control that
is outsourced to policy decision points (PDP). Kombining end-point
signalling (e.g., RSVP) with edge routers that correspond with QoS
controller (using NSIS protocol?) is one way of providing this. A
signalling solution that does not include policy control does not make
sense in most cases.
- another way of operation should be to skip endpoint signalling, and
thereby allow off-path service management units (e.g. SIP proxies, H.323
gatekeepers,  3G radio network controllers etc) or content service units
to reserve resources for their clients. There are also services that are
typically not end-point specific that may prefer this scenario (e.g.,
VPN, coproprate access contracts etc)

Given that both solutions above should be possible i would like to add:
- the signalling overhead is NOT becoming larger by allowing off-path
units to initialise QoS requests. On the contrary, you may save a lot of
signalling over wireless hops since  service gatways (e.g., SIP proxies
or H.323 gatekeepers) already have the necessery information from
ordinary session setup to also make QoS requests.
- with a QoS controller you get much better opportunities to localize
your QoS decisions so that the RTT delay at e.g., hand-over in wireless
access can be avoided. Yes, you get an RTT to the local QoS controller
instead, but this is usually shorter. Hand over-must involve
re-negotiation of radio-resources and then the information for IP QoS
control is already available in a box inside the fixed network and can
be fed to the QoS controller.
- the performance of a QoS controller is NOT a problem. We have an
implementation that shows excellent performance.

I would like to point to one of our technical presentation of a QoS
controller (see next mail). The focus is on concepts and use cases, but
for this discussion I apologize that the product name occurs as well.

/Olov


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



From daemon@optimus.ietf.org  Tue Feb 26 05:43: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 FAA22767
	for <nsis-archive@odin.ietf.org>; Tue, 26 Feb 2002 05:43:51 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id FAA04171
	for nsis-archive@odin.ietf.org; Tue, 26 Feb 2002 05:43: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 FAA03900;
	Tue, 26 Feb 2002 05:37: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 FAA03873
	for <nsis@optimus.ietf.org>; Tue, 26 Feb 2002 05:37:05 -0500 (EST)
Received: from operax.com (aurorum86-0.aurorum.se [213.88.249.86])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA22626
	for <nsis@ietf.org>; Tue, 26 Feb 2002 05:37:01 -0500 (EST)
Received: (qmail 38220 invoked by uid 0); 26 Feb 2002 10:36:34 -0000
Received: from detrol.operax.com (HELO operax.com) (192.168.1.15)
  by treo.operax.com with SMTP; 26 Feb 2002 10:36:34 -0000
Message-ID: <3C7B6525.FF4095FC@operax.com>
Date: Tue, 26 Feb 2002 11:36:21 +0100
From: Olov Schelen <olov.schelen@operax.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.9 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: NSIS Mailing List <nsis@ietf.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [NSIS] An QoS controller implementation
Sender: nsis-admin@ietf.org
Errors-To: nsis-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Next Steps in Signaling <nsis.ietf.org>
X-BeenThere: nsis@ietf.org
Content-Transfer-Encoding: 7bit

Hi!
Here is the presentation of concepts and use-cases for our
implementation that roughly matches a QoS controller, as disussed in my
previous mail. Again,  for this list I apologize that product name
occurrs.

http://www.operax.com/docs/Operax-IQ-Man-tech-pub.pdf

/Olov


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



From daemon@optimus.ietf.org  Tue Feb 26 06:01: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 GAA22933
	for <nsis-archive@odin.ietf.org>; Tue, 26 Feb 2002 06:01:14 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id GAA05099
	for nsis-archive@odin.ietf.org; Tue, 26 Feb 2002 06:01: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 FAA04517;
	Tue, 26 Feb 2002 05:56: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 FAA04430
	for <nsis@optimus.ietf.org>; Tue, 26 Feb 2002 05:56:50 -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 FAA22847
	for <nsis@ietf.org>; Tue, 26 Feb 2002 05:56:45 -0500 (EST)
From: danny.goderis@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 g1QAuBA22685;
	Tue, 26 Feb 2002 11:56:12 +0100 (MET)
Received: from alcatel.be ([138.203.67.19])
          by bemail04.net.alcatel.be (Lotus Domino Release 5.0.8)
          with ESMTP id 2002022611561030:624 ;
          Tue, 26 Feb 2002 11:56:10 +0100 
Message-ID: <3C7B69C8.53539C06@alcatel.be>
Date: Tue, 26 Feb 2002 11:56:08 +0100
Organization: Alcatel CRC Antwerp
X-Mailer: Mozilla 4.72 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: "Vlora Rexhepi (ELN)" <Vlora.Rexhepi@eln.ericsson.se>
Cc: "'David.Partain@ericsson.com'" <David.Partain@ericsson.com>,
        NSIS Mailing List <nsis@ietf.org>
Subject: Re: [NSIS] WG requirements draft
References: <OF75B625A2.49A69D7B-ONC1256B6C.00319D9F@alcatel.be>
X-MIMETrack: Itemize by SMTP Server on BEMAIL04/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at
 02/26/2002 11:56:10,
	Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at
 02/26/2002 11:56:11,
	Serialize complete at 02/26/2002 11:56:11
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
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 <nsis.ietf.org>
X-BeenThere: nsis@ietf.org
Content-Transfer-Encoding: 7bit

Hi Vlora,

As I wrote a minute ago, I agree that NSIS should not restrict itself to
one basic model for deriving requirements. I also agree that the use
case of a central entity ("bandwidth broker" or whatever you call it)
does not cover a number of important cases: e.g. PacketCable (RSVP++
signaling) and UMTS (PDP-signaling). 

However, the distributed approach does not cover other use cases
neither. For example, in xDSL broadband access, the "L2 QoS signaling"
protocol, setting up ATM Switched Virtual Connections is, not deployed
in today networks. Another example is a DiffServ IP network provider,
which would also like to offer QoS to "user applications" (i.e. at the
microflow level and not just on an DiffServ aggrege DSCP- basis). But
the edge routers do not implement RSVP and therefore InServ over
DiffServ is not an option... 

As we all know, there has been quite some effort to solve this "pure
DiffServ case", and much of these approaches have been categorised as
"Bandwidth broker solutions", initially proposed by Van Jacobson,
researched by Internet2, etc. 
I agree with you that much of these approaches do not scale in DiffServ
networks: especially you can not "trigger"/configure (by e.g. the COPS
protocol) the routers on a micro-flow bases from a central entity "BB".
This approach even scales worse than IntServ all the way. In my view,
the DiffServ routers should not **at all** be triggered by a
per-micro-flow signaling/reservation protocol (not in band alike RSVP
and not out-of-band from a BB-alike entity). 

In a simple use case of our draft, we present a possible alternative
approach for pure DiffServ networks, not requiring any per-flow
interaction with the routers, but nevertheless being capable of offering
"per-micro flow" QoS. 

Just want to say that at this stage we should not excluse neither
distributed nor centralised approaches. In particular, I guess both will
co-exist in the future and NSIS should try to give a solution for their
interworking, yielding end-to-end QoS.

Best regards
Danny

"Vlora Rexhepi (ELN)" wrote:
> 
> Hi,
> 
> I think that the NSIS WG should certainly not use this model
> as the basis for the requirements. I believe that initially
> the NSIS WG should derive the requirements from typical scenarios/use
> cases as it also stated in the [NSIS] WG requirements draft without
> any assumptions/relations to any kind of a model. In fact a
> model/framework should be developed based on the derived
> requirements.
> I think, the problem with the "discussion model" described in
> Section 4.1, is that it does not seem to be generic enough to
> derive requirements for all the use cases, even though
> introduced for this purpose.
> What I mean is that it can not be straightforwardly seen
> how this model would apply to typical scenarios/use cases. This
> is due to the fact that the scenarios/use cases described in the
> draft are not common as it is considered that there is an
> centralized entity for the resource management, i.e. "access
> network manager" ("Scenario 1: Terminal Mobility"), bandwidth
> broker ("Scenario 2: Cellular networks"). Typically this is not the
> case since many existing scenarios are using distributed resource
> management concepts, e.g. RSVPv1, RSVP Aggregation, etc. where the
> resource management is provided on a distributed manner by
> many nodes (e.g. RSVP-aware nodes) along the communication path.
> Without the assumption of having this centralized resource
> management entity it is very difficult to see how this model
> is applied efficiently. For example if there is no such centralized
> entity in the access network such as "access network manager" how
> would this model be applied?
> In my understanding  of the model you would need to have on
> each node on the communication path a "QoS Initiator" and a
> "QoS controller". This I believe will be a very complex system
> which would deteriorate severely the scalability and performance
> of the protocol. This kind of scenario/use case on Terminal
> Mobility, which in my opinion is typical use case, is missing from
> the draft.
> As far as I know, centralized resource management is not a goal
> of NSIS and it has not been discussed in other individual drafts
> submitted to NSIS WG.
> So, firstly it looks kind of strange to derive the requirements
> based on a model and also unusual to base them on this specific
> model?!
> Furthermore, there are several requirements which are specifically
> related to the entities of this model, i.e. QoS
> Initiator and QoS controller, such as e.g. requirement on
> "Automatic notification on available resources not been granted
> before" (section 5.3.7) where the QoS Initiator would like to
> have notification of resources he requested in the past time...
> To conclude regarding this issue I would appreciate that:
> - the NSIS WG derives first the requirements from the scenarios/use
>   cases without any assumptions/relations to any kind of a model.
> - the requirements should be based on typical scenarios/use cases
> - the requirements should not be dependent on the model entities such
>   as "QoS initiator" and the "QoS controller", but should be related to
>   typical scenarios/use cases network entities/nodes, e.g. host, border
>   nodes, interior nodes, etc.
> - the requirements should not be constrained to specific resource
>   management schemes, i.e. NSIS protocol  should fulfil the QoS
>   requirements independently of the resource management scheme
>   used (centralized or distributed)
> 
> Regards,
> Vlora
> 
> _______________________________________________
> 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 Feb 26 06:02: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 GAA22959
	for <nsis-archive@odin.ietf.org>; Tue, 26 Feb 2002 06:02:52 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id GAA05314
	for nsis-archive@odin.ietf.org; Tue, 26 Feb 2002 06:02: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 GAA05195;
	Tue, 26 Feb 2002 06:01:26 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA05166
	for <nsis@optimus.ietf.org>; Tue, 26 Feb 2002 06:01:24 -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 GAA22946
	for <nsis@ietf.org>; Tue, 26 Feb 2002 06:01: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 g1QB1iI36546;
	Tue, 26 Feb 2002 12:01:45 +0100 (CET)
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 66E59C040; Tue, 26 Feb 2002 12:00:41 +0100 (CET)
Date: Tue, 26 Feb 2002 12:13:29 +0100
From: Marcus Brunner <brunner@ccrle.nec.de>
Reply-To: brunner@ccrle.nec.de
To: "Vlora Rexhepi (ELN)" <Vlora.Rexhepi@eln.ericsson.se>,
        "'David.Partain@ericsson.com'" <David.Partain@ericsson.com>,
        NSIS Mailing List <nsis@ietf.org>
Subject: RE: [NSIS] WG requirements draft
Message-ID: <8565907.1014725609@[192.168.102.79]>
In-Reply-To: <E244E44D6AB85E40AEEF7EAABE3545FAF7844D@enleent104.nl.eu.ericsson.se>
References:  <E244E44D6AB85E40AEEF7EAABE3545FAF7844D@enleent104.nl.eu.ericsso
 n.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 <nsis.ietf.org>
X-BeenThere: nsis@ietf.org
Content-Transfer-Encoding: 7bit



--On Tuesday, February 26, 2002 10:01 AM +0100 "Vlora Rexhepi (ELN)"
> I think, the problem with the "discussion model" described in
> Section 4.1, is that it does not seem to be generic enough to
> derive requirements for all the use cases, even though
> introduced for this purpose.

If you feel that it is not generic enough, could let me know in what 
direction it should be more generic?

> What I mean is that it can not be straightforwardly seen
> how this model would apply to typical scenarios/use cases. This
> is due to the fact that the scenarios/use cases described in the
> draft are not common as it is considered that there is an
> centralized entity for the resource management, i.e. "access
> network manager" ("Scenario 1: Terminal Mobility"), bandwidth
> broker ("Scenario 2: Cellular networks"). Typically this is not the
> case since many existing scenarios are using distributed resource
> management concepts, e.g. RSVPv1, RSVP Aggregation, etc. where the
> resource management is provided on a distributed manner by
> many nodes (e.g. RSVP-aware nodes) along the communication path.
> Without the assumption of having this centralized resource
> management entity it is very difficult to see how this model
> is applied efficiently. For example if there is no such centralized
> entity in the access network such as "access network manager" how
> would this model be applied?
> In my understanding  of the model you would need to have on
> each node on the communication path a "QoS Initiator" and a
> "QoS controller". This I believe will be a very complex system
> which would deteriorate severely the scalability and performance
> of the protocol. This kind of scenario/use case on Terminal
> Mobility, which in my opinion is typical use case, is missing from
> the draft.

In todays RSVP you exactly have one QoS controller and initiator on each 
node, and I have not seen somebody claiming this to be wrong so far.


> As far as I know, centralized resource management is not a goal
> of NSIS and it has not been discussed in other individual drafts
> submitted to NSIS WG.
> So, firstly it looks kind of strange to derive the requirements
> based on a model and also unusual to base them on this specific
> model?!

I have no problem to change the model if it is open to cover a broad range 
of scenarios, and several entities need to be named.

> Furthermore, there are several requirements which are specifically
> related to the entities of this model, i.e. QoS
> Initiator and QoS controller, such as e.g. requirement on
> "Automatic notification on available resources not been granted
> before" (section 5.3.7) where the QoS Initiator would like to
> have notification of resources he requested in the past time...
> To conclude regarding this issue I would appreciate that:
> - the NSIS WG derives first the requirements from the scenarios/use
>   cases without any assumptions/relations to any kind of a model.

It has proven to be difficult to do this. I would like that it is that easy.

> - the requirements should be based on typical scenarios/use cases

agreed.

> - the requirements should not be dependent on the model entities such
>   as "QoS initiator" and the "QoS controller", but should be related to
>   typical scenarios/use cases network entities/nodes, e.g. host, border
>   nodes, interior nodes, etc.

The model with host, border nodes, interior nodes is in my opinion 
restrictive as well. E.g., I don't see how mobilities related scenarios fit 
in, nor how centralized resource management scenarios fit in.

> - the requirements should not be constrained to specific resource
>   management schemes, i.e. NSIS protocol  should fulfil the QoS
>   requirements independently of the resource management scheme
>   used (centralized or distributed)
>

Completly agree with this.

> Regards,
> Vlora
>
> _______________________________________________
> 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  Tue Feb 26 06:14: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 GAA23066
	for <nsis-archive@odin.ietf.org>; Tue, 26 Feb 2002 06:14:12 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id GAA05827
	for nsis-archive@odin.ietf.org; Tue, 26 Feb 2002 06:14:16 -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 GAA05578;
	Tue, 26 Feb 2002 06:10: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 GAA05547
	for <nsis@optimus.ietf.org>; Tue, 26 Feb 2002 06:10:08 -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 GAA23026
	for <nsis@ietf.org>; Tue, 26 Feb 2002 06:10:02 -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 g1QBAaI36597;
	Tue, 26 Feb 2002 12:10:36 +0100 (CET)
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 5B7F5C040; Tue, 26 Feb 2002 12:09:33 +0100 (CET)
Date: Tue, 26 Feb 2002 12:22:21 +0100
From: Marcus Brunner <brunner@ccrle.nec.de>
Reply-To: brunner@ccrle.nec.de
To: "Vlora Rexhepi (ELN)" <Vlora.Rexhepi@eln.ericsson.se>,
        NSIS Mailing List <nsis@ietf.org>
Subject: RE: [NSIS] WG requirements draft
Message-ID: <9097902.1014726141@[192.168.102.79]>
In-Reply-To: <E244E44D6AB85E40AEEF7EAABE3545FAF7844F@enleent104.nl.eu.ericsson.se>
References:  <E244E44D6AB85E40AEEF7EAABE3545FAF7844F@enleent104.nl.eu.ericsso
 n.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 <nsis.ietf.org>
X-BeenThere: nsis@ietf.org
Content-Transfer-Encoding: 7bit



--On Tuesday, February 26, 2002 10:36 AM +0100 "Vlora Rexhepi (ELN)" 
<Vlora.Rexhepi@eln.ericsson.se> wrote:

> Hi Robert,
>
>| *) You would like more scenarios. Me too. People have to provide them.
> I would very much like to have some typical scenarios/use cases.
> These are missing from the current draft.
>

Me too so far we some kind of IP telephony use case in discussion, if the 
WG agrees we will added it in the next version (currently it needs some 
more discussions.


>| *) Having said which, I really fail to see how the act of
>| giving the names 'QoS initiator' and 'QoS controller' to these
>| entities leads to "a very complex system which would
>| deteriorate severely the scalability and performance of the
>| protocol" as you put it.
> Well it is not about the names it is about the functionality of
> these entities when applied into every node. Just to recall here
> the definition of these two entities as given in the draft:
> "
>    QoS Initiator: this is responsible for generating the QSCs for
>    traffic flow(s) based on user or application requirements and
>    signaling them to the network as well as invoking local QoS
>    provisioning mechanisms.  This can be located in the end system, but
>    may reside elsewhere in network.
>
>    QoS Controller: this is responsible for interpreting the signaling
>    carrying the user QoS parameters, optionally inserting/modifying the
>    parameters according to local network QoS management policy, and
>    invoking local QoS provisioning mechanisms.
> "
> If you would want this functionality in every node on the
> communication path it will be a very complex system that will not
> scale and that will perform poorly.

As said before in RSVP you have this exactly on each node.

If you regard the case of having a QoS signalling entity on each node we 
can discuss this.

Marcus

>
> Regards,
> Vlora
>
> _______________________________________________
> 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  Tue Feb 26 06:35: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 GAA23352
	for <nsis-archive@odin.ietf.org>; Tue, 26 Feb 2002 06:35:09 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id GAA06934
	for nsis-archive@odin.ietf.org; Tue, 26 Feb 2002 06:35:11 -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 GAA06827;
	Tue, 26 Feb 2002 06:33:04 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA06792
	for <nsis@optimus.ietf.org>; Tue, 26 Feb 2002 06:33:02 -0500 (EST)
Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23335
	for <nsis@ietf.org>; Tue, 26 Feb 2002 06:32:58 -0500 (EST)
Received: from mbb5.ericsson.se (mbb5.ericsson.se [136.225.151.210])
	by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g1QBX0Zc019047
	for <nsis@ietf.org>; Tue, 26 Feb 2002 12:33:00 +0100 (MET)
Received: from era.ericsson.se (rcur181ip162.ericsson.se [147.214.181.162])
 by mbb1.ericsson.se (PMDF V5.2-29 #39352)
 with ESMTP id <0GS500OD41F085@mbb1.ericsson.se> for nsis@ietf.org; Tue,
 26 Feb 2002 12:33:00 +0100 (MET)
Date: Tue, 26 Feb 2002 12:32:56 +0100
From: "Lars.Westberg" <Lars.Westberg@era.ericsson.se>
Subject: Re: [NSIS] WG requirements draft
To: brunner@ccrle.nec.de
Cc: "Vlora Rexhepi (ELN)" <Vlora.Rexhepi@eln.ericsson.se>,
        "'David.Partain@ericsson.com'" <David.Partain@ericsson.com>,
        NSIS Mailing List <nsis@ietf.org>
Message-id: <3C7B7268.5ADEB2FD@era.ericsson.se>
MIME-version: 1.0
X-Mailer: Mozilla 4.61 [en] (Win98; I)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7bit
X-Accept-Language: en
References: <8565907.1014725609@[192.168.102.79]>
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 <nsis.ietf.org>
X-BeenThere: nsis@ietf.org
Content-Transfer-Encoding: 7bit

Comments regarding mobillity:

Marcus Brunner wrote:

> --On Tuesday, February 26, 2002 10:01 AM +0100 "Vlora Rexhepi (ELN)"
> > I think, the problem with the "discussion model" described in
> > Section 4.1, is that it does not seem to be generic enough to
> > derive requirements for all the use cases, even though
> > introduced for this purpose.
>
> If you feel that it is not generic enough, could let me know in what
> direction it should be more generic?
>
> > What I mean is that it can not be straightforwardly seen
> > how this model would apply to typical scenarios/use cases. This
> > is due to the fact that the scenarios/use cases described in the
> > draft are not common as it is considered that there is an
> > centralized entity for the resource management, i.e. "access
> > network manager" ("Scenario 1: Terminal Mobility"), bandwidth
> > broker ("Scenario 2: Cellular networks"). Typically this is not the
> > case since many existing scenarios are using distributed resource
> > management concepts, e.g. RSVPv1, RSVP Aggregation, etc. where the
> > resource management is provided on a distributed manner by
> > many nodes (e.g. RSVP-aware nodes) along the communication path.
> > Without the assumption of having this centralized resource
> > management entity it is very difficult to see how this model
> > is applied efficiently. For example if there is no such centralized
> > entity in the access network such as "access network manager" how
> > would this model be applied?
> > In my understanding  of the model you would need to have on
> > each node on the communication path a "QoS Initiator" and a
> > "QoS controller". This I believe will be a very complex system
> > which would deteriorate severely the scalability and performance
> > of the protocol. This kind of scenario/use case on Terminal
> > Mobility, which in my opinion is typical use case, is missing from
> > the draft.
>
> In todays RSVP you exactly have one QoS controller and initiator on each
> node, and I have not seen somebody claiming this to be wrong so far.

>
> > As far as I know, centralized resource management is not a goal
> > of NSIS and it has not been discussed in other individual drafts
> > submitted to NSIS WG.
> > So, firstly it looks kind of strange to derive the requirements
> > based on a model and also unusual to base them on this specific
> > model?!
>
> I have no problem to change the model if it is open to cover a broad range
> of scenarios, and several entities need to be named.
>
> > Furthermore, there are several requirements which are specifically
> > related to the entities of this model, i.e. QoS
> > Initiator and QoS controller, such as e.g. requirement on
> > "Automatic notification on available resources not been granted
> > before" (section 5.3.7) where the QoS Initiator would like to
> > have notification of resources he requested in the past time...
> > To conclude regarding this issue I would appreciate that:
> > - the NSIS WG derives first the requirements from the scenarios/use
> >   cases without any assumptions/relations to any kind of a model.
>
> It has proven to be difficult to do this. I would like that it is that easy.
>
> > - the requirements should be based on typical scenarios/use cases
>
> agreed.
>
> > - the requirements should not be dependent on the model entities such
> >   as "QoS initiator" and the "QoS controller", but should be related to
> >   typical scenarios/use cases network entities/nodes, e.g. host, border
> >   nodes, interior nodes, etc.
>
> The model with host, border nodes, interior nodes is in my opinion
> restrictive as well. E.g., I don't see how mobilities related scenarios fit
> in, nor how centralized resource management scenarios fit in.
>

The purpose is to get an efficient message processing becase all router do not
need to
process all protocol functionality.
We need modularity of the protocol to get fast reservation setup-time at
handoff.
This can be easily be done if we can divide the requirements on different type
of interfaces/nodes.

>
> > - the requirements should not be constrained to specific resource
> >   management schemes, i.e. NSIS protocol  should fulfil the QoS
> >   requirements independently of the resource management scheme
> >   used (centralized or distributed)
> >
>
> Completly agree with this.
>
> > Regards,
> > Vlora
> >
> > _______________________________________________
> > 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


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



From daemon@optimus.ietf.org  Tue Feb 26 06:42: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 GAA23470
	for <nsis-archive@odin.ietf.org>; Tue, 26 Feb 2002 06:42:48 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id GAA07253
	for nsis-archive@odin.ietf.org; Tue, 26 Feb 2002 06:42: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 GAA07200;
	Tue, 26 Feb 2002 06:41: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 GAA07170
	for <nsis@optimus.ietf.org>; Tue, 26 Feb 2002 06:41:30 -0500 (EST)
Received: from penguin-ext.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 GAA23453
	for <nsis@ietf.org>; Tue, 26 Feb 2002 06:41:27 -0500 (EST)
Received: from mbb5.ericsson.se (mbb5.ericsson.se [136.225.151.210])
	by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id g1QBfTB00726
	for <nsis@ietf.org>; Tue, 26 Feb 2002 12:41:29 +0100 (MET)
Received: from era.ericsson.se (rcur181ip162.ericsson.se [147.214.181.162])
 by mbb1.ericsson.se (PMDF V5.2-29 #39352)
 with ESMTP id <0GS5001HR1T4FE@mbb1.ericsson.se> for nsis@ietf.org; Tue,
 26 Feb 2002 12:41:29 +0100 (MET)
Date: Tue, 26 Feb 2002 12:41:25 +0100
From: "Lars.Westberg" <Lars.Westberg@era.ericsson.se>
Subject: Re: [NSIS] Allow both signalled and centralised solution
To: Olov Schelen <olov.schelen@operax.com>
Cc: NSIS Mailing List <nsis@ietf.org>
Message-id: <3C7B7464.49498CAA@era.ericsson.se>
MIME-version: 1.0
X-Mailer: Mozilla 4.61 [en] (Win98; I)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7bit
X-Accept-Language: en
References: <3C7B651C.7C52CF9E@operax.com>
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 <nsis.ietf.org>
X-BeenThere: nsis@ietf.org
Content-Transfer-Encoding: 7bit

comments below

-Lasse
Olov Schelen wrote:

> Hi all,
>
> - an advantage with a logically centralised  QoS controller is that the
> network operator gets necessary control of what is going on in their
> network. In implementation, however, the QoS controller may be
> distributed or clustered.
> - all solutions, including in-path signalling, need policy control that
> is outsourced to policy decision points (PDP). Kombining end-point
> signalling (e.g., RSVP) with edge routers that correspond with QoS
> controller (using NSIS protocol?) is one way of providing this. A
> signalling solution that does not include policy control does not make
> sense in most cases.
> - another way of operation should be to skip endpoint signalling, and
> thereby allow off-path service management units (e.g. SIP proxies, H.323
> gatekeepers,  3G radio network controllers etc) or content service units
> to reserve resources for their clients. There are also services that are
> typically not end-point specific that may prefer this scenario (e.g.,
> VPN, coproprate access contracts etc)
>
> Given that both solutions above should be possible i would like to add:
> - the signalling overhead is NOT becoming larger by allowing off-path
> units to initialise QoS requests. On the contrary, you may save a lot of
> signalling over wireless hops since  service gatways (e.g., SIP proxies
> or H.323 gatekeepers) already have the necessery information from
> ordinary session setup to also make QoS requests.
> - with a QoS controller you get much better opportunities to localize
> your QoS decisions so that the RTT delay at e.g., hand-over in wireless
> access can be avoided. Yes, you get an RTT to the local QoS controller
> instead, but this is usually shorter. Hand over-must involve
> re-negotiation of radio-resources and then the information for IP QoS
> control is already available in a box inside the fixed network and can
> be fed to the QoS controller.
> - the performance of a QoS controller is NOT a problem. We have an
> implementation that shows excellent performance.

Bandwidth Broker is suitable solution for backbone networks, but if you have
high cost for
transmission, as in access network, Bandwidth Broker is not an efficient
solution. The simplest solution is to
make a new version of RSVP with better processing performance.

>

>
>
> I would like to point to one of our technical presentation of a QoS
> controller (see next mail). The focus is on concepts and use cases, but
> for this discussion I apologize that the product name occurs as well.
>
> /Olov
>
> _______________________________________________
> 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 Feb 26 07:06: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 HAA24781
	for <nsis-archive@odin.ietf.org>; Tue, 26 Feb 2002 07:06:46 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id HAA08737
	for nsis-archive@odin.ietf.org; Tue, 26 Feb 2002 07:06: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 HAA08613;
	Tue, 26 Feb 2002 07:05: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 HAA08580
	for <nsis@optimus.ietf.org>; Tue, 26 Feb 2002 07:05:15 -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 HAA24690;
	Tue, 26 Feb 2002 07:05:12 -0500 (EST)
Message-Id: <200202261205.HAA24690@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: Tue, 26 Feb 2002 07:05:12 -0500
Subject: [NSIS] I-D ACTION:draft-ietf-nsis-req-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 <nsis.ietf.org>
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-00.txt
	Pages		: 35
	Date		: 25-Feb-02
	
This draft 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.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-nsis-req-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-ietf-nsis-req-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-ietf-nsis-req-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:	<20020225143248.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-nsis-req-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-nsis-req-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20020225143248.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 Feb 26 07:12: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 HAA25005
	for <nsis-archive@odin.ietf.org>; Tue, 26 Feb 2002 07:12:37 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id HAA08950
	for nsis-archive@odin.ietf.org; Tue, 26 Feb 2002 07: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 HAA08363;
	Tue, 26 Feb 2002 07:03: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 HAA08330
	for <nsis@optimus.ietf.org>; Tue, 26 Feb 2002 07:03:04 -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 HAA24104;
	Tue, 26 Feb 2002 07:03:01 -0500 (EST)
Message-Id: <200202261203.HAA24104@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: Tue, 26 Feb 2002 07:03:00 -0500
Subject: [NSIS] I-D ACTION:draft-buchli-nsis-req-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 <nsis.ietf.org>
X-BeenThere: nsis@ietf.org

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: QoS signaling requirements, interfaces and 
                          architecture
	Author(s)	: M. Buchli et al.
	Filename	: draft-buchli-nsis-req-00.txt
	Pages		: 21
	Date		: 25-Feb-02
	
This draft gives evidence for the existence of different QoS 
signaling interfaces based on a reference architecture that is 
derived from two use cases. The main purpose is to refine the 
requirements for the signaling interface that is being considered in 
scope of NSIS.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-buchli-nsis-req-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-buchli-nsis-req-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-buchli-nsis-req-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:	<20020225142758.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-buchli-nsis-req-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-buchli-nsis-req-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20020225142758.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 Feb 26 07:29: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 HAA25368
	for <nsis-archive@odin.ietf.org>; Tue, 26 Feb 2002 07:29:03 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id HAA09334
	for nsis-archive@odin.ietf.org; Tue, 26 Feb 2002 07:29:05 -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 HAA09261;
	Tue, 26 Feb 2002 07:28: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 HAA09229
	for <nsis@optimus.ietf.org>; Tue, 26 Feb 2002 07:28:09 -0500 (EST)
Received: from operax.com (aurorum86-0.aurorum.se [213.88.249.86])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA25321
	for <nsis@ietf.org>; Tue, 26 Feb 2002 07:28:05 -0500 (EST)
Received: (qmail 92241 invoked by uid 0); 26 Feb 2002 12:27:37 -0000
Received: from detrol.operax.com (HELO operax.com) (192.168.1.15)
  by treo.operax.com with SMTP; 26 Feb 2002 12:27:37 -0000
Message-ID: <3C7B7F2C.46E57103@operax.com>
Date: Tue, 26 Feb 2002 13:27:24 +0100
From: Olov Schelen <olov.schelen@operax.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.9 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "Lars.Westberg" <Lars.Westberg@era.ericsson.se>
CC: NSIS Mailing List <nsis@ietf.org>
Subject: Re: [NSIS] Allow both signalled and centralised solution
References: <3C7B651C.7C52CF9E@operax.com> <3C7B7464.49498CAA@era.ericsson.se>
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 <nsis.ietf.org>
X-BeenThere: nsis@ietf.org
Content-Transfer-Encoding: 7bit

Lasse,
I think the overhead of (periodic) signalling along the path would be at least
as large as signalling to a Q0S controller.  Also per-flow e2e signalling will
induce some delay at hand-over, which indicates that reserving aggregates may
give better hand-over performance.  In any solution there are trade-offs
between  signalling overhead, bandwidth allocation, and hand-over performance.
We should not start ruling out any solutions at this point.

With processing overhead in the in-path signalling approach, do you mean that
the per-node processing overhead or link bandwidth efficiency (or both) is a
potential problem with RSVP.? There must be very strong reasons to replace RSVP
and also the charter of this group suggests re-using existing protocols.
/Olov

"Lars.Westberg" wrote:

> comments below
>
> -Lasse
> Olov Schelen wrote:
>
> > Hi all,
> >
> > - an advantage with a logically centralised  QoS controller is that the
> > network operator gets necessary control of what is going on in their
> > network. In implementation, however, the QoS controller may be
> > distributed or clustered.
> > - all solutions, including in-path signalling, need policy control that
> > is outsourced to policy decision points (PDP). Kombining end-point
> > signalling (e.g., RSVP) with edge routers that correspond with QoS
> > controller (using NSIS protocol?) is one way of providing this. A
> > signalling solution that does not include policy control does not make
> > sense in most cases.
> > - another way of operation should be to skip endpoint signalling, and
> > thereby allow off-path service management units (e.g. SIP proxies, H.323
> > gatekeepers,  3G radio network controllers etc) or content service units
> > to reserve resources for their clients. There are also services that are
> > typically not end-point specific that may prefer this scenario (e.g.,
> > VPN, coproprate access contracts etc)
> >
> > Given that both solutions above should be possible i would like to add:
> > - the signalling overhead is NOT becoming larger by allowing off-path
> > units to initialise QoS requests. On the contrary, you may save a lot of
> > signalling over wireless hops since  service gatways (e.g., SIP proxies
> > or H.323 gatekeepers) already have the necessery information from
> > ordinary session setup to also make QoS requests.
> > - with a QoS controller you get much better opportunities to localize
> > your QoS decisions so that the RTT delay at e.g., hand-over in wireless
> > access can be avoided. Yes, you get an RTT to the local QoS controller
> > instead, but this is usually shorter. Hand over-must involve
> > re-negotiation of radio-resources and then the information for IP QoS
> > control is already available in a box inside the fixed network and can
> > be fed to the QoS controller.
> > - the performance of a QoS controller is NOT a problem. We have an
> > implementation that shows excellent performance.
>
> Bandwidth Broker is suitable solution for backbone networks, but if you have
> high cost for
> transmission, as in access network, Bandwidth Broker is not an efficient
> solution. The simplest solution is to
> make a new version of RSVP with better processing performance.
>
> >
>
> >
> >
> > I would like to point to one of our technical presentation of a QoS
> > controller (see next mail). The focus is on concepts and use cases, but
> > for this discussion I apologize that the product name occurs as well.
> >
> > /Olov
> >
> > _______________________________________________
> > 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  Tue Feb 26 07:44: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 HAA25750
	for <nsis-archive@odin.ietf.org>; Tue, 26 Feb 2002 07:44:28 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id HAA10225
	for nsis-archive@odin.ietf.org; Tue, 26 Feb 2002 07:44: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 HAA09630;
	Tue, 26 Feb 2002 07:30: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 HAA09544
	for <nsis@optimus.ietf.org>; Tue, 26 Feb 2002 07:30:30 -0500 (EST)
Received: from penguin-ext.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 HAA25441
	for <nsis@ietf.org>; Tue, 26 Feb 2002 07:30:22 -0500 (EST)
Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62])
	by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g1QCUOB08461
	for <nsis@ietf.org>; Tue, 26 Feb 2002 13:30:24 +0100 (MET)
Received: FROM esealnt746.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Tue Feb 26 13:29:03 2002 +0100
Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <F4HC9GHF>; Tue, 26 Feb 2002 13:29:02 +0100
Message-ID: <E244E44D6AB85E40AEEF7EAABE3545FAF78452@enleent104.nl.eu.ericsson.se>
From: "Vlora Rexhepi (ELN)" <Vlora.Rexhepi@eln.ericsson.se>
To: "'brunner@ccrle.nec.de'" <brunner@ccrle.nec.de>,
        NSIS Mailing List
	 <nsis@ietf.org>
Subject: RE: [NSIS] WG requirements draft
Date: Tue, 26 Feb 2002 13:29:01 +0100
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 <nsis.ietf.org>
X-BeenThere: nsis@ietf.org

Hi Marcus and All,

|If you feel that it is not generic enough, could let me know in what 
|direction it should be more generic?

As  I already said the typical scenarios/use cases are missing and once 
trying to apply the model to such scenarios it is not straightforward to
do so. Also in my opinion the model is clearly in favour of centralised 
resource  management. Therefore I believe it is not generic enough.
In the introduction of [NSIS] WG draft it is said "Therefore there might 
different requirements on QoS signalling applying to different parts 
of the network", which is very true. So why not use this reasoning
to derive and group the requirements instead? 
This kind of approach is used in draft-partain-nsis-requirements-00.txt.
where the QoS requirements are separated into QoS requirements specific
to a particular interface between different parts of the network.
This way does not suggest any  "constraints" on possible solutions.
Further, my concern is that the "problem discussion model" is more
into suggesting a solution/signalling framework rather than just 
identifying the requirements. 
Also the requirements heavily depend on the "QoS Initiator"
and "QoS Controller".

Some more comments inline:

|In todays RSVP you exactly have one QoS controller and 
|initiator on each 
|node, and I have not seen somebody claiming this to be wrong so far.
True, but if there is a requirement related to QoS Initiator such as for
example " Automatic notification on available resources not been
granted before", how would this work in a single node with distributed
resource management?

|> As far as I know, centralized resource management is not a goal
|> of NSIS and it has not been discussed in other individual drafts
|> submitted to NSIS WG.
|> So, firstly it looks kind of strange to derive the requirements
|> based on a model and also unusual to base them on this specific
|> model?!
|
|I have no problem to change the model if it is open to cover a 
|broad range 
|of scenarios, and several entities need to be named.
Please have a look at the draft-partain-nsis-requirements-00.txt.

|> Furthermore, there are several requirements which are specifically
|> related to the entities of this model, i.e. QoS
|> Initiator and QoS controller, such as e.g. requirement on
|> "Automatic notification on available resources not been granted
|> before" (section 5.3.7) where the QoS Initiator would like to
|> have notification of resources he requested in the past time...
|> To conclude regarding this issue I would appreciate that:
|> - the NSIS WG derives first the requirements from the scenarios/use
|>   cases without any assumptions/relations to any kind of a model.
|
|It has proven to be difficult to do this. I would like that it 
|is that easy.
|
I have to refer to the draft-partain-nsis-requirements-00.txt again :-).

|> - the requirements should be based on typical scenarios/use cases
|
|agreed.
Great!

|> - the requirements should not be dependent on the model entities such
|>   as "QoS initiator" and the "QoS controller", but should be 
|related to
|>   typical scenarios/use cases network entities/nodes, e.g. 
|host, border
|>   nodes, interior nodes, etc.
|
|The model with host, border nodes, interior nodes is in my opinion 
|restrictive as well. E.g., I don't see how mobilities related 
|scenarios fit 
|in, nor how centralized resource management scenarios fit in.
If a domain is applying a centralized resource management or 
overprovisioning, NSIS protocol would be applied at the edges of a
domain. 
In case of mobility, the NSIS QoS protocol can be applied between an 
Access Router and a proxy - "Joint point of reservation" that would 
be located in the QoS aware segment that maintains an end-to-end 
reservation, but due to handover it should be able to 
change/modify this reservation. 

|> - the requirements should not be constrained to specific resource
|>   management schemes, i.e. NSIS protocol  should fulfil the QoS
|>   requirements independently of the resource management scheme
|>   used (centralized or distributed)
|>
|
|Completly agree with this.
Great!

Regards,
Vlora

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



From daemon@optimus.ietf.org  Tue Feb 26 07:48: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 HAA25842
	for <nsis-archive@odin.ietf.org>; Tue, 26 Feb 2002 07:48:10 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id HAA10321
	for nsis-archive@odin.ietf.org; Tue, 26 Feb 2002 07:48: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 HAA10086;
	Tue, 26 Feb 2002 07:37: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 HAA10054
	for <nsis@optimus.ietf.org>; Tue, 26 Feb 2002 07:37:13 -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 HAA25540
	for <nsis@ietf.org>; Tue, 26 Feb 2002 07:37:10 -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 g1QCafX20791;
	Tue, 26 Feb 2002 13:36:41 +0100 (MET)
Subject: RE: [NSIS] WG requirements draft
To: "Vlora Rexhepi (ELN)" <Vlora.Rexhepi@eln.ericsson.se>
Cc: nsis@ietf.org
X-Mailer: Lotus Notes Release 5.0.5  September 22, 2000
Message-ID: <OFD7BFFF93.B3D084BE-ONC1256B6C.00390E71@net.alcatel.be>
Date: Tue, 26 Feb 2002 13:36:37 +0100
X-MIMETrack: Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at
 02/26/2002 13:36:40
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 <nsis.ietf.org>
X-BeenThere: nsis@ietf.org

Hi Vlora,

The idea is to have preprovisioned bandwidth pipes under the control of a
local entity (NMS or router) that talks to the QC. The pipes implement a
certain QoS (edge-to-edge delay, jitter, ...). The QC then only has very
simple AC to do when a request arrives (check whether it fits in the pipe).
This makes sense for a number of reasons:
- A number of services will require similar QoS
- If each flow is treated independently, the QoS may change with new
incoming requests
- The provisioning action is a local matter: it may be distributed or
centralised.

Regards,
Sven.





"Vlora Rexhepi (ELN)" <Vlora.Rexhepi@eln.ericsson.se> on 26/02/2002
11:19:09
                                                              
                                                              
                                                              
  To:          Sven VAN DEN BOSCH/BE/ALCATEL@ALCATEL          
                                                              
  cc:                                                         
                                                              
                                                              
                                                              
  Subject      RE: [NSIS] WG requirements draft               
  :                                                           
                                                              





Hi Sven,

|Allow me to jump into this discussion. I believe that the QI,
|QC controller
|model at least has the merit of clearly identifying the
|interfaces that we
|are deriving requirements for. When applied to various use
|cases, it allows
|to discover functionality that is common between different
|entities in the
|different use cases. In this way, we are looking for common
|functionality
|which will lead to the core nsis requirements.
As I said the scenarios/use cases described in the draft are
not the typical ones and while trying to apply the model to a
typical scenario it was not as clear and straightforward to do
so. Furthermore it turned out to be quite complex.


|I am a bit surprised to see the discussion emphasize on centralised or
|distributed resource management. While both obviously should
|be allowed,
|resource management is clearly a local (intra-domain) matter
|and as such it
|should probably be decoupled from the end-to-end issues. For
|this reason,
|we have introduced a two-level approach with preprovisioned bandwidth
|pipes, allowing simple admission control and both distributed and
|centralised resource management.
This is because the model is according to my opinion clearly in favor
of the centalised approach.
What do you exactly mean by preprovisioned bandwidth pipes?
Where are they going to be applied to?

Regards,
Vlora




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



From daemon@optimus.ietf.org  Tue Feb 26 08:30: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 IAA28354
	for <nsis-archive@odin.ietf.org>; Tue, 26 Feb 2002 08:30:34 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id IAA12443
	for nsis-archive@odin.ietf.org; Tue, 26 Feb 2002 08:30:37 -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 IAA12060;
	Tue, 26 Feb 2002 08:27:59 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA12029
	for <nsis@optimus.ietf.org>; Tue, 26 Feb 2002 08:27:57 -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 IAA28160
	for <nsis@ietf.org>; Tue, 26 Feb 2002 08:27:53 -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.35)
	  id 16fhdd-0005MO-00; Tue, 26 Feb 2002 14:27:25 +0100
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 g1QDRO905703;
	Tue, 26 Feb 2002 14:27:24 +0100
Message-ID: <3C7B8D3C.238AFF29@ee.tu-berlin.de>
Date: Tue, 26 Feb 2002 14:27:24 +0100
From: Xiaoming Fu <fu@ee.tu-berlin.de>
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: Olov Schelen <olov.schelen@operax.com>
CC: "Lars.Westberg" <Lars.Westberg@era.ericsson.se>,
        NSIS Mailing List <nsis@ietf.org>
Subject: Re: [NSIS] Allow both signalled and centralised solution
References: <3C7B651C.7C52CF9E@operax.com> <3C7B7464.49498CAA@era.ericsson.se> <3C7B7F2C.46E57103@operax.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 <nsis.ietf.org>
X-BeenThere: nsis@ietf.org
Content-Transfer-Encoding: 7bit

Olov,

Olov Schelen wrote:
> 
> Lasse,
> I think the overhead of (periodic) signalling along the path would be at least
> as large as signalling to a Q0S controller.  Also per-flow e2e signalling will
> induce some delay at hand-over, which indicates that reserving aggregates may
> give better hand-over performance.  In any solution there are trade-offs
> between  signalling overhead, bandwidth allocation, and hand-over performance.
> We should not start ruling out any solutions at this point.
> 
> With processing overhead in the in-path signalling approach, do you mean that
> the per-node processing overhead or link bandwidth efficiency (or both) is a
> potential problem with RSVP.? There must be very strong reasons to replace RSVP
> and also the charter of this group suggests re-using existing protocols.

I think the complexity of dealing with multicast is one of the potential 
problems of RSVPv1. Multicast leads to a lot of overhead in state merging
and partially the reciever-initiated solution. In many scenarios, however, 
multicast is not necessarily required. If we remove the multicast support 
for RSVP, much processing overhead may be reduced. It may look like the 
following:
 - There will be only one FF style for reservation, hence the sender address
   with a port number may be added in the session information; meanwhile 
   the SENDER_TEMPLATE, STYLE and SCOPE objects can be omitted. 
 - There will be no necessity for FLOWSPEC merging (or change) - and later, 
   complexity in the state maintenance - when a session is reserved (or torn 
   down). Path messages are reduced to transmit SENDER_TSPEC (and optional 
   ADSPEC to find the predicted e2e QoS) and Resv messages are still used to 
   reserve resources but no FLOWSPEC merging is required.
 - RSVP aggregation and other extensions will be simplified as a result.
   
We outlined such a possibility, namely RSVPvs in Section 7.2 of
http://www.epic.roke.co.uk/epic/draft-hancock-nsis-framework-00.txt

Regards,
Xiaoming
 

> /Olov
> 
> "Lars.Westberg" wrote:
> 
> > comments below
> >
> > -Lasse
> > Olov Schelen wrote:
> >
> > > Hi all,
> > >
> > > - an advantage with a logically centralised  QoS controller is that the
> > > network operator gets necessary control of what is going on in their
> > > network. In implementation, however, the QoS controller may be
> > > distributed or clustered.
> > > - all solutions, including in-path signalling, need policy control that
> > > is outsourced to policy decision points (PDP). Kombining end-point
> > > signalling (e.g., RSVP) with edge routers that correspond with QoS
> > > controller (using NSIS protocol?) is one way of providing this. A
> > > signalling solution that does not include policy control does not make
> > > sense in most cases.
> > > - another way of operation should be to skip endpoint signalling, and
> > > thereby allow off-path service management units (e.g. SIP proxies, H.323
> > > gatekeepers,  3G radio network controllers etc) or content service units
> > > to reserve resources for their clients. There are also services that are
> > > typically not end-point specific that may prefer this scenario (e.g.,
> > > VPN, coproprate access contracts etc)
> > >
> > > Given that both solutions above should be possible i would like to add:
> > > - the signalling overhead is NOT becoming larger by allowing off-path
> > > units to initialise QoS requests. On the contrary, you may save a lot of
> > > signalling over wireless hops since  service gatways (e.g., SIP proxies
> > > or H.323 gatekeepers) already have the necessery information from
> > > ordinary session setup to also make QoS requests.
> > > - with a QoS controller you get much better opportunities to localize
> > > your QoS decisions so that the RTT delay at e.g., hand-over in wireless
> > > access can be avoided. Yes, you get an RTT to the local QoS controller
> > > instead, but this is usually shorter. Hand over-must involve
> > > re-negotiation of radio-resources and then the information for IP QoS
> > > control is already available in a box inside the fixed network and can
> > > be fed to the QoS controller.
> > > - the performance of a QoS controller is NOT a problem. We have an
> > > implementation that shows excellent performance.
> >
> > Bandwidth Broker is suitable solution for backbone networks, but if you have
> > high cost for
> > transmission, as in access network, Bandwidth Broker is not an efficient
> > solution. The simplest solution is to
> > make a new version of RSVP with better processing performance.
> >
> > >
> >
> > >
> > >
> > > I would like to point to one of our technical presentation of a QoS
> > > controller (see next mail). The focus is on concepts and use cases, but
> > > for this discussion I apologize that the product name occurs as well.
> > >
> > > /Olov
> > >
> > > _______________________________________________
> > > 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 Feb 26 09:05: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 JAA00103
	for <nsis-archive@odin.ietf.org>; Tue, 26 Feb 2002 09:05:08 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id JAA14370
	for nsis-archive@odin.ietf.org; Tue, 26 Feb 2002 09:05:10 -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 IAA13648;
	Tue, 26 Feb 2002 08:54: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 IAA13612
	for <nsis@optimus.ietf.org>; Tue, 26 Feb 2002 08:54:51 -0500 (EST)
Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29479
	for <nsis@ietf.org>; Tue, 26 Feb 2002 08:54:47 -0500 (EST)
Received: from mbb5.ericsson.se (mbb5.ericsson.se [136.225.151.210])
	by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g1QDsnZc021056
	for <nsis@ietf.org>; Tue, 26 Feb 2002 14:54:49 +0100 (MET)
Received: from era.ericsson.se (rcur181ip162.ericsson.se [147.214.181.162])
 by mbb1.ericsson.se (PMDF V5.2-29 #39352)
 with ESMTP id <0GS500J467ZDH0@mbb1.ericsson.se> for nsis@ietf.org; Tue,
 26 Feb 2002 14:54:49 +0100 (MET)
Date: Tue, 26 Feb 2002 14:54:44 +0100
From: "Lars.Westberg" <Lars.Westberg@era.ericsson.se>
Subject: Re: [NSIS] Allow both signalled and centralised solution
To: Olov Schelen <olov.schelen@operax.com>
Cc: NSIS Mailing List <nsis@ietf.org>
Message-id: <3C7B93A4.616FE9C2@era.ericsson.se>
MIME-version: 1.0
X-Mailer: Mozilla 4.61 [en] (Win98; I)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7bit
X-Accept-Language: en
References: <3C7B651C.7C52CF9E@operax.com> <3C7B7464.49498CAA@era.ericsson.se>
 <3C7B7F2C.46E57103@operax.com>
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 <nsis.ietf.org>
X-BeenThere: nsis@ietf.org
Content-Transfer-Encoding: 7bit

Periodic signalling will require some degree of overprovisioning in the transport..
A sutable solution for
backbone networks.

Regards Lasse

Olov Schelen wrote:

> Lasse,
> I think the overhead of (periodic) signalling along the path would be at least
> as large as signalling to a Q0S controller.  Also per-flow e2e signalling will
> induce some delay at hand-over, which indicates that reserving aggregates may
> give better hand-over performance.  In any solution there are trade-offs
> between  signalling overhead, bandwidth allocation, and hand-over performance.
> We should not start ruling out any solutions at this point.
>
> With processing overhead in the in-path signalling approach, do you mean that
> the per-node processing overhead or link bandwidth efficiency (or both) is a
> potential problem with RSVP.? There must be very strong reasons to replace RSVP
> and also the charter of this group suggests re-using existing protocols.
> /Olov
>
> "Lars.Westberg" wrote:
>
> > comments below
> >
> > -Lasse
> > Olov Schelen wrote:
> >
> > > Hi all,
> > >
> > > - an advantage with a logically centralised  QoS controller is that the
> > > network operator gets necessary control of what is going on in their
> > > network. In implementation, however, the QoS controller may be
> > > distributed or clustered.
> > > - all solutions, including in-path signalling, need policy control that
> > > is outsourced to policy decision points (PDP). Kombining end-point
> > > signalling (e.g., RSVP) with edge routers that correspond with QoS
> > > controller (using NSIS protocol?) is one way of providing this. A
> > > signalling solution that does not include policy control does not make
> > > sense in most cases.
> > > - another way of operation should be to skip endpoint signalling, and
> > > thereby allow off-path service management units (e.g. SIP proxies, H.323
> > > gatekeepers,  3G radio network controllers etc) or content service units
> > > to reserve resources for their clients. There are also services that are
> > > typically not end-point specific that may prefer this scenario (e.g.,
> > > VPN, coproprate access contracts etc)
> > >
> > > Given that both solutions above should be possible i would like to add:
> > > - the signalling overhead is NOT becoming larger by allowing off-path
> > > units to initialise QoS requests. On the contrary, you may save a lot of
> > > signalling over wireless hops since  service gatways (e.g., SIP proxies
> > > or H.323 gatekeepers) already have the necessery information from
> > > ordinary session setup to also make QoS requests.
> > > - with a QoS controller you get much better opportunities to localize
> > > your QoS decisions so that the RTT delay at e.g., hand-over in wireless
> > > access can be avoided. Yes, you get an RTT to the local QoS controller
> > > instead, but this is usually shorter. Hand over-must involve
> > > re-negotiation of radio-resources and then the information for IP QoS
> > > control is already available in a box inside the fixed network and can
> > > be fed to the QoS controller.
> > > - the performance of a QoS controller is NOT a problem. We have an
> > > implementation that shows excellent performance.
> >
> > Bandwidth Broker is suitable solution for backbone networks, but if you have
> > high cost for
> > transmission, as in access network, Bandwidth Broker is not an efficient
> > solution. The simplest solution is to
> > make a new version of RSVP with better processing performance.
> >
> > >
> >
> > >
> > >
> > > I would like to point to one of our technical presentation of a QoS
> > > controller (see next mail). The focus is on concepts and use cases, but
> > > for this discussion I apologize that the product name occurs as well.
> > >
> > > /Olov
> > >
> > > _______________________________________________
> > > 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  Tue Feb 26 09:38: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 JAA01524
	for <nsis-archive@odin.ietf.org>; Tue, 26 Feb 2002 09:38:50 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id JAA15791
	for nsis-archive@odin.ietf.org; Tue, 26 Feb 2002 09:38: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 JAA15716;
	Tue, 26 Feb 2002 09:37: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 JAA15675
	for <nsis@optimus.ietf.org>; Tue, 26 Feb 2002 09:37:22 -0500 (EST)
Received: from penguin-ext.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 JAA01415
	for <nsis@ietf.org>; Tue, 26 Feb 2002 09:37:19 -0500 (EST)
Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62])
	by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g1QEbLB17752
	for <nsis@ietf.org>; Tue, 26 Feb 2002 15:37:21 +0100 (MET)
Received: FROM esealnt747.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Tue Feb 26 15:37:20 2002 +0100
Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <F4H17AGC>; Tue, 26 Feb 2002 15:37:21 +0100
Message-ID: <E244E44D6AB85E40AEEF7EAABE3545FAF78454@enleent104.nl.eu.ericsson.se>
From: "Vlora Rexhepi (ELN)" <Vlora.Rexhepi@eln.ericsson.se>
To: "'Kappler Cornelia'" <Cornelia.Kappler@icn.siemens.de>,
        Hancock Robert
	 <robert.hancock@roke.co.uk>,
        NSIS Mailing List <nsis@ietf.org>
Subject: RE: [NSIS] WG requirements draft
Date: Tue, 26 Feb 2002 15:37:16 +0100
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 <nsis.ietf.org>
X-BeenThere: nsis@ietf.org

Hi Cornelia, Robert,


|the basic idea of QoS Initiator and QoS Controller is_just_ 
|giving a name to the entity _intitiating_ QoS signaling, and 
|another name to entities _processing_ QoS signalling (we 
|believe their functionality is sufficiently distinct as to 
|give them different names) This is all there is to it!!!!! 
|Doesn't this make perfect sense?
The "problem discussion model" is much more than this as 
the NSIS signalling requirements are depending heavily on 
these entities and it gets complicated when one is thinking 
of typical scenarios/use cases.

|Of course we then tried defining more precisely what QIs and 
|QCs are. In fact we updated the definition somewhat in the 
|framework draft 
|http://www.epic.roke.co.uk/epic/draft-hancock-nsis-framework-00
|.txt. We are happy to amend it when somebody comes up with 
|something better! (I append the updated definition to this mail)
I will have to get back to you later on your framework draft, as I
haven't read it yet. 

|In a second step, these entities should of course be mapped on 
|"hosts, routers, edge routers, interior routers, proxies, 
|etc.," I think it makes sense to describe the QoS 
|functionality performed by these entities via some common 
|term, rather than identifying and describing individually how 
|each of them acts when it initiates / processes QoS signaling 
|- just because there is lot's of communality! This will make 
|fixing the actual protocol much easier. And stating the 
|requirements too.
I believe the mapping is going to be a painful process, especially
when trying to satisfy the QoS requirements.

A question related to the definition of QI:
The QoS Initiator is located in "the end system or within some
part of the network, such as the edge router for an access 
network, or even an application layer proxy" and is used to 
communicate with higher layers. What does this mean for any other
node, e.g. interior node? Can the QI be part of the interior node?


Regards,
Vlora

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



From daemon@optimus.ietf.org  Tue Feb 26 09:50: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 JAA01890
	for <nsis-archive@odin.ietf.org>; Tue, 26 Feb 2002 09:50:13 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id JAA16254
	for nsis-archive@odin.ietf.org; Tue, 26 Feb 2002 09:50: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 JAA16179;
	Tue, 26 Feb 2002 09:49:16 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA16147
	for <nsis@optimus.ietf.org>; Tue, 26 Feb 2002 09:49:15 -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 JAA01858
	for <nsis@ietf.org>; Tue, 26 Feb 2002 09:49:12 -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.1.0/Switch-2.1.0) with ESMTP id g1QEnOZ28698
	for <nsis@ietf.org>; Tue, 26 Feb 2002 16:49:24 +0200 (EET)
Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T594fc14059ac158f23078@esvir03nok.nokia.com> for <nsis@ietf.org>;
 Tue, 26 Feb 2002 16:49:14 +0200
Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779);
	 Tue, 26 Feb 2002 16:49:14 +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"
Date: Tue, 26 Feb 2002 16:49:14 +0200
Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64A40@esebe004.NOE.Nokia.com>
Thread-Topic: [NSIS] WG requirements draft
Thread-Index: AcG+0y12bl0IUc5hT8aKdSrcEm3/DQAAR3Fg
To: <nsis@ietf.org>
X-OriginalArrivalTime: 26 Feb 2002 14:49:14.0460 (UTC) FILETIME=[C24301C0:01C1BED4]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id JAA16148
Subject: [NSIS] IETF 53
Sender: nsis-admin@ietf.org
Errors-To: nsis-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Next Steps in Signaling <nsis.ietf.org>
X-BeenThere: nsis@ietf.org
Content-Transfer-Encoding: 8bit

Hi all,

We have been given a slot for NSIS on Tuesday Morning, 9:00 to 11:30.
I have already recieved a few requests for slots, if anyone has
anything to discuss, please send me a direct mail, with the document
to be discussed (a link will be find) and the approximate time
needed.

Please remember, IETF meetings are not to present Internet Drafts,
but to discuss open issues.  I believe that most of the time will
be given to discuss the WG document, but as there are a number of
personal submissions on requirements, it might be useful for 
those personal submissions to be discussed, especially where 
they differ from the WG document.

best regards,
John

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



From daemon@optimus.ietf.org  Tue Feb 26 11:28: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 LAA06315
	for <nsis-archive@odin.ietf.org>; Tue, 26 Feb 2002 11:28:04 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id LAA21493
	for nsis-archive@odin.ietf.org; Tue, 26 Feb 2002 11:28: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 LAA20628;
	Tue, 26 Feb 2002 11:18:39 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA20597
	for <nsis@optimus.ietf.org>; Tue, 26 Feb 2002 11:18:37 -0500 (EST)
Received: from penguin-ext.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 LAA05840
	for <nsis@ietf.org>; Tue, 26 Feb 2002 11:18:33 -0500 (EST)
Received: from mbb5.ericsson.se (mbb5.ericsson.se [136.225.151.210])
	by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id g1QGIaB29653
	for <nsis@ietf.org>; Tue, 26 Feb 2002 17:18:36 +0100 (MET)
Received: from era.ericsson.se (rcur181ip162.ericsson.se [147.214.181.162])
 by mbb1.ericsson.se (PMDF V5.2-29 #39352)
 with ESMTP id <0GS500N1NEMZEW@mbb1.ericsson.se> for nsis@ietf.org; Tue,
 26 Feb 2002 17:18:36 +0100 (MET)
Date: Tue, 26 Feb 2002 17:18:30 +0100
From: "Lars.Westberg" <Lars.Westberg@era.ericsson.se>
Subject: Re: [NSIS] WG requirements draft
To: sven.van_den_bosch@alcatel.be
Cc: "Vlora Rexhepi (ELN)" <Vlora.Rexhepi@eln.ericsson.se>, nsis@ietf.org
Message-id: <3C7BB555.F86161CB@era.ericsson.se>
MIME-version: 1.0
X-Mailer: Mozilla 4.61 [en] (Win98; I)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7bit
X-Accept-Language: en
References: <OFD7BFFF93.B3D084BE-ONC1256B6C.00390E71@net.alcatel.be>
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 <nsis.ietf.org>
X-BeenThere: nsis@ietf.org
Content-Transfer-Encoding: 7bit

Hi, Sven
We have different needs for different application scenarios. In a backbone
network a centralized solution is a very good
idea, especially when we have a possibility for a certain degree of
overprovisioning.
However, I think the archtecture has to cope with all different scenarios and
therefore has to flexible enough
without limiting the needs for different applications.

I would propose the we have two different scenarios explicitly in the
requirements draft:
One for a Bandwidth Broker case and one for a typical RSVP scenario.

Regards Lasse
sven.van_den_bosch@alcatel.be wrote:

> Hi Vlora,
>
> The idea is to have preprovisioned bandwidth pipes under the control of a
> local entity (NMS or router) that talks to the QC. The pipes implement a
> certain QoS (edge-to-edge delay, jitter, ...). The QC then only has very
> simple AC to do when a request arrives (check whether it fits in the pipe).
> This makes sense for a number of reasons:
> - A number of services will require similar QoS
> - If each flow is treated independently, the QoS may change with new
> incoming requests
> - The provisioning action is a local matter: it may be distributed or
> centralised.
>
> Regards,
> Sven.
>
> "Vlora Rexhepi (ELN)" <Vlora.Rexhepi@eln.ericsson.se> on 26/02/2002
> 11:19:09
>
>
>
>   To:          Sven VAN DEN BOSCH/BE/ALCATEL@ALCATEL
>
>   cc:
>
>
>
>   Subject      RE: [NSIS] WG requirements draft
>   :
>
>
> Hi Sven,
>
> |Allow me to jump into this discussion. I believe that the QI,
> |QC controller
> |model at least has the merit of clearly identifying the
> |interfaces that we
> |are deriving requirements for. When applied to various use
> |cases, it allows
> |to discover functionality that is common between different
> |entities in the
> |different use cases. In this way, we are looking for common
> |functionality
> |which will lead to the core nsis requirements.
> As I said the scenarios/use cases described in the draft are
> not the typical ones and while trying to apply the model to a
> typical scenario it was not as clear and straightforward to do
> so. Furthermore it turned out to be quite complex.
>
> |I am a bit surprised to see the discussion emphasize on centralised or
> |distributed resource management. While both obviously should
> |be allowed,
> |resource management is clearly a local (intra-domain) matter
> |and as such it
> |should probably be decoupled from the end-to-end issues. For
> |this reason,
> |we have introduced a two-level approach with preprovisioned bandwidth
> |pipes, allowing simple admission control and both distributed and
> |centralised resource management.
> This is because the model is according to my opinion clearly in favor
> of the centalised approach.
> What do you exactly mean by preprovisioned bandwidth pipes?
> Where are they going to be applied to?
>
> Regards,
> Vlora
>
> _______________________________________________
> 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 Feb 26 11:29: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 LAA06381
	for <nsis-archive@odin.ietf.org>; Tue, 26 Feb 2002 11:29:03 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id LAA21597
	for nsis-archive@odin.ietf.org; Tue, 26 Feb 2002 11:29:06 -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 LAA20725;
	Tue, 26 Feb 2002 11:19:19 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA20696
	for <nsis@optimus.ietf.org>; Tue, 26 Feb 2002 11:19:17 -0500 (EST)
Received: from aifhs8.alcatel.fr (una200.alcatel.fr [212.208.74.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05853
	for <nsis@ietf.org>; Tue, 26 Feb 2002 11:19:13 -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 RAA28654;
        Tue, 26 Feb 2002 17:18:42 +0100 (MET)
Received: from alcatel.fr ([139.54.208.120])
          by frmail30.netfr.alcatel.fr (Lotus Domino Release 5.0.8)
          with ESMTP id 2002022617184090:4580 ;
          Tue, 26 Feb 2002 17:18:40 +0100 
Message-ID: <3C7BB55E.F088C54F@alcatel.fr>
Date: Tue, 26 Feb 2002 17:18:38 +0100
Organization: Alcatel
X-Mailer: Mozilla 4.78 [fr] (Windows NT 5.0; U)
X-Accept-Language: fr
MIME-Version: 1.0
To: "Vlora Rexhepi (ELN)" <Vlora.Rexhepi@eln.ericsson.se>,
        NSIS Mailing List <nsis@ietf.org>,
        Marcus Brunner <brunner@ccrle.nec.de>
Subject: Definition of QI was: Re: [NSIS] WG requirements draft
References: <E244E44D6AB85E40AEEF7EAABE3545FAF78454@enleent104.nl.eu.ericsson.se>
X-MIMETrack: Itemize by SMTP Server on FRMAIL30/FR/ALCATEL(Release 5.0.8 |June 18, 2001) at
 02/26/2002 17:18:40,
	Serialize by Router on FRMAIL30/FR/ALCATEL(Release 5.0.8 |June 18, 2001) at
 02/26/2002 17:18:46,
	Serialize complete at 02/26/2002 17:18:46
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
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 <nsis.ietf.org>
X-BeenThere: nsis@ietf.org
Content-Transfer-Encoding: 7bit

Hello Vlora, Marcus, and NSIS,



> A question related to the definition of QI:
> The QoS Initiator is located in "the end system or within some
> part of the network, such as the edge router for an access
> network, or even an application layer proxy" and is used to
> communicate with higher layers. What does this mean for any other
> node, e.g. interior node? Can the QI be part of the interior node?

Marcus said on the list : "In todays RSVP you exactly have one QoS
controller and initiator on each node".
I understand here that the QoS controller receives signaling, while QoS
initiator sends it. If this is true, I would say that the figure 1 of
the WG draft could modified in order to be inline. Instead of :


            |         |        ...............
            |         |        . QoS Control .
            V         |        . Information .
       +----------------+      ...............     +----------------+
   --->|                |------------------------->|                |->
       |                |      QoS signalling      |                |
       | QoS Initiator  |     (request/query,      | QoS Controller |
       |                |   response/error etc.)   |                |
   <---|                |<-------------------------|                |<-
       +----------------+                          +----------------+
        ^              |                            ^              |

I believe we could have:


            |         |        ...............
            |         |        . QoS Control .
            V         |        . Information .
       +----------------+      ...............     +----------------+
       |                |------------------------->|QoS        /    |->
       |                |      QoS signalling      |Controller/     |
       | QoS Initiator  |     (request/query,      |         /  QoS |
       |                |   response/error etc.)   |        /initi- |
       |                |<-------------------------|       /  -ator |<-
       +----------------+                          +----------------+
        ^              |                            ^              |




Vlora, I think that could answer your question (in case of an RSVP
network). 


To conclude, in order to make things clear, I would propose a small
update of the QoS initiator and controller definition, without changing
its meaning -at least the one I understood-.
I would propose to add at the beginning of the definition for QoS
controller and initiator: "role of an entity responsible for...". The
same entity (an RSVP node) could have both roles.
 

Best regards,

-- 
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  Tue Feb 26 11:47: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 LAA09594
	for <nsis-archive@odin.ietf.org>; Tue, 26 Feb 2002 11:47:59 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id LAA23174
	for nsis-archive@odin.ietf.org; Tue, 26 Feb 2002 11:48:02 -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 LAA22835;
	Tue, 26 Feb 2002 11:43: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 LAA22716
	for <nsis@optimus.ietf.org>; Tue, 26 Feb 2002 11:43:22 -0500 (EST)
Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09398
	for <nsis@ietf.org>; Tue, 26 Feb 2002 11:43:04 -0500 (EST)
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 g1QGh7Zc001217
	for <nsis@ietf.org>; Tue, 26 Feb 2002 17:43:07 +0100 (MET)
Received: FROM esealnt746.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Tue Feb 26 17:43:06 2002 +0100
Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <F4HC927P>; Tue, 26 Feb 2002 17:43:05 +0100
Message-ID: <E244E44D6AB85E40AEEF7EAABE3545FAF78456@enleent104.nl.eu.ericsson.se>
From: "Vlora Rexhepi (ELN)" <Vlora.Rexhepi@eln.ericsson.se>
To: "'Alban.Couturier@alcatel.fr'" <Alban.Couturier@alcatel.fr>,
        "Vlora Rexhepi (ELN)" <Vlora.Rexhepi@eln.ericsson.se>,
        NSIS Mailing List
	 <nsis@ietf.org>,
        Marcus Brunner <brunner@ccrle.nec.de>
Subject: RE: Definition of QI was: Re: [NSIS] WG requirements draft
Date: Tue, 26 Feb 2002 17:42:58 +0100
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 <nsis.ietf.org>
X-BeenThere: nsis@ietf.org

Hi Alban,

As I already mentioned it so many times by now :-), I do 
apologise to all of you for this repetition...But I really think 
that the problem is not only the definitions but the whole model
as I do not consider it as a general one and as the requirements
are heavily dependent on these entities.
Changing the definition as you propose does not really solve 
the problem. 
I would rather prefer that the NSIS QoS requirements are not 
derived/related to this model or any other model, but are based 
on typical scenarios/use cases.

Some more comments inline:

|> A question related to the definition of QI:
|> The QoS Initiator is located in "the end system or within some
|> part of the network, such as the edge router for an access
|> network, or even an application layer proxy" and is used to
|> communicate with higher layers. What does this mean for any other
|> node, e.g. interior node? Can the QI be part of the interior node?
|
|Marcus said on the list : "In todays RSVP you exactly have one QoS
|controller and initiator on each node".
|I understand here that the QoS controller receives signaling, while QoS
|initiator sends it. If this is true, I would say that the figure 1 of
|the WG draft could modified in order to be inline. Instead of :
|
|
|            |         |        ...............
|            |         |        . QoS Control .
|            V         |        . Information .
|       +----------------+      ...............     +----------------+
|   --->|                |------------------------->|                |->
|       |                |      QoS signalling      |                |
|       | QoS Initiator  |     (request/query,      | QoS Controller |
|       |                |   response/error etc.)   |                |
|   <---|                |<-------------------------|                |<-
|       +----------------+                          +----------------+
|        ^              |                            ^              |
|
|I believe we could have:
|
|
|            |         |        ...............
|            |         |        . QoS Control .
|            V         |        . Information .
|       +----------------+      ...............     +----------------+
|       |                |------------------------->|QoS        /    |->
|       |                |      QoS signalling      |Controller/     |
|       | QoS Initiator  |     (request/query,      |         /  QoS |
|       |                |   response/error etc.)   |        /initi- |
|       |                |<-------------------------|       /  -ator |<-
|       +----------------+                          +----------------+
|        ^              |                            ^              |
|
Your proposal brings up the point I was trying to make that it will 
be quite difficult to map these entities into functions of real network 
entities and satisfying the QoS requirements at the same time. 

|Vlora, I think that could answer your question (in case of an RSVP
|network). 
But, doing this is contradictory to the definition of QI. 

|To conclude, in order to make things clear, I would propose a small
|update of the QoS initiator and controller definition, without changing
|its meaning -at least the one I understood-.
|I would propose to add at the beginning of the definition for QoS
|controller and initiator: "role of an entity responsible for...". The
|same entity (an RSVP node) could have both roles.
Than, in this case the NSIS signalling protocol will have problems
satisfying certain QoS requirements defined in the [NSIS] WG draft.

Regards,
Vlora

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



From daemon@optimus.ietf.org  Tue Feb 26 12:58: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 MAA13164
	for <nsis-archive@odin.ietf.org>; Tue, 26 Feb 2002 12:58:51 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id MAA07851
	for nsis-archive@odin.ietf.org; Tue, 26 Feb 2002 12:58: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 MAA07668;
	Tue, 26 Feb 2002 12:53:22 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA07631
	for <nsis@optimus.ietf.org>; Tue, 26 Feb 2002 12:53:18 -0500 (EST)
Received: from aifhs8.alcatel.fr (una200.alcatel.fr [212.208.74.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12979
	for <nsis@ietf.org>; Tue, 26 Feb 2002 12:53:15 -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 SAA16183;
        Tue, 26 Feb 2002 18:52:46 +0100 (MET)
Received: from alcatel.fr ([139.54.208.120])
          by frmail30.netfr.alcatel.fr (Lotus Domino Release 5.0.8)
          with ESMTP id 2002022618524531:5215 ;
          Tue, 26 Feb 2002 18:52:45 +0100 
Message-ID: <3C7BCB6A.C9F026E4@alcatel.fr>
Date: Tue, 26 Feb 2002 18:52:42 +0100
Organization: Alcatel
X-Mailer: Mozilla 4.78 [fr] (Windows NT 5.0; U)
X-Accept-Language: fr
MIME-Version: 1.0
To: "Vlora Rexhepi (ELN)" <Vlora.Rexhepi@eln.ericsson.se>
Cc: NSIS Mailing List <nsis@ietf.org>, Marcus Brunner <brunner@ccrle.nec.de>
Subject: Re: Definition of QI was: Re: [NSIS] WG requirements draft
References: <E244E44D6AB85E40AEEF7EAABE3545FAF78456@enleent104.nl.eu.ericsson.se>
X-MIMETrack: Itemize by SMTP Server on FRMAIL30/FR/ALCATEL(Release 5.0.8 |June 18, 2001) at
 02/26/2002 18:52:45,
	Serialize by Router on FRMAIL30/FR/ALCATEL(Release 5.0.8 |June 18, 2001) at
 02/26/2002 18:52:46,
	Serialize complete at 02/26/2002 18:52:46
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 MAA07632
Sender: nsis-admin@ietf.org
Errors-To: nsis-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Next Steps in Signaling <nsis.ietf.org>
X-BeenThere: nsis@ietf.org
Content-Transfer-Encoding: 8bit

Hi Vlora

"Vlora Rexhepi (ELN)" a écrit :
> 
> Hi Alban,
> 
> As I already mentioned it so many times by now :-), I do
> apologise to all of you for this repetition...But I really think
> that the problem is not only the definitions but the whole model
> as I do not consider it as a general one and as the requirements
> are heavily dependent on these entities.
> Changing the definition as you propose does not really solve
> the problem.

Vlora, I just wanted to propose a more clear definition, to answer your
question wih QI and interior nodes. I don't think I changed the meaning.
Marcus can agree, or disagree.

> I would rather prefer that the NSIS QoS requirements are not
> derived/related to this model or any other model, but are based
> on typical scenarios/use cases.
 

Yes, let's make use cases. We'll see if the terminology can still apply. 
Following a use case methodology, you must first define the system, and
an actor. So I identify 3 types of use cases:
1- system= a network, the actor= a terminal, and in this case, the
terminal plays the role of a QoS initiator 
2- system= a network, the actor is another network,
3- system= a network, the actor is a trusted application located in this
network (e.g. a SIP proxy etc..., playing the role of a QoS initiator) 
I don't see more general use cases, they covers everything we talked
about, don't they?
I think starting we these 3 families of use cases, we can do a lot of
work.


> Some more comments inline:
> 
> |> A question related to the definition of QI:
> |> The QoS Initiator is located in "the end system or within some
> |> part of the network, such as the edge router for an access
> |> network, or even an application layer proxy" and is used to
> |> communicate with higher layers. What does this mean for any other
> |> node, e.g. interior node? Can the QI be part of the interior node?
> |
> |Marcus said on the list : "In todays RSVP you exactly have one QoS
> |controller and initiator on each node".
> |I understand here that the QoS controller receives signaling, while QoS
> |initiator sends it. If this is true, I would say that the figure 1 of
> |the WG draft could modified in order to be inline. Instead of :
> |
> |
> |            |         |        ...............
> |            |         |        . QoS Control .
> |            V         |        . Information .
> |       +----------------+      ...............     +----------------+
> |   --->|                |------------------------->|                |->
> |       |                |      QoS signalling      |                |
> |       | QoS Initiator  |     (request/query,      | QoS Controller |
> |       |                |   response/error etc.)   |                |
> |   <---|                |<-------------------------|                |<-
> |       +----------------+                          +----------------+
> |        ^              |                            ^              |
> |
> |I believe we could have:
> |
> |
> |            |         |        ...............
> |            |         |        . QoS Control .
> |            V         |        . Information .
> |       +----------------+      ...............     +----------------+
> |       |                |------------------------->|QoS        /    |->
> |       |                |      QoS signalling      |Controller/     |
> |       | QoS Initiator  |     (request/query,      |         /  QoS |
> |       |                |   response/error etc.)   |        /initi- |
> |       |                |<-------------------------|       /  -ator |<-
> |       +----------------+                          +----------------+
> |        ^              |                            ^              |
> |
> Your proposal brings up the point I was trying to make that it will
> be quite difficult to map these entities into functions of real network
> entities and satisfying the QoS requirements at the same time.
>
> |Vlora, I think that could answer your question (in case of an RSVP
> |network).
> But, doing this is contradictory to the definition of QI.

Why?


> |To conclude, in order to make things clear, I would propose a small
> |update of the QoS initiator and controller definition, without changing
> |its meaning -at least the one I understood-.
> |I would propose to add at the beginning of the definition for QoS
> |controller and initiator: "role of an entity responsible for...". The
> |same entity (an RSVP node) could have both roles.
> Than, in this case the NSIS signalling protocol will have problems
> satisfying certain QoS requirements defined in the [NSIS] WG draft.

Really? Which ones? 
(But I would also add for my defense that I may have misunderstood the
QI definition.)

Best regards

-- 
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  Tue Feb 26 14: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 OAA17724
	for <nsis-archive@odin.ietf.org>; Tue, 26 Feb 2002 14:29:14 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id OAA13954
	for nsis-archive@odin.ietf.org; Tue, 26 Feb 2002 14:29:17 -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 OAA12581;
	Tue, 26 Feb 2002 14:01: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 OAA12539
	for <nsis@optimus.ietf.org>; Tue, 26 Feb 2002 14:01:31 -0500 (EST)
Received: from mail1.telekom.de ([62.225.183.235])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16487
	for <nsis@ietf.org>; Tue, 26 Feb 2002 14:01:27 -0500 (EST)
Received: from g8pbq.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Tue, 26 Feb 2002 19:59:23 +0100
Received: by G8PBQ.blf01.telekom.de with Internet Mail Service (5.5.2653.19)
	id <FFZ7KNGB>; Tue, 26 Feb 2002 20:00:55 +0100
Message-Id: <DFD875E85664D3118FA6080006277DE70362C8D0@U8PN2>
From: "Geib, Ruediger" <Ruediger.Geib@t-systems.com>
To: Vlora.Rexhepi@eln.ericsson.se
Cc: nsis@ietf.org
Subject: RE: [NSIS] WG requirements draft
Date: Tue, 26 Feb 2002 16:41:06 +0100
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 OAA12540
Sender: nsis-admin@ietf.org
Errors-To: nsis-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Next Steps in Signaling <nsis.ietf.org>
X-BeenThere: nsis@ietf.org
Content-Transfer-Encoding: 8bit

Hi Vlora,

> A question related to the definition of QI:
> The QoS Initiator is located in "the end system or within some
> part of the network, such as the edge router for an access 
> network, or even an application layer proxy" and is used to 
> communicate with higher layers. What does this mean for any other
> node, e.g. interior node? Can the QI be part of the interior node?

Why not? The definition doesn't exclude it.

Regards, Rüdiger

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



From daemon@optimus.ietf.org  Tue Feb 26 18:06: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 SAA24388
	for <nsis-archive@odin.ietf.org>; Tue, 26 Feb 2002 18:06:06 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id SAA27168
	for nsis-archive@odin.ietf.org; Tue, 26 Feb 2002 18:06: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 RAA26320;
	Tue, 26 Feb 2002 17:49: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 RAA26292
	for <nsis@optimus.ietf.org>; Tue, 26 Feb 2002 17:49:52 -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 RAA23980
	for <nsis@ietf.org>; Tue, 26 Feb 2002 17:49:48 -0500 (EST)
Received: from irams1.ira.uka.de ([129.13.10.5])
	by iraun2.uka.de with esmtp (Exim 3.30 #7 (Debian))
	id 16fqPv-0004nv-00; Tue, 26 Feb 2002 23:49:51 +0100
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 16fqPv-0003jp-00; Tue, 26 Feb 2002 23:49:51 +0100
Received: from i72pc127.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 g1QMnoW01222;
	Tue, 26 Feb 2002 23:49:50 +0100
Message-Id: <200202262249.g1QMnoW01222@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: "Vlora Rexhepi (ELN)" <Vlora.Rexhepi@eln.ericsson.se>,
        NSIS Mailing List <nsis@ietf.org>,
        Marcus Brunner <brunner@ccrle.nec.de>
Subject: Re: Definition of QI was: Re: [NSIS] WG requirements draft 
In-Reply-To: Message from Alban.Couturier@alcatel.fr 
   of "Tue, 26 Feb 2002 17:18:38 +0100." <3C7BB55E.F088C54F@alcatel.fr> 
References: <E244E44D6AB85E40AEEF7EAABE3545FAF78454@enleent104.nl.eu.ericsson.se>  <3C7BB55E.F088C54F@alcatel.fr> 
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Date: Tue, 26 Feb 2002 23:49:50 +0100
From: Roland Bless <bless@tm.uka.de>
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 <nsis.ietf.org>
X-BeenThere: nsis@ietf.org
Content-Transfer-Encoding: 8bit

Hi all,

I think we can solve this issue by not complicating the role model. 
It is also mentioned in section 4.1 of the nsis-req draft that QoS
Controllers interact with other QoS Controllers (as I understood). 
Therefore, there is signaling between different QCs. I don't think 
that we should complicate the model by explicitly defining every QC 
also as QI, although the QC initiates a further signaling transaction 
with another QC. I also don't think that the terms QC and QI are not 
generic enough to also cover a distributed approach. For a more 
complete model my suggestion (we add also a QoS Responder):

          Domain A             Domain B
        .......................      .......................
        .                     .      .                     .
QI <--> . QC <==> ... <==> QC . <==> . QC <==> ... <==> QC . <--> QR
        .......................      .......................
     a)       b)                  c)                           a)

1.) The QI can be an end system or signaling proxy acting on
    behalf of an end system. 
2.) There can be several QoS Controllers involved in signaling. 
    Some of the QCs may be located within one administrative
    domain (allowing the distributed case where each router or each edge
    router or several BBs are involved within such a domain) whereas 
    others are located within different domains. 
3.) Finally, we should add the QoS Responder (QR) in order to have 
    a "symmetric" model where the corresponding end system can be also 
    involved in signaling (e.g., to let a mobile terminal decide about 
    the priority of requests due to scarce bandwidth). As with the QI 
    the QR could be also a signaling proxy. Alternatively, the QC can 
    act as proxy.

I think that this model covers all the different signaling cases:
a) end <-> edge/network
b) network internal, also covering edge to edge (intra-domain)
c) network <-> network (inter-domain)
and considering the whole signaling scenario by combining
the parts
d) end to end (QI <--> QR indirectly via a)b)c), not at application level)

Won't this fit most use cases?

> > A question related to the definition of QI:
> > The QoS Initiator is located in "the end system or within some
> > part of the network, such as the edge router for an access
> > network, or even an application layer proxy" and is used to
> > communicate with higher layers. What does this mean for any other
> > node, e.g. interior node? Can the QI be part of the interior node?
> 
> Marcus said on the list : "In todays RSVP you exactly have one QoS
> controller and initiator on each node".
> I understand here that the QoS controller receives signaling, while QoS
> initiator sends it. If this is true, I would say that the figure 1 of
> the WG draft could modified in order to be inline. Instead of :
> 
> 
>             |         |        ...............
>             |         |        . QoS Control .
>             V         |        . Information .
>        +----------------+      ...............     +----------------+
>    --->|                |------------------------->|                |->
>        |                |      QoS signalling      |                |
>        | QoS Initiator  |     (request/query,      | QoS Controller |
>        |                |   response/error etc.)   |                |
>    <---|                |<-------------------------|                |<-
>        +----------------+                          +----------------+
>         ^              |                            ^              |
> 
> I believe we could have:
> 
> 
>             |         |        ...............
>             |         |        . QoS Control .
>             V         |        . Information .
>        +----------------+      ...............     +----------------+
>        |                |------------------------->|QoS        /    |->
>        |                |      QoS signalling      |Controller/     |
>        | QoS Initiator  |     (request/query,      |         /  QoS |
>        |                |   response/error etc.)   |        /initi- |
>        |                |<-------------------------|       /  -ator |<-
>        +----------------+                          +----------------+
>         ^              |                            ^              |
> 
> 
> 
> 
> Vlora, I think that could answer your question (in case of an RSVP
> network). 
> 
> 
> To conclude, in order to make things clear, I would propose a small
> update of the QoS initiator and controller definition, without changing
> its meaning -at least the one I understood-.
> I would propose to add at the beginning of the definition for QoS
> controller and initiator: "role of an entity responsible for...". The
> same entity (an RSVP node) could have both roles.
>  
> 
> Best regards,
> 
> -- 
> 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
> ---------------------------------------------------------------------


-- 
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  Tue Feb 26 18:16: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 SAA24647
	for <nsis-archive@odin.ietf.org>; Tue, 26 Feb 2002 18:16:02 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id SAA27688
	for nsis-archive@odin.ietf.org; Tue, 26 Feb 2002 18:16:05 -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 SAA27266;
	Tue, 26 Feb 2002 18:08: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 SAA27233
	for <nsis@optimus.ietf.org>; Tue, 26 Feb 2002 18:08:34 -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 SAA24429
	for <nsis@ietf.org>; Tue, 26 Feb 2002 18:08:30 -0500 (EST)
Received: from irams1.ira.uka.de ([129.13.10.5])
	by iraun2.uka.de with esmtp (Exim 3.30 #7 (Debian))
	id 16fqi1-00054R-00; Wed, 27 Feb 2002 00:08:33 +0100
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 16fqi0-00041l-00; Wed, 27 Feb 2002 00:08:32 +0100
Received: from i72pc127.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 g1QN8WW01785;
	Wed, 27 Feb 2002 00:08:32 +0100
Message-Id: <200202262308.g1QN8WW01785@i72pc127.tm.uka.de>
X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4+dev
To: danny.goderis@alcatel.be
cc: "Vlora Rexhepi (ELN)" <Vlora.Rexhepi@eln.ericsson.se>,
        "'David.Partain@ericsson.com'" <David.Partain@ericsson.com>,
        NSIS Mailing List <nsis@ietf.org>
Subject: Re: [NSIS] WG requirements draft 
In-Reply-To: Message from danny.goderis@alcatel.be 
   of "Tue, 26 Feb 2002 11:56:08 +0100." <3C7B69C8.53539C06@alcatel.be> 
References: <OF75B625A2.49A69D7B-ONC1256B6C.00319D9F@alcatel.be>  <3C7B69C8.53539C06@alcatel.be> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 27 Feb 2002 00:08:32 +0100
From: Roland Bless <bless@tm.uka.de>
Sender: nsis-admin@ietf.org
Errors-To: nsis-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Next Steps in Signaling <nsis.ietf.org>
X-BeenThere: nsis@ietf.org

Hi Danny,

> I agree with you that much of these approaches do not scale in DiffServ
> networks: especially you can not "trigger"/configure (by e.g. the COPS
> protocol) the routers on a micro-flow bases from a central entity "BB".
> This approach even scales worse than IntServ all the way. In my view,
> the DiffServ routers should not **at all** be triggered by a
> per-micro-flow signaling/reservation protocol (not in band alike RSVP
> and not out-of-band from a BB-alike entity). 

I disagree here, but I don't think we should discuss different 
architectural approaches now, or even exclude some approaches.
All have their pros and cons. In my view, it should be possible
to define nsis protocols that allow different QoS architectures
within domains. Thus, neither for the requirements nor for the
signaling protocol(s) it should matter whether QCs are routers
or BBs.

I'd like to bring up two issues here:
- One should really carefully think about the processing burden
  for routers (even edge routers) caused by letting them act as 
  QoS controllers rather than one or more dedicated QC systems.
- Most architectures only consider scalability/performance within
  a single domain. We should also work on global scalability, i.e.
  considering the multi-domain/multi-AS case.

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  Wed Feb 27 03:29: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 DAA13727
	for <nsis-archive@odin.ietf.org>; Wed, 27 Feb 2002 03:29:29 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id DAA02321
	for nsis-archive@odin.ietf.org; Wed, 27 Feb 2002 03: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 DAA02032;
	Wed, 27 Feb 2002 03:16: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 DAA02001
	for <nsis@optimus.ietf.org>; Wed, 27 Feb 2002 03:16:45 -0500 (EST)
Received: from mail1.telekom.de ([62.225.183.235])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13613
	for <nsis@ietf.org>; Wed, 27 Feb 2002 03:16:42 -0500 (EST)
Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Wed, 27 Feb 2002 09:14:38 +0100
Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19)
	id <F3BADM08>; Wed, 27 Feb 2002 09:16:11 +0100
Message-Id: <DFD875E85664D3118FA6080006277DE70362C8D2@U8PN2>
From: "Geib, Ruediger" <Ruediger.Geib@t-systems.com>
To: bless@tm.uka.de
Cc: nsis@ietf.org
Subject: RE: Definition of QI was: Re: [NSIS] WG requirements draft 
Date: Wed, 27 Feb 2002 09:16:09 +0100
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 DAA02002
Sender: nsis-admin@ietf.org
Errors-To: nsis-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Next Steps in Signaling <nsis.ietf.org>
X-BeenThere: nsis@ietf.org
Content-Transfer-Encoding: 8bit

Roland,

I agree with your view completely. Let's go on with the requirements and stop a discussion of architectures. That's part of the solutions.

A requirement may be that in some cases a "QC" may act as "QI": An edge to edge QoS tunnel set up (maybe even spanning several domains). This would allow the tunnel entry point QC to do per flow edge to edge admission control once the QI requests service for the tunnel destination domain. To me this is the simplest and therefore most desireable way of per service reservation aggregation.

Regards, Rüdiger 

> Hi all,
> 
> I think we can solve this issue by not complicating the role model. 
> It is also mentioned in section 4.1 of the nsis-req draft that QoS
> Controllers interact with other QoS Controllers (as I understood). 
> Therefore, there is signaling between different QCs. I don't think 
> that we should complicate the model by explicitly defining every QC 
> also as QI, although the QC initiates a further signaling transaction 
> with another QC. I also don't think that the terms QC and QI are not 
> generic enough to also cover a distributed approach. For a more 
> complete model my suggestion (we add also a QoS Responder):
> 
>           Domain A             Domain B
>         .......................      .......................
>         .                     .      .                     .
> QI <--> . QC <==> ... <==> QC . <==> . QC <==> ... <==> QC . <--> QR
>         .......................      .......................
>      a)       b)                  c)                           a)
> 
> 1.) The QI can be an end system or signaling proxy acting on
>     behalf of an end system. 
> 2.) There can be several QoS Controllers involved in signaling. 
>     Some of the QCs may be located within one administrative
>     domain (allowing the distributed case where each router 
>     or each edge router or several BBs are involved within
>     such a domain) whereas others are located within different
>     domains. 
> 3.) Finally, we should add the QoS Responder (QR) in order to have 
>     a "symmetric" model where the corresponding end system
>     can be also involved in signaling (e.g., to let a mobile terminal 
>     decide about the priority of requests due to scarce bandwidth).
>     As with the QI the QR could be also a signaling proxy. 
>     Alternatively, the QC can act as proxy.
> 
> I think that this model covers all the different signaling cases:
> a) end <-> edge/network
> b) network internal, also covering edge to edge (intra-domain)
> c) network <-> network (inter-domain)
> and considering the whole signaling scenario by combining
> the parts
> d) end to end (QI <--> QR indirectly via a)b)c), not at 
> application level)
> 
> Won't this fit most use cases?
> 

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



From daemon@optimus.ietf.org  Wed Feb 27 04:12: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 EAA14522
	for <nsis-archive@odin.ietf.org>; Wed, 27 Feb 2002 04:12:52 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id EAA05061
	for nsis-archive@odin.ietf.org; Wed, 27 Feb 2002 04:12: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 EAA04749;
	Wed, 27 Feb 2002 04:08: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 EAA04715
	for <nsis@optimus.ietf.org>; Wed, 27 Feb 2002 04:08:18 -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 EAA14478
	for <nsis@ietf.org>; Wed, 27 Feb 2002 04:08:15 -0500 (EST)
From: danny.goderis@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 g1R97jE17002;
	Wed, 27 Feb 2002 10:07:45 +0100 (MET)
Received: from alcatel.be ([138.203.136.5])
          by bemail04.net.alcatel.be (Lotus Domino Release 5.0.8)
          with ESMTP id 2002022710074373:429 ;
          Wed, 27 Feb 2002 10:07:43 +0100 
Message-ID: <3C7CA1E1.781BDC1C@alcatel.be>
Date: Wed, 27 Feb 2002 10:07:45 +0100
Organization: Alcatel CRC Antwerp
X-Mailer: Mozilla 4.72 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: "Lars.Westberg" <Lars.Westberg@era.ericsson.se>
Cc: sven.van_den_bosch@alcatel.be,
        "Vlora Rexhepi (ELN)" <Vlora.Rexhepi@eln.ericsson.se>, nsis@ietf.org
Subject: Re: [NSIS] WG requirements draft
References: <OFE23FD267.9CEC680E-ONC1256B6C.0059A2CE@alcatel.be>
X-MIMETrack: Itemize by SMTP Server on BEMAIL04/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at
 02/27/2002 10:07:44,
	Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at
 02/27/2002 10:07:44,
	Serialize complete at 02/27/2002 10:07:44
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
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 <nsis.ietf.org>
X-BeenThere: nsis@ietf.org
Content-Transfer-Encoding: 7bit

Hi Larsse,

I agree that the architecture should be flexible to cope with the (main)
different scenarios, especially access/core may involve different
scenarios, models,... It seems to me that part of the confusion is
because we want to write down requirements for a kind of abstract "QoS
signaling interface" while in fact we clearly have in mind some kind of
models/use cases. 

It seems that we could have 2 approaches to tackle the problem.

- One possibility is to try to define generic functional entities (like
QI and QC) and then - afterwards - to see how these entities are
"instantiated" concretely on a certain interface.

- Another possibility is to try to identify the basic scenarios, to
recognise that there are possibly different Qos interfaces (with
different requirements). For example, i clearly see a difference between
access QoS and core QoS (interface host - edge and edge -core). In the
core, we could, as you suggest, identify two approaches (centralised
/distributed) and try to see how then can interwork. 

In the draft we published, we identified different types of interfaces
(especially access/core) and then tried to see how the generic
definitions of QI and QC apply and list the basic requirements for the
QI-to-QC interface (as we see it). I must admit it's not an easy
excercise.

At current stage, both approaches can be tried and we can see how things
convergence: try to have generic defintions of functional entities and
see how they apply to concrete situations (and of course, concrete
scenarios help to define generic functions...)

Regards,
Danny

"Lars.Westberg" wrote:
> 
> Hi, Sven
> We have different needs for different application scenarios. In a backbone
> network a centralized solution is a very good
> idea, especially when we have a possibility for a certain degree of
> overprovisioning.
> However, I think the archtecture has to cope with all different scenarios and
> therefore has to flexible enough
> without limiting the needs for different applications.
> 
> I would propose the we have two different scenarios explicitly in the
> requirements draft:
> One for a Bandwidth Broker case and one for a typical RSVP scenario.
> 
> Regards Lasse
> sven.van_den_bosch@alcatel.be wrote:
> 
> > Hi Vlora,
> >
> > The idea is to have preprovisioned bandwidth pipes under the control of a
> > local entity (NMS or router) that talks to the QC. The pipes implement a
> > certain QoS (edge-to-edge delay, jitter, ...). The QC then only has very
> > simple AC to do when a request arrives (check whether it fits in the pipe).
> > This makes sense for a number of reasons:
> > - A number of services will require similar QoS
> > - If each flow is treated independently, the QoS may change with new
> > incoming requests
> > - The provisioning action is a local matter: it may be distributed or
> > centralised.
> >
> > Regards,
> > Sven.
> >
> > "Vlora Rexhepi (ELN)" <Vlora.Rexhepi@eln.ericsson.se> on 26/02/2002
> > 11:19:09
> >
> >
> >
> >   To:          Sven VAN DEN BOSCH/BE/ALCATEL@ALCATEL
> >
> >   cc:
> >
> >
> >
> >   Subject      RE: [NSIS] WG requirements draft
> >   :
> >
> >
> > Hi Sven,
> >
> > |Allow me to jump into this discussion. I believe that the QI,
> > |QC controller
> > |model at least has the merit of clearly identifying the
> > |interfaces that we
> > |are deriving requirements for. When applied to various use
> > |cases, it allows
> > |to discover functionality that is common between different
> > |entities in the
> > |different use cases. In this way, we are looking for common
> > |functionality
> > |which will lead to the core nsis requirements.
> > As I said the scenarios/use cases described in the draft are
> > not the typical ones and while trying to apply the model to a
> > typical scenario it was not as clear and straightforward to do
> > so. Furthermore it turned out to be quite complex.
> >
> > |I am a bit surprised to see the discussion emphasize on centralised or
> > |distributed resource management. While both obviously should
> > |be allowed,
> > |resource management is clearly a local (intra-domain) matter
> > |and as such it
> > |should probably be decoupled from the end-to-end issues. For
> > |this reason,
> > |we have introduced a two-level approach with preprovisioned bandwidth
> > |pipes, allowing simple admission control and both distributed and
> > |centralised resource management.
> > This is because the model is according to my opinion clearly in favor
> > of the centalised approach.
> > What do you exactly mean by preprovisioned bandwidth pipes?
> > Where are they going to be applied to?
> >
> > Regards,
> > Vlora
> >
> > _______________________________________________
> > 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 Feb 27 04:40: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 EAA14971
	for <nsis-archive@odin.ietf.org>; Wed, 27 Feb 2002 04:40:01 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id EAA06664
	for nsis-archive@odin.ietf.org; Wed, 27 Feb 2002 04:40: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 EAA05386;
	Wed, 27 Feb 2002 04:22: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 EAA05355
	for <nsis@optimus.ietf.org>; Wed, 27 Feb 2002 04:22:11 -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 EAA14659
	for <nsis@ietf.org>; Wed, 27 Feb 2002 04:22:06 -0500 (EST)
From: danny.goderis@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 g1R9KrF20708;
	Wed, 27 Feb 2002 10:20:53 +0100 (MET)
Received: from alcatel.be ([138.203.136.5])
          by bemail04.net.alcatel.be (Lotus Domino Release 5.0.8)
          with ESMTP id 2002022710205251:470 ;
          Wed, 27 Feb 2002 10:20:52 +0100 
Message-ID: <3C7CA4F5.1BF53A0B@alcatel.be>
Date: Wed, 27 Feb 2002 10:20:53 +0100
Organization: Alcatel CRC Antwerp
X-Mailer: Mozilla 4.72 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Roland Bless <bless@tm.uka.de>
Cc: "Vlora Rexhepi (ELN)" <Vlora.Rexhepi@eln.ericsson.se>,
        "'David.Partain@ericsson.com'" <David.Partain@ericsson.com>,
        NSIS Mailing List <nsis@ietf.org>
Subject: Re: [NSIS] WG requirements draft
References: <OF2E477E48.F9BDC17D-ONC1256B6C.007F27B1@alcatel.be>
X-MIMETrack: Itemize by SMTP Server on BEMAIL04/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at
 02/27/2002 10:20:52,
	Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at
 02/27/2002 10:20:53,
	Serialize complete at 02/27/2002 10:20:53
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
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 <nsis.ietf.org>
X-BeenThere: nsis@ietf.org
Content-Transfer-Encoding: 7bit

Hi Roland,

It was not my intention to exclude whatever approach. 

Basically i agree that NSIS QoS signaling should allow for interworking
of different QoS approaches/provisioning and the NSIS protocol could be
a kind of "signaling glue" between different approaches. 

My main concern for now is that requirements are discussed for an
"abstract" protocol without taking into account the concrete interfaces
(scenarios) where the protocol will be applied and thus to forget
concrete problems (like scalability) that are already discussed for a
long time.

Best regards,
Danny

Roland Bless wrote:
> 
> Hi Danny,
> 
> > I agree with you that much of these approaches do not scale in DiffServ
> > networks: especially you can not "trigger"/configure (by e.g. the COPS
> > protocol) the routers on a micro-flow bases from a central entity "BB".
> > This approach even scales worse than IntServ all the way. In my view,
> > the DiffServ routers should not **at all** be triggered by a
> > per-micro-flow signaling/reservation protocol (not in band alike RSVP
> > and not out-of-band from a BB-alike entity).
> 
> I disagree here, but I don't think we should discuss different
> architectural approaches now, or even exclude some approaches.
> All have their pros and cons. In my view, it should be possible
> to define nsis protocols that allow different QoS architectures
> within domains. Thus, neither for the requirements nor for the
> signaling protocol(s) it should matter whether QCs are routers
> or BBs.
> 
> I'd like to bring up two issues here:
> - One should really carefully think about the processing burden
>   for routers (even edge routers) caused by letting them act as
>   QoS controllers rather than one or more dedicated QC systems.
> - Most architectures only consider scalability/performance within
>   a single domain. We should also work on global scalability, i.e.
>   considering the multi-domain/multi-AS case.
> 
> 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

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



From daemon@optimus.ietf.org  Wed Feb 27 05:33: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 FAA15787
	for <nsis-archive@odin.ietf.org>; Wed, 27 Feb 2002 05:33:12 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id FAA09410
	for nsis-archive@odin.ietf.org; Wed, 27 Feb 2002 05:32:20 -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 FAA08176;
	Wed, 27 Feb 2002 05:11: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 FAA08145
	for <nsis@optimus.ietf.org>; Wed, 27 Feb 2002 05:11:12 -0500 (EST)
Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15508
	for <nsis@ietf.org>; Wed, 27 Feb 2002 05:11:08 -0500 (EST)
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 g1RABBZc021144
	for <nsis@ietf.org>; Wed, 27 Feb 2002 11:11:11 +0100 (MET)
Received: FROM esealnt747.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Wed Feb 27 11:11:10 2002 +0100
Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <F4H171L1>; Wed, 27 Feb 2002 11:04:25 +0100
Message-ID: <E244E44D6AB85E40AEEF7EAABE3545FAF7845A@enleent104.nl.eu.ericsson.se>
From: "Vlora Rexhepi (ELN)" <Vlora.Rexhepi@eln.ericsson.se>
To: "'sven.van_den_bosch@alcatel.be'" <sven.van_den_bosch@alcatel.be>,
        "Vlora Rexhepi (ELN)" <Vlora.Rexhepi@eln.ericsson.se>
Cc: nsis@ietf.org
Subject: RE: [NSIS] WG requirements draft
Date: Wed, 27 Feb 2002 11:04:22 +0100
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 <nsis.ietf.org>
X-BeenThere: nsis@ietf.org

Hi Sven,

I have not read your draft yet, and you might have explained 
this there already...
The idea of QoS pipes seems interesting, but what will be used 
for communication between this local entity and the QC?

Regards,
Vlora


|-----Original Message-----
|From: sven.van_den_bosch@alcatel.be
|[mailto:sven.van_den_bosch@alcatel.be]
|Sent: Tuesday, February 26, 2002 1:37 PM
|To: Vlora Rexhepi (ELN)
|Cc: nsis@ietf.org
|Subject: RE: [NSIS] WG requirements draft
|
|
|Hi Vlora,
|
|The idea is to have preprovisioned bandwidth pipes under the 
|control of a
|local entity (NMS or router) that talks to the QC. The pipes 
|implement a
|certain QoS (edge-to-edge delay, jitter, ...). The QC then 
|only has very
|simple AC to do when a request arrives (check whether it fits 
|in the pipe).
|This makes sense for a number of reasons:
|- A number of services will require similar QoS
|- If each flow is treated independently, the QoS may change with new
|incoming requests
|- The provisioning action is a local matter: it may be distributed or
|centralised.
|
|Regards,
|Sven.
|
|
|
|
|
|"Vlora Rexhepi (ELN)" <Vlora.Rexhepi@eln.ericsson.se> on 26/02/2002
|11:19:09
|                                                              
|                                                              
|                                                              
|  To:          Sven VAN DEN BOSCH/BE/ALCATEL@ALCATEL          
|                                                              
|  cc:                                                         
|                                                              
|                                                              
|                                                              
|  Subject      RE: [NSIS] WG requirements draft               
|  :                                                           
|                                                              
|
|
|
|
|
|Hi Sven,
|
||Allow me to jump into this discussion. I believe that the QI,
||QC controller
||model at least has the merit of clearly identifying the
||interfaces that we
||are deriving requirements for. When applied to various use
||cases, it allows
||to discover functionality that is common between different
||entities in the
||different use cases. In this way, we are looking for common
||functionality
||which will lead to the core nsis requirements.
|As I said the scenarios/use cases described in the draft are
|not the typical ones and while trying to apply the model to a
|typical scenario it was not as clear and straightforward to do
|so. Furthermore it turned out to be quite complex.
|
|
||I am a bit surprised to see the discussion emphasize on centralised or
||distributed resource management. While both obviously should
||be allowed,
||resource management is clearly a local (intra-domain) matter
||and as such it
||should probably be decoupled from the end-to-end issues. For
||this reason,
||we have introduced a two-level approach with preprovisioned bandwidth
||pipes, allowing simple admission control and both distributed and
||centralised resource management.
|This is because the model is according to my opinion clearly in favor
|of the centalised approach.
|What do you exactly mean by preprovisioned bandwidth pipes?
|Where are they going to be applied to?
|
|Regards,
|Vlora
|
|
|

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



From daemon@optimus.ietf.org  Wed Feb 27 06:06: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 GAA16177
	for <nsis-archive@odin.ietf.org>; Wed, 27 Feb 2002 06:06:17 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id GAA11109
	for nsis-archive@odin.ietf.org; Wed, 27 Feb 2002 06:06: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 FAA09803;
	Wed, 27 Feb 2002 05: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 FAA09772
	for <nsis@optimus.ietf.org>; Wed, 27 Feb 2002 05:44:11 -0500 (EST)
Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15910
	for <nsis@ietf.org>; Wed, 27 Feb 2002 05:43:58 -0500 (EST)
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 g1RAi1Zc007704
	for <nsis@ietf.org>; Wed, 27 Feb 2002 11:44:01 +0100 (MET)
Received: FROM esealnt747.al.sw.ericsson.se BY esealnt461 ; Wed Feb 27 11:44:00 2002 +0100
Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <F4H171X8>; Wed, 27 Feb 2002 11:37:15 +0100
Message-ID: <E244E44D6AB85E40AEEF7EAABE3545FA8234EB@enleent104.nl.eu.ericsson.se>
From: "Georgios Karagiannis (ELN)" <Georgios.Karagiannis@eln.ericsson.se>
To: "'john.loughney@nokia.com'" <john.loughney@nokia.com>,
        "'Marcus Brunner'" <brunner@ccrle.nec.de>
Cc: nsis@ietf.org
Date: Wed, 27 Feb 2002 11:37:14 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [NSIS] Modularity and grouping QoS requirements
Sender: nsis-admin@ietf.org
Errors-To: nsis-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Next Steps in Signaling <nsis.ietf.org>
X-BeenThere: nsis@ietf.org

Dear John and Marcus

One of the outcomes of the NSIS meeting in Salt Lake City was 
to start working on defining QoS requirements based on scenario cases.

Furthermore, we all agreed that modularity is very important;
During that meeting many people agreed that after the QoS requirements 
are defined, then they will be grouped according to network  
interfaces (e.g., UNI (access), NNI (backbone));

A reasonable way of doing the above, is in my opinion the following:
* First define the scenario cases;
* Second using these scenario cases, define which QoS requirements will have 
   to be satisfied on each network interface, and on each network node type, e.g.,
   host, access router, interior router, border router, edge router, proxy, bandwidth broker, ...
* Third the outcome of this separation of QoS requirements it will result in 
  an efficient grouping of the QoS requirements.

After the QOS requirements grouping is done, then we could define a QoS model.
This QoS model could have entities such as a QoS initiator and a QoS controller.


The problem I have with the NSIS WG requirements draft is that these sequence of
doing things is very much opposite to the sequence mentioned above. In the NSIS WG
requirements draft the following sequence of actions is followed:
* First a QoS model and its QoS model entities are defined. At this stage, these 
  QoS model entities, e.g., QoS initiator and QoS controller, are not representing 
   network entities.
 * Second, the QoS requirements are grouped according to these QoS  model entities 
   and not grouped according to any network interface or any network node type!
* Third, the QoS model entites are assigned to specific network node types. In my opinion 
  this  step is difficult to be accomplished and for some scenarios is impossible to be done.


Best regards,
Georgios







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



From daemon@optimus.ietf.org  Wed Feb 27 06:10: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 GAA16239
	for <nsis-archive@odin.ietf.org>; Wed, 27 Feb 2002 06:10:23 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id GAA11287
	for nsis-archive@odin.ietf.org; Wed, 27 Feb 2002 06:10: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 FAA08702;
	Wed, 27 Feb 2002 05:23:52 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA08630
	for <nsis@optimus.ietf.org>; Wed, 27 Feb 2002 05:23:46 -0500 (EST)
Received: from aifhs8.alcatel.fr (una200.alcatel.fr [212.208.74.200])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15661
	for <nsis@ietf.org>; Wed, 27 Feb 2002 05:23:41 -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 LAA24669;
        Wed, 27 Feb 2002 11:22:38 +0100 (MET)
Received: from alcatel.fr ([139.54.208.120])
          by frmail30.netfr.alcatel.fr (Lotus Domino Release 5.0.8)
          with ESMTP id 2002022711223618:2185 ;
          Wed, 27 Feb 2002 11:22:36 +0100 
Message-ID: <3C7CB36D.DB00E206@alcatel.fr>
Date: Wed, 27 Feb 2002 11:22:37 +0100
Organization: Alcatel
X-Mailer: Mozilla 4.78 [fr] (Windows NT 5.0; U)
X-Accept-Language: fr
MIME-Version: 1.0
To: Roland Bless <bless@tm.uka.de>
Cc: "Vlora Rexhepi (ELN)" <Vlora.Rexhepi@eln.ericsson.se>,
        NSIS Mailing List <nsis@ietf.org>,
        Marcus Brunner <brunner@ccrle.nec.de>
Subject: Re: Definition of QI was: Re: [NSIS] WG requirements draft
References: <E244E44D6AB85E40AEEF7EAABE3545FAF78454@enleent104.nl.eu.ericsson.se>  <3C7BB55E.F088C54F@alcatel.fr> <200202262249.g1QMnoW01222@i72pc127.tm.uka.de>
X-MIMETrack: Itemize by SMTP Server on FRMAIL30/FR/ALCATEL(Release 5.0.8 |June 18, 2001) at
 02/27/2002 11:22:36,
	Serialize by Router on FRMAIL30/FR/ALCATEL(Release 5.0.8 |June 18, 2001) at
 02/27/2002 11:22:37,
	Serialize complete at 02/27/2002 11:22:37
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 FAA08631
Sender: nsis-admin@ietf.org
Errors-To: nsis-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Next Steps in Signaling <nsis.ietf.org>
X-BeenThere: nsis@ietf.org
Content-Transfer-Encoding: 8bit

Hi Roland and all

Roland Bless a écrit :
> 
> Hi all,
> 
> I think we can solve this issue by not complicating the role model.
> It is also mentioned in section 4.1 of the nsis-req draft that QoS
> Controllers interact with other QoS Controllers (as I understood).
> Therefore, there is signaling between different QCs. I don't think
> that we should complicate the model by explicitly defining every QC
> also as QI, although the QC initiates a further signaling transaction
> with another QC. I also don't think that the terms QC and QI are not
> generic enough to also cover a distributed approach. For a more
> complete model my suggestion (we add also a QoS Responder):
> 
>           Domain A             Domain B
>         .......................      .......................
>         .                     .      .                     .
> QI <--> . QC <==> ... <==> QC . <==> . QC <==> ... <==> QC . <--> QR
>         .......................      .......................
>      a)       b)                  c)                           a)
> 
> 1.) The QI can be an end system or signaling proxy acting on
>     behalf of an end system.
> 2.) There can be several QoS Controllers involved in signaling.
>     Some of the QCs may be located within one administrative
>     domain (allowing the distributed case where each router or each edge
>     router or several BBs are involved within such a domain) whereas
>     others are located within different domains.
> 3.) Finally, we should add the QoS Responder (QR) in order to have
>     a "symmetric" model where the corresponding end system can be also
>     involved in signaling (e.g., to let a mobile terminal decide about
>     the priority of requests due to scarce bandwidth). As with the QI
>     the QR could be also a signaling proxy. Alternatively, the QC can
>     act as proxy.
> 
> I think that this model covers all the different signaling cases:
> a) end <-> edge/network
> b) network internal, also covering edge to edge (intra-domain)
> c) network <-> network (inter-domain)
> and considering the whole signaling scenario by combining
> the parts
> d) end to end (QI <--> QR indirectly via a)b)c), not at application level)
> 
> Won't this fit most use cases?


Roland, any model works fine, I don't think the current wg draft is not
generic enough. I remarked there is was a subtle misunderstanding about
QoS initiator and controller definition.(cf Can the QI be part of the
interior node?)

Some people think a QoS controller is a function, and that is your
opinion. You make a model based on that definition, and it is OK for me
(I would add QR should be optionnal because the last QC could decide not
to forward it. This depends of course of the precise definition of QR).
But with this formalism, you can't say that an RSVP node is a QoS
initiator and controler: it is only a QoS controller.

I proposed to say the QoS controller is a role, this allows to say an
RSVP router is a QoS controler, and initiator at the same time. (by the
way, this looks like the PDP and PEP definition in COPS, or the
agent/manager in SNMP. A server can be a PDP, while talking to a router,
and a PEP, while talking to another server.)

I invite the authors of the wg draft to fix this misunderstanding.
Anyway, this has a very little impact (if any) on the work done. 



> > > A question related to the definition of QI:
> > > The QoS Initiator is located in "the end system or within some
> > > part of the network, such as the edge router for an access
> > > network, or even an application layer proxy" and is used to
> > > communicate with higher layers. What does this mean for any other
> > > node, e.g. interior node? Can the QI be part of the interior node?
> >
> > Marcus said on the list : "In todays RSVP you exactly have one QoS
> > controller and initiator on each node".
> > I understand here that the QoS controller receives signaling, while QoS
> > initiator sends it. If this is true, I would say that the figure 1 of
> > the WG draft could modified in order to be inline. Instead of :
> >
> >
> >             |         |        ...............
> >             |         |        . QoS Control .
> >             V         |        . Information .
> >        +----------------+      ...............     +----------------+
> >    --->|                |------------------------->|                |->
> >        |                |      QoS signalling      |                |
> >        | QoS Initiator  |     (request/query,      | QoS Controller |
> >        |                |   response/error etc.)   |                |
> >    <---|                |<-------------------------|                |<-
> >        +----------------+                          +----------------+
> >         ^              |                            ^              |
> >
> > I believe we could have:
> >
> >
> >             |         |        ...............
> >             |         |        . QoS Control .
> >             V         |        . Information .
> >        +----------------+      ...............     +----------------+
> >        |                |------------------------->|QoS        /    |->
> >        |                |      QoS signalling      |Controller/     |
> >        | QoS Initiator  |     (request/query,      |         /  QoS |
> >        |                |   response/error etc.)   |        /initi- |
> >        |                |<-------------------------|       /  -ator |<-
> >        +----------------+                          +----------------+
> >         ^              |                            ^              |
> >
> >
> >
> >
> > Vlora, I think that could answer your question (in case of an RSVP
> > network).
> >
> >
> > To conclude, in order to make things clear, I would propose a small
> > update of the QoS initiator and controller definition, without changing
> > its meaning -at least the one I understood-.
> > I would propose to add at the beginning of the definition for QoS
> > controller and initiator: "role of an entity responsible for...". The
> > same entity (an RSVP node) could have both roles.


Best regards,
Alban

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



From daemon@optimus.ietf.org  Wed Feb 27 06:17: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 GAA16349
	for <nsis-archive@odin.ietf.org>; Wed, 27 Feb 2002 06:17:02 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id GAA11653
	for nsis-archive@odin.ietf.org; Wed, 27 Feb 2002 06:17:06 -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 GAA10933;
	Wed, 27 Feb 2002 06:01:59 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA10900
	for <nsis@optimus.ietf.org>; Wed, 27 Feb 2002 06:01:57 -0500 (EST)
Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16141
	for <nsis@ietf.org>; Wed, 27 Feb 2002 06:01:51 -0500 (EST)
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 g1RB1tZc015945
	for <nsis@ietf.org>; Wed, 27 Feb 2002 12:01:55 +0100 (MET)
Received: FROM esealnt746.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Wed Feb 27 12:01:41 2002 +0100
Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <F4HC9M3M>; Wed, 27 Feb 2002 12:01:42 +0100
Message-ID: <E244E44D6AB85E40AEEF7EAABE3545FAF7845D@enleent104.nl.eu.ericsson.se>
From: "Vlora Rexhepi (ELN)" <Vlora.Rexhepi@eln.ericsson.se>
To: "'Alban.Couturier@alcatel.fr'" <Alban.Couturier@alcatel.fr>,
        Roland Bless <bless@tm.uka.de>
Cc: "Vlora Rexhepi (ELN)" <Vlora.Rexhepi@eln.ericsson.se>,
        NSIS Mailing List <nsis@ietf.org>,
        Marcus Brunner <brunner@ccrle.nec.de>
Subject: RE: Definition of QI was: Re: [NSIS] WG requirements draft
Date: Wed, 27 Feb 2002 11:54:53 +0100
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 <nsis.ietf.org>
X-BeenThere: nsis@ietf.org

Hi Alban, Roland, Rudiger and All,

I see that there are differences in interpretation of the model
as soon as one starts thinking of scenarios other than centralized
resource management, which is what I tried to bring up on the list. 
And hope this shows my point that there is a problem with the [NSIS]
WG draft model once one is thinking of applying it to typical scenarios.
Personally I think that in centralized resource management scenarios
the [NSIS] WG draft model fits really well and I certainly am not
against centralised resource management scenarios. I just believe 
that it is not a feasible solution in particular scenarios such 
as e.g. access networks with high transmission costs.
Further, the real problem is that in the [NSIS] WG draft the 
requirements are dependent on this model and its entities, i.e.
QoS Initiator and QoS Controller. I believe this is not right. I 
would rather prefer to define the requirements based on typical 
scenarios and without relating them to a model nor to a resource
management scheme.

I liked Danny's proposal:
"
- Another possibility is to try to identify the basic scenarios, to
recognise that there are possibly different Qos interfaces (with
different requirements). For example, i clearly see a difference between
access QoS and core QoS (interface host - edge and edge -core). In the
core, we could, as you suggest, identify two approaches (centralised
/distributed) and try to see how then can interwork."

And I definitely agree with Georgios.

Regards,
Vlora


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



From daemon@optimus.ietf.org  Wed Feb 27 07:30: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 HAA19011
	for <nsis-archive@odin.ietf.org>; Wed, 27 Feb 2002 07:30:35 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id HAA16001
	for nsis-archive@odin.ietf.org; Wed, 27 Feb 2002 07:30:37 -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 HAA15396;
	Wed, 27 Feb 2002 07:25: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 HAA15365
	for <nsis@optimus.ietf.org>; Wed, 27 Feb 2002 07:25:52 -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 HAA18406;
	Wed, 27 Feb 2002 07:25:49 -0500 (EST)
Message-Id: <200202271225.HAA18406@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: Wed, 27 Feb 2002 07:25:48 -0500
Subject: [NSIS] I-D ACTION:draft-hancock-nsis-framework-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 <nsis.ietf.org>
X-BeenThere: nsis@ietf.org

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: Towards a Framework for QoS Signaling in the Internet
	Author(s)	: B. Hancock et al.
	Filename	: draft-hancock-nsis-framework-00.txt
	Pages		: 74
	Date		: 26-Feb-02
	
This Internet Draft presents a framework for further development of 
QoS signaling in the Internet. We give a basic model for the 
entities involved in QoS signaling, which is intended to be 
applicable to a very wide range of networking environments, while 
still retaining the flexibility to allow lightweight implementations 
in particular environments and incremental deployment in the 
Internet as a whole.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-hancock-nsis-framework-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-hancock-nsis-framework-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-hancock-nsis-framework-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:	<20020226130948.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-hancock-nsis-framework-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-hancock-nsis-framework-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20020226130948.I-D@ietf.org>

--OtherAccess--

--NextPart--



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



From daemon@optimus.ietf.org  Wed Feb 27 07:47: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 HAA19683
	for <nsis-archive@odin.ietf.org>; Wed, 27 Feb 2002 07:47:25 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id HAA17365
	for nsis-archive@odin.ietf.org; Wed, 27 Feb 2002 07:47:28 -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 HAA16265;
	Wed, 27 Feb 2002 07:31: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 HAA16218
	for <nsis@optimus.ietf.org>; Wed, 27 Feb 2002 07:31:43 -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 HAA19159
	for <nsis@ietf.org>; Wed, 27 Feb 2002 07:31:39 -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 g1RCV7B12707;
	Wed, 27 Feb 2002 13:31:07 +0100 (MET)
Subject: Re: [NSIS] WG requirements draft
To: "Lars.Westberg" <Lars.Westberg@era.ericsson.se>
Cc: "Vlora Rexhepi (ELN)" <Vlora.Rexhepi@eln.ericsson.se>, nsis@ietf.org
X-Mailer: Lotus Notes Release 5.0.5  September 22, 2000
Message-ID: <OF55F5690E.0EA0604A-ONC1256B6D.0029C9B8@net.alcatel.be>
Date: Wed, 27 Feb 2002 13:31:03 +0100
X-MIMETrack: Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at
 02/27/2002 13:31:07
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 <nsis.ietf.org>
X-BeenThere: nsis@ietf.org

Hi Lasse,

I think there can hardly be any objection to list as many scenarios as we
can come up with and investigate what requirements derive from those.
Please also note that we propose to reuse as much as possible the access
QoS technologies in order to avoid duplication of functionality.

Regards,
Sven.





"Lars.Westberg" <Lars.Westberg@era.ericsson.se> on 26/02/2002 17:18:30
                                                              
                                                              
                                                              
  To:          Sven VAN DEN BOSCH/BE/ALCATEL@ALCATEL          
                                                              
  cc:          "Vlora Rexhepi (ELN)"                          
               <Vlora.Rexhepi@eln.ericsson.se>, nsis@ietf.org 
                                                              
                                                              
                                                              
  Subject      Re: [NSIS] WG requirements draft               
  :                                                           
                                                              





Hi, Sven
We have different needs for different application scenarios. In a backbone
network a centralized solution is a very good
idea, especially when we have a possibility for a certain degree of
overprovisioning.
However, I think the archtecture has to cope with all different scenarios
and
therefore has to flexible enough
without limiting the needs for different applications.

I would propose the we have two different scenarios explicitly in the
requirements draft:
One for a Bandwidth Broker case and one for a typical RSVP scenario.

Regards Lasse
sven.van_den_bosch@alcatel.be wrote:

> Hi Vlora,
>
> The idea is to have preprovisioned bandwidth pipes under the control of a
> local entity (NMS or router) that talks to the QC. The pipes implement a
> certain QoS (edge-to-edge delay, jitter, ...). The QC then only has very
> simple AC to do when a request arrives (check whether it fits in the
pipe).
> This makes sense for a number of reasons:
> - A number of services will require similar QoS
> - If each flow is treated independently, the QoS may change with new
> incoming requests
> - The provisioning action is a local matter: it may be distributed or
> centralised.
>
> Regards,
> Sven.
>
> "Vlora Rexhepi (ELN)" <Vlora.Rexhepi@eln.ericsson.se> on 26/02/2002
> 11:19:09
>
>
>
>   To:          Sven VAN DEN BOSCH/BE/ALCATEL@ALCATEL
>
>   cc:
>
>
>
>   Subject      RE: [NSIS] WG requirements draft
>   :
>
>
> Hi Sven,
>
> |Allow me to jump into this discussion. I believe that the QI,
> |QC controller
> |model at least has the merit of clearly identifying the
> |interfaces that we
> |are deriving requirements for. When applied to various use
> |cases, it allows
> |to discover functionality that is common between different
> |entities in the
> |different use cases. In this way, we are looking for common
> |functionality
> |which will lead to the core nsis requirements.
> As I said the scenarios/use cases described in the draft are
> not the typical ones and while trying to apply the model to a
> typical scenario it was not as clear and straightforward to do
> so. Furthermore it turned out to be quite complex.
>
> |I am a bit surprised to see the discussion emphasize on centralised or
> |distributed resource management. While both obviously should
> |be allowed,
> |resource management is clearly a local (intra-domain) matter
> |and as such it
> |should probably be decoupled from the end-to-end issues. For
> |this reason,
> |we have introduced a two-level approach with preprovisioned bandwidth
> |pipes, allowing simple admission control and both distributed and
> |centralised resource management.
> This is because the model is according to my opinion clearly in favor
> of the centalised approach.
> What do you exactly mean by preprovisioned bandwidth pipes?
> Where are they going to be applied to?
>
> Regards,
> Vlora
>
> _______________________________________________
> 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 Feb 27 07:55: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 HAA19905
	for <nsis-archive@odin.ietf.org>; Wed, 27 Feb 2002 07:55:24 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id HAA17669
	for nsis-archive@odin.ietf.org; Wed, 27 Feb 2002 07:55: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 HAA17408;
	Wed, 27 Feb 2002 07:48: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 HAA17377
	for <nsis@optimus.ietf.org>; Wed, 27 Feb 2002 07:48: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 HAA19710
	for <nsis@ietf.org>; Wed, 27 Feb 2002 07:48:01 -0500 (EST)
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.1.0/Switch-2.1.0) with ESMTP id g1RCmAZ26757
	for <nsis@ietf.org>; Wed, 27 Feb 2002 14:48:10 +0200 (EET)
Received: from esebh001.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T595478a29aac158f22077@esvir02nok.ntc.nokia.com>;
 Wed, 27 Feb 2002 14:48:01 +0200
Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779);
	 Wed, 27 Feb 2002 14:48:00 +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"
Date: Wed, 27 Feb 2002 14:48:00 +0200
Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD38D46@esebe004.NOE.Nokia.com>
Thread-Topic: Modularity and grouping QoS requirements
Thread-Index: AcG/g980EnbaON24SfmFBW0u/9+FkwABnVNg
To: <Georgios.Karagiannis@eln.ericsson.se>, <brunner@ccrle.nec.de>
Cc: <nsis@ietf.org>
X-OriginalArrivalTime: 27 Feb 2002 12:48:00.0518 (UTC) FILETIME=[FD114A60:01C1BF8C]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id HAA17378
Subject: [NSIS] RE: Modularity and grouping QoS requirements
Sender: nsis-admin@ietf.org
Errors-To: nsis-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Next Steps in Signaling <nsis.ietf.org>
X-BeenThere: nsis@ietf.org
Content-Transfer-Encoding: 8bit

Hi Georgios,

> The problem I have with the NSIS WG requirements draft is 
> that these sequence of  doing things is very much opposite to the 
> sequence mentioned above. In the NSIS WG requirements draft the 
> following sequence of actions is followed:

Unfortunately, I am under server deadline pressures this week,
so I have not given the requirements document an indepth reading
which it deserves.

My high level comment should be that any model in the requirements
should be for illustrative purposes, not to imply any requirements.
Additionallly, the model should should functional blocks, not
how these functions are actually implemented.

Finally, I would suggest that everyone try to comment directly on 
the draft - add text, delete text, etc. rather then having 
gerneralized concerns.

John

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



From daemon@optimus.ietf.org  Wed Feb 27 09:05: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 JAA23023
	for <nsis-archive@odin.ietf.org>; Wed, 27 Feb 2002 09:05:24 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id JAA21453
	for nsis-archive@odin.ietf.org; Wed, 27 Feb 2002 09:05:28 -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 IAA20509;
	Wed, 27 Feb 2002 08:51: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 IAA20477
	for <nsis@optimus.ietf.org>; Wed, 27 Feb 2002 08:51:25 -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 IAA22193
	for <nsis@ietf.org>; Wed, 27 Feb 2002 08:51:20 -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 g1RDpnI41749;
	Wed, 27 Feb 2002 14:51:49 +0100 (CET)
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 C6AEDC040; Wed, 27 Feb 2002 14:50:44 +0100 (CET)
Date: Wed, 27 Feb 2002 15:03:35 +0100
From: Marcus Brunner <brunner@ccrle.nec.de>
Reply-To: brunner@ccrle.nec.de
To: "Georgios Karagiannis (ELN)" <Georgios.Karagiannis@eln.ericsson.se>,
        "'john.loughney@nokia.com'" <john.loughney@nokia.com>
Cc: nsis@ietf.org
Message-ID: <21367655.1014822215@[192.168.102.79]>
In-Reply-To: <E244E44D6AB85E40AEEF7EAABE3545FA8234EB@enleent104.nl.eu.ericsson.se>
References:  <E244E44D6AB85E40AEEF7EAABE3545FA8234EB@enleent104.nl.eu.ericsso
 n.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
Subject: [NSIS] Re: Modularity and grouping QoS requirements
Sender: nsis-admin@ietf.org
Errors-To: nsis-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Next Steps in Signaling <nsis.ietf.org>
X-BeenThere: nsis@ietf.org
Content-Transfer-Encoding: 7bit

Georgios,

I am open to the consensus of the WG. Just some remarks inline.

--On Wednesday, February 27, 2002 11:37 AM +0100 "Georgios Karagiannis 
(ELN)" <Georgios.Karagiannis@eln.ericsson.se> wrote:

> Dear John and Marcus
>
> One of the outcomes of the NSIS meeting in Salt Lake City was
> to start working on defining QoS requirements based on scenario cases.
>
> Furthermore, we all agreed that modularity is very important;
> During that meeting many people agreed that after the QoS requirements
> are defined, then they will be grouped according to network
> interfaces (e.g., UNI (access), NNI (backbone));

Here you have at least 4 types (UNI with home network, UNI with foreign 
network, NNI within same administrative domain, NNI across admin domains.

>
> A reasonable way of doing the above, is in my opinion the following:
> * First define the scenario cases;
Agreed

> * Second using these scenario cases, define which QoS requirements will
> have     to be satisfied on each network interface, and on each network
> node type, e.g.,    host, access router, interior router, border router,
> edge router, proxy, bandwidth broker, ...

We can still do it my concern is that we have then with N scenarios (N 
currently 5 to be more) and M interfaces (M as mentioned above =4) and L 
node types (L=7 in your proposal)

This implies NxMxL entities we have to define requirements for. And this I 
am definitly not willing to do.

> Third the outcome of this
> separation of QoS requirements it will result in    an efficient grouping
> of the QoS requirements.

We can discuss the grouping (I was just to lazy to change it so far)

> After the QOS requirements grouping is done, then we could define a QoS
> model. This QoS model could have entities such as a QoS initiator and a
> QoS controller.

Yes, that is what the framework document does.

>
> The problem I have with the NSIS WG requirements draft is that these
> sequence of doing things is very much opposite to the sequence mentioned
> above. In the NSIS WG requirements draft the following sequence of
> actions is followed:

> First a QoS model and its QoS model entities are
> defined. At this stage, these    QoS model entities, e.g., QoS initiator
> and QoS controller, are not representing     network entities.

This is the second step in the draft and it is ment to reduce the node 
types.

I understand that some people have problems to see the value of it, others 
very much appreciated the more abstract way of thinking. I would say it is 
50:50 so far.

And some even think we should get more abstract

>  * Second, the QoS requirements are grouped according to these QoS  model
> entities     and not grouped according to any network interface or any
> network node type!

No they are grouped into topics like security, flow definition, 
architectural, etc. The grouping actually as nothing to do with the model

>*Third, the QoS model entites are assigned to
> specific network node types. In my opinion    this  step is difficult to
> be accomplished and for some scenarios is impossible to be done.

You might be right, but we have done it so far. Currently I do not see it 
as too difficult, but I might be wrong.

Marcus
>
> Best regards,
> Georgios
>
>
>
>
>
>



--------------------------------------
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 Feb 27 09:13: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 JAA23307
	for <nsis-archive@odin.ietf.org>; Wed, 27 Feb 2002 09:13:03 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id JAA21677
	for nsis-archive@odin.ietf.org; Wed, 27 Feb 2002 09:13: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 JAA21378;
	Wed, 27 Feb 2002 09:03:56 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA21342
	for <nsis@optimus.ietf.org>; Wed, 27 Feb 2002 09:03:54 -0500 (EST)
Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22916
	for <nsis@ietf.org>; Wed, 27 Feb 2002 09:03:48 -0500 (EST)
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 g1RE3oZc017322
	for <nsis@ietf.org>; Wed, 27 Feb 2002 15:03:50 +0100 (MET)
Received: FROM esealnt746.al.sw.ericsson.se BY esealnt461 ; Wed Feb 27 14:09:33 2002 +0100
Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <F4HC9NZJ>; Wed, 27 Feb 2002 14:09:34 +0100
Message-ID: <E244E44D6AB85E40AEEF7EAABE3545FA8234F4@enleent104.nl.eu.ericsson.se>
From: "Georgios Karagiannis (ELN)" <Georgios.Karagiannis@eln.ericsson.se>
To: "'john.loughney@nokia.com'" <john.loughney@nokia.com>,
        brunner@ccrle.nec.de
Cc: nsis@ietf.org
Date: Wed, 27 Feb 2002 14:09:32 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [NSIS] RE: Modularity and grouping QoS requirements
Sender: nsis-admin@ietf.org
Errors-To: nsis-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Next Steps in Signaling <nsis.ietf.org>
X-BeenThere: nsis@ietf.org

Hi John

Thank you for your reply!

[JL] >> Finally, I would suggest that everyone try to 
[JL] >>  comment directly on the draft - add text, delete 
[JL] >> text, etc. rather then having 
[JL]>> gerneralized concerns.

I think that we first have to find out if a consensus
within the NSIS working group can be found on the method
of creating and separating (grouping) the QoS requirements.
The draft "draft-partain-nsis-requirements-00.txt" is 
using a method to create, separate/group the QoS requirements 
that is in line with what has been agreed during the 
NSIS WG meeting in Salt Lake City.
The NSIS WG draft apparently does not.

Best regards,
Georgios

-----Original Message-----
From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]
Sent: woensdag 27 februari 2002 13:48
To: Georgios.Karagiannis@eln.ericsson.se; brunner@ccrle.nec.de
Cc: nsis@ietf.org
Subject: RE: Modularity and grouping QoS requirements

Hi Georgios,

> The problem I have with the NSIS WG requirements draft is 
> that these sequence of  doing things is very much opposite to the 
> sequence mentioned above. In the NSIS WG requirements draft the 
> following sequence of actions is followed:

Unfortunately, I am under server deadline pressures this week,
so I have not given the requirements document an indepth reading
which it deserves.

My high level comment should be that any model in the requirements
should be for illustrative purposes, not to imply any requirements.
Additionallly, the model should should functional blocks, not
how these functions are actually implemented.

Finally, I would suggest that everyone try to comment directly on 
the draft - add text, delete text, etc. rather then having 
gerneralized concerns.

John

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



From daemon@optimus.ietf.org  Wed Feb 27 10:11: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 KAA26421
	for <nsis-archive@odin.ietf.org>; Wed, 27 Feb 2002 10:11:24 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id KAA25284
	for nsis-archive@odin.ietf.org; Wed, 27 Feb 2002 10:11: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 JAA23977;
	Wed, 27 Feb 2002 09:50: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 JAA23942
	for <nsis@optimus.ietf.org>; Wed, 27 Feb 2002 09:50:26 -0500 (EST)
Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25229
	for <nsis@ietf.org>; Wed, 27 Feb 2002 09:50:21 -0500 (EST)
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 g1REoNZc019230
	for <nsis@ietf.org>; Wed, 27 Feb 2002 15:50:23 +0100 (MET)
Received: FROM esealnt746.al.sw.ericsson.se BY esealnt461 ; Wed Feb 27 14:55:40 2002 +0100
Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <F4HC93GA>; Wed, 27 Feb 2002 14:54:52 +0100
Message-ID: <E244E44D6AB85E40AEEF7EAABE3545FA8234F6@enleent104.nl.eu.ericsson.se>
From: "Georgios Karagiannis (ELN)" <Georgios.Karagiannis@eln.ericsson.se>
To: "'nsis@ietf.org'" <nsis@ietf.org>
Date: Wed, 27 Feb 2002 14:54:50 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [NSIS] FW: Modularity and grouping QoS requirements
Sender: nsis-admin@ietf.org
Errors-To: nsis-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Next Steps in Signaling <nsis.ietf.org>
X-BeenThere: nsis@ietf.org

Sorry if you have received this e-mail twice!


-----Original Message-----
From: Georgios Karagiannis (ELN) 
Sent: woensdag 27 februari 2002 14:10
To: 'john.loughney@nokia.com'; brunner@ccrle.nec.de
Cc: nsis@ietf.org
Subject: RE: Modularity and grouping QoS requirements


Hi John

Thank you for your reply!

[JL] >> Finally, I would suggest that everyone try to 
[JL] >>  comment directly on the draft - add text, delete 
[JL] >> text, etc. rather then having 
[JL]>> gerneralized concerns.

I think that we first have to find out if a consensus
within the NSIS working group can be found on the method
of creating and separating (grouping) the QoS requirements.
The draft "draft-partain-nsis-requirements-00.txt" is 
using a method to create, separate/group the QoS requirements 
that is in line with what has been agreed during the 
NSIS WG meeting in Salt Lake City.
The NSIS WG draft apparently does not.

Best regards,
Georgios

-----Original Message-----
From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]
Sent: woensdag 27 februari 2002 13:48
To: Georgios.Karagiannis@eln.ericsson.se; brunner@ccrle.nec.de
Cc: nsis@ietf.org
Subject: RE: Modularity and grouping QoS requirements

Hi Georgios,

> The problem I have with the NSIS WG requirements draft is 
> that these sequence of  doing things is very much opposite to the 
> sequence mentioned above. In the NSIS WG requirements draft the 
> following sequence of actions is followed:

Unfortunately, I am under server deadline pressures this week,
so I have not given the requirements document an indepth reading
which it deserves.

My high level comment should be that any model in the requirements
should be for illustrative purposes, not to imply any requirements.
Additionallly, the model should should functional blocks, not
how these functions are actually implemented.

Finally, I would suggest that everyone try to comment directly on 
the draft - add text, delete text, etc. rather then having 
gerneralized concerns.

John

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



From daemon@optimus.ietf.org  Wed Feb 27 10:49: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 KAA28514
	for <nsis-archive@odin.ietf.org>; Wed, 27 Feb 2002 10:49:30 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id KAA27070
	for nsis-archive@odin.ietf.org; Wed, 27 Feb 2002 10:49: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 KAA26935;
	Wed, 27 Feb 2002 10:44: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 KAA26904
	for <nsis@optimus.ietf.org>; Wed, 27 Feb 2002 10:44:12 -0500 (EST)
Received: from penguin-ext.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 KAA28183
	for <nsis@ietf.org>; Wed, 27 Feb 2002 10:44:07 -0500 (EST)
Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61])
	by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g1RFiAB13093
	for <nsis@ietf.org>; Wed, 27 Feb 2002 16:44:10 +0100 (MET)
Received: FROM esealnt747.al.sw.ericsson.se BY esealnt461 ; Wed Feb 27 15:50:17 2002 +0100
Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <F4H17HJ3>; Wed, 27 Feb 2002 15:50:13 +0100
Message-ID: <E244E44D6AB85E40AEEF7EAABE3545FAF78460@enleent104.nl.eu.ericsson.se>
From: "Vlora Rexhepi (ELN)" <Vlora.Rexhepi@eln.ericsson.se>
To: "'brunner@ccrle.nec.de'" <brunner@ccrle.nec.de>,
        "Georgios Karagiannis (ELN)" <Georgios.Karagiannis@eln.ericsson.se>,
        "'john.loughney@nokia.com'" <john.loughney@nokia.com>
Cc: nsis@ietf.org
Subject: RE: [NSIS] Re: Modularity and grouping QoS requirements
Date: Wed, 27 Feb 2002 15:50:13 +0100
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 <nsis.ietf.org>
X-BeenThere: nsis@ietf.org

Hi Marcus,

|I am open to the consensus of the WG. Just some remarks inline.
Great.

|> One of the outcomes of the NSIS meeting in Salt Lake City was
|> to start working on defining QoS requirements based on 
|scenario cases.
|>
|> Furthermore, we all agreed that modularity is very important;
|> During that meeting many people agreed that after the QoS 
|requirements
|> are defined, then they will be grouped according to network
|> interfaces (e.g., UNI (access), NNI (backbone));
|
|Here you have at least 4 types (UNI with home network, UNI 
|with foreign 
|network, NNI within same administrative domain, NNI across 
|admin domains.

In draft-partain-nsis-requirements-00.txt there are three types
of interfaces identified:
- interior <-> interior interface
- border node <-> border node interface
- host <-> border node interface
Please see the draft for detailed info.


|> A reasonable way of doing the above, is in my opinion the following:
|> * First define the scenario cases;
|Agreed
Great. 


|> * Second using these scenario cases, define which QoS 
|requirements will
|> have     to be satisfied on each network interface, and on 
|each network
|> node type, e.g.,    host, access router, interior router, 
|border router,
|> edge router, proxy, bandwidth broker, ...
|
|We can still do it my concern is that we have then with N scenarios (N 
|currently 5 to be more) and M interfaces (M as mentioned above 
|=4) and L 
|node types (L=7 in your proposal)
|
|This implies NxMxL entities we have to define requirements 
|for. And this I 
|am definitly not willing to do.
Understandable. No one is suggesting to have more entities than
the number of typical network nodes known in the Internet
community. 
What, Georgios is suggesting is that the [NSIS] WG derives requirements
from the scenarios and group them into particular interfaces between 
different nodes they apply to.  This is already done in
draft-partain-nsis-requirements-00.txt. 
Based on this, the QoS model entities would be defined later. 


|> Third the outcome of this
|> separation of QoS requirements it will result in    an 
|efficient grouping
|> of the QoS requirements.
|
|We can discuss the grouping (I was just to lazy to change it so far)
I already mentioned above one possible way to do it :-). 


|> After the QOS requirements grouping is done, then we could 
|define a QoS
|> model. This QoS model could have entities such as a QoS 
|initiator and a
|> QoS controller.
|
|Yes, that is what the framework document does.
Exactly. The framework should be a result of scenarios and the 
requirements derived from them. As it is now in the [NSIS] WG 
draft the things are done in a different order. And as we could 
see it the "problem discussion model" has a problem when one wants
to apply it in other scenarios rather than the ones described in 
the [NSIS] WG draft.


|> The problem I have with the NSIS WG requirements draft is that these
|> sequence of doing things is very much opposite to the 
|sequence mentioned
|> above. In the NSIS WG requirements draft the following sequence of
|> actions is followed:
|
|> First a QoS model and its QoS model entities are
|> defined. At this stage, these    QoS model entities, e.g., 
|QoS initiator
|> and QoS controller, are not representing network entities.
|
|This is the second step in the draft and it is ment to reduce the node 
|types.
Yes, but it does also impact the QoS requirements. 


|I understand that some people have problems to see the value 
|of it, others 
|very much appreciated the more abstract way of thinking. I 
|would say it is 
|50:50 so far.
|
|And some even think we should get more abstract
|
|>  * Second, the QoS requirements are grouped according to 
|these QoS  model
|> entities     and not grouped according to any network 
|interface or any
|> network node type!
|
|No they are grouped into topics like security, flow definition, 
|architectural, etc. The grouping actually as nothing to do 
|with the model
Right. But, I think the grouping should be done based on the 
agreement in the meeting at Salt Lake City.  

|>*Third, the QoS model entites are assigned to
|> specific network node types. In my opinion    this  step is 
|difficult to
|> be accomplished and for some scenarios is impossible to be done.
|
|You might be right, but we have done it so far. Currently I do 
|not see it 
|as too difficult, but I might be wrong.
We already heard from Danny that in their scenarios it was not 
an "easy exercise"...
So, could someone (other than the authors) please try to relate 
one of the Scenarios from draft-partain-nsis-requirements-00.txt
with "Problem Discussion Model" from the [NSIS] WG draft such that
we can close the discussion on the generality of the model? That 
would be appreciated very much.

Regards,
Vlora  




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



From daemon@optimus.ietf.org  Wed Feb 27 12:09: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 MAA03637
	for <nsis-archive@odin.ietf.org>; Wed, 27 Feb 2002 12:09:09 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id MAA03582
	for nsis-archive@odin.ietf.org; Wed, 27 Feb 2002 12:09: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 LAA01494;
	Wed, 27 Feb 2002 11:53: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 LAA01413
	for <nsis@optimus.ietf.org>; Wed, 27 Feb 2002 11:53:20 -0500 (EST)
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 LAA02360
	for <nsis@ietf.org>; Wed, 27 Feb 2002 11:53:11 -0500 (EST)
Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19)
	id <1S9WN4SD>; Wed, 27 Feb 2002 16:52:40 -0000
Message-ID: <76C92FBBFB58D411AE760090271ED4181EA17D@rsys002a.roke.co.uk>
From: "Hancock, Robert" <robert.hancock@roke.co.uk>
To: NSIS Mailing List <nsis@ietf.org>
Date: Wed, 27 Feb 2002 16:52:39 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/mixed;
	boundary="------------InterScan_NT_MIME_Boundary"
Subject: [NSIS] requirements issues relating to the QI (was: RE: Definition of QI
 (was: something else))
Sender: nsis-admin@ietf.org
Errors-To: nsis-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Next Steps in Signaling <nsis.ietf.org>
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"

Hi Alban, Roland, Rudiger, Vlora, Marcus, NSIS,

I'd like to provide an updated concept for the QI/QC definition to clear this fog. I've yet to see any specific argument that the terminology is not capable of describing the scenarios (in particular, I like Alban's use case analysis), but since the point of the terminology is to provide a consistent language for the scenarios, maybe we can pin it down a bit more.

Once this pinning is done, I'd like to raise some requirements questions (which is what we are actually supposed to be talking about).

The current definitions are:

"QoS Initiator: this is responsible for generating the QSCs for
   traffic flow(s) based on user or application requirements and
   signaling them to the network as well as invoking local QoS
   provisioning mechanisms.  This can be located in the end system, but
   may reside elsewhere in network."

"QoS Controller: this is responsible for interpreting the signaling
   carrying the user QoS parameters, optionally inserting/modifying the
   parameters according to local network QoS management policy, and
   invoking local QoS provisioning mechanisms."

I can't see any ambiguity in how flexibly the QI could be located. In the QC case, the definition leaves it open, and there is discussion is at the start of section 4.2. We could add to the definition:

"The QC could control just the QoS provisioning mechanisms at a single router, in which case it could be an entity located within that router; or it could be remote from that router; and in that remote case it could be controlling the QoS provisioning within a number of routers."

The second question is what entities talk to each other. It has been my assumption that the general model is
QI <--> QC <--> QC <--> QC <- ... -> QC
covering the complete path. Fig. 2 should imply this, although maybe we tried to show something too complex there and so left out the basic case. In any case, the QC can send QoS messages to the 'next hop' QC. So the simplest RSVP case would be to have just a QC at the interior and far end nodes. But this leads to...

***A real requirements/terminology question***
One reason to separate out the QI and QC cases for the requirements discussion was that we felt that a QI had all sorts of important upper layer interactions which were out of the scope of NSIS, in particular that it was the only place where application layer requests were interpreted, it was the entity that had to be authenticated (e.g. because it represented the entity that was going to be authorised and charged). On the other hand, a QC did not have these interactions, and the way it processed NSIS signals (and passed them to other QCs) was entirely defined as part of NSIS. 
In other words, the distinction between QI and QC is part of the definition of NSIS scope.

Question: is this distinction between QI and QC useful? Should the QC behaviour be fully defined by NSIS? (I think this question would start to become critical if people start looking at MIBs and so on.) Basically, we took the view that if there is complex behaviour, it is abstracted out of the QC into a separate application - a good example is where a node initiates an aggregate (cf. Rudi's email), in which case I would say that we don't want to define an NSIS-standard aggregation policy etc. and instead a local management application triggers a QI for the aggregate. It's also in section 5.5.1 of our framework draft - but note, that's a solution case built out of the terminology (if people want to make aggregation policy and so on part of NSIS, we would call this - in the requirements - a standard QoS controller).

There are several other requirements issues related to QIs. In particular:

*** A real requirements question ***
Given the above definition of a QI, can there be more than one QI for a single flow? In other words, can there be several places within a network where someone decides to request QoS based on upper layer considerations (including AAA aspects)? If there is more than one QI, do they need to talk to each other directly? (Our assumption: there is only a single QI for a given flow, which is a restriction, but the scenarios don't currently motivate anything more complex, so far as I can tell).

*** Another requirements question ***
Since we have requirements for both sender and receiver initiated QoS, the implication is that (for a unicast flow), someone has to decide to be the QI (this is different from RSVP, where there is no choice in the matter). At the moment, the requirements basically assume (I think in line with the scenarios) that this is decided by the application layer and the QI just 'gets called'. Again, this is a 'scope of NSIS' question - should NSIS actually include some sort of QI election capability? (Note that by having the term QI rather than just talking about 'hosts' we are able to pose this question quite concretely - at least I find it helpful, even if nobody else does...)

And, 
*** Yet another requirements question ***
Is there any scenario showing a need for any special application-related functionality at the 'far end' (this would be the QR of Roland's email). At the moment, we don't see what this would be - all the NSIS functionality seems to be covered by the QC definition, and at most there is some sort of upwards trigger into the application to say 'flow is setup' (this is also in our framework draft, section 4.1). But, is there a requirement to have some more complex behaviour here, and if so how much of this behaviour is in the scope of NSIS? (And if so, we can define a QR term to be a label for it.)

At the moment, I think there are 'obvious' answers to these questions, but since there is a concern about the capability of the terminology to express them, I thought I'd make them explicit. I'd also be interested in pointers to where other requirements drafts have considered these questions (or made it clear what assumptions were being made).

Yours,

Robert H.


> -----Original Message-----
> From: Vlora Rexhepi (ELN) [mailto:Vlora.Rexhepi@eln.ericsson.se]
> Sent: 27 February 2002 10:55
> To: 'Alban.Couturier@alcatel.fr'; Roland Bless
> Cc: Vlora Rexhepi (ELN); NSIS Mailing List; Marcus Brunner
> Subject: RE: Definition of QI was: Re: [NSIS] WG requirements draft
> 
> 
> Hi Alban, Roland, Rudiger and All,
> 
> I see that there are differences in interpretation of the model
> as soon as one starts thinking of scenarios other than centralized
> resource management, which is what I tried to bring up on the list. 
> And hope this shows my point that there is a problem with the [NSIS]
> WG draft model once one is thinking of applying it to typical 
> scenarios.
> Personally I think that in centralized resource management scenarios
> the [NSIS] WG draft model fits really well and I certainly am not
> against centralised resource management scenarios. I just believe 
> that it is not a feasible solution in particular scenarios such 
> as e.g. access networks with high transmission costs.
> Further, the real problem is that in the [NSIS] WG draft the 
> requirements are dependent on this model and its entities, i.e.
> QoS Initiator and QoS Controller. I believe this is not right. I 
> would rather prefer to define the requirements based on typical 
> scenarios and without relating them to a model nor to a resource
> management scheme.
> 
> I liked Danny's proposal:
> "
> - Another possibility is to try to identify the basic scenarios, to
> recognise that there are possibly different Qos interfaces (with
> different requirements). For example, i clearly see a 
> difference between
> access QoS and core QoS (interface host - edge and edge -core). In the
> core, we could, as you suggest, identify two approaches (centralised
> /distributed) and try to see how then can interwork."
> 
> And I definitely agree with Georgios.
> 
> Regards,
> Vlora
> 
> 
> _______________________________________________
> 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 Feb 27 12:09: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 MAA03687
	for <nsis-archive@odin.ietf.org>; Wed, 27 Feb 2002 12:09:39 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id MAA03645
	for nsis-archive@odin.ietf.org; Wed, 27 Feb 2002 12:09: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 MAA03194;
	Wed, 27 Feb 2002 12:04: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 MAA03162
	for <nsis@optimus.ietf.org>; Wed, 27 Feb 2002 12:04:12 -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 MAA03313
	for <nsis@ietf.org>; Wed, 27 Feb 2002 12:04:07 -0500 (EST)
From: danny.goderis@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 g1RH3SO03630;
	Wed, 27 Feb 2002 18:03:28 +0100 (MET)
Received: from alcatel.be ([138.203.136.5])
          by bemail04.net.alcatel.be (Lotus Domino Release 5.0.8)
          with ESMTP id 2002022718032620:1515 ;
          Wed, 27 Feb 2002 18:03:26 +0100 
Message-ID: <3C7D115A.E82FF423@alcatel.be>
Date: Wed, 27 Feb 2002 18:03:22 +0100
Organization: Alcatel CRC Antwerp
X-Mailer: Mozilla 4.72 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: "Vlora Rexhepi (ELN)" <Vlora.Rexhepi@eln.ericsson.se>
Cc: "'brunner@ccrle.nec.de'" <brunner@ccrle.nec.de>,
        "Georgios Karagiannis (ELN)" <Georgios.Karagiannis@eln.ericsson.se>,
        "'john.loughney@nokia.com'" <john.loughney@nokia.com>, nsis@ietf.org
Subject: Re: [NSIS] Re: Modularity and grouping QoS requirements
References: <OFC14BC2A2.11AF00D9-ONC1256B6D.0056942E@alcatel.be>
X-MIMETrack: Itemize by SMTP Server on BEMAIL04/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at
 02/27/2002 18:03:26,
	Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at
 02/27/2002 18:03:27,
	Serialize complete at 02/27/2002 18:03:27
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
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 <nsis.ietf.org>
X-BeenThere: nsis@ietf.org
Content-Transfer-Encoding: 7bit

Hi Vlora, Marcus,

I support the approach as seems to be agreed in the mail discussions:
- define and study scenario cases 
- identify the particular QoS interfaces
- group requirements according to the identified interfaces
- define functional entities (like QI, QC, etc) and elaborate the QoS
model. 

I am also in favour the idea of identifying interfaces and grouping
requirements because it seems to me that important requirements, such as
e.g. mobility, only apply to UNI and not to NNI. I also think that there
are not infinite number of (particular) interfaces and that, basically
one has:
- UNI: host-network edge (border)
- NNI: which may have particular requirments and features whether it
concerns access-core | core-core
- interior 

Regarding the 3-interface proposal of Vlora: although i perfectly
understand the meaning, i rather prefer the taxonomy of Marcus because
this leaves open whether the interface is on the data-path (in-band &
out-of-band mechanisms are in scope I guess)

BTW, If we follow this approach, it seems to me that a kind of "QoS
mapping" (QM) functional entity seems also necessary for enbabling
end-to-end QoS. The QM entity could e.g. have some
aggregating/de-aggregating functionality (at e.g. network edge), resolve
the mapping of QoS parameters from UNI to NNI, etc. 

In the scenario cases of draft-buchli-nsis-req-00.txt (PSTN trunking and
UMTS access over a single IP core), we needed such a kind of QM
function. We put this QM function as a part of the QI (to line up with
draft-brunner-...), but I now think it is a dedicated function. Anyhow,
that's why i said previously that "it was not so simple" and that the
definition of functional entities is to be elaborated further.

Regards,
Danny


"Vlora Rexhepi (ELN)" wrote:
> 
> Hi Marcus,
> 
> |I am open to the consensus of the WG. Just some remarks inline.
> Great.
> 
> |> One of the outcomes of the NSIS meeting in Salt Lake City was
> |> to start working on defining QoS requirements based on
> |scenario cases.
> |>
> |> Furthermore, we all agreed that modularity is very important;
> |> During that meeting many people agreed that after the QoS
> |requirements
> |> are defined, then they will be grouped according to network
> |> interfaces (e.g., UNI (access), NNI (backbone));
> |
> |Here you have at least 4 types (UNI with home network, UNI
> |with foreign
> |network, NNI within same administrative domain, NNI across
> |admin domains.
> 
> In draft-partain-nsis-requirements-00.txt there are three types
> of interfaces identified:
> - interior <-> interior interface
> - border node <-> border node interface
> - host <-> border node interface
> Please see the draft for detailed info.
> 
> |> A reasonable way of doing the above, is in my opinion the following:
> |> * First define the scenario cases;
> |Agreed
> Great.
> 
> |> * Second using these scenario cases, define which QoS
> |requirements will
> |> have     to be satisfied on each network interface, and on
> |each network
> |> node type, e.g.,    host, access router, interior router,
> |border router,
> |> edge router, proxy, bandwidth broker, ...
> |
> |We can still do it my concern is that we have then with N scenarios (N
> |currently 5 to be more) and M interfaces (M as mentioned above
> |=4) and L
> |node types (L=7 in your proposal)
> |
> |This implies NxMxL entities we have to define requirements
> |for. And this I
> |am definitly not willing to do.
> Understandable. No one is suggesting to have more entities than
> the number of typical network nodes known in the Internet
> community.
> What, Georgios is suggesting is that the [NSIS] WG derives requirements
> from the scenarios and group them into particular interfaces between
> different nodes they apply to.  This is already done in
> draft-partain-nsis-requirements-00.txt.
> Based on this, the QoS model entities would be defined later.
> 
> |> Third the outcome of this
> |> separation of QoS requirements it will result in    an
> |efficient grouping
> |> of the QoS requirements.
> |
> |We can discuss the grouping (I was just to lazy to change it so far)
> I already mentioned above one possible way to do it :-).
> 
> |> After the QOS requirements grouping is done, then we could
> |define a QoS
> |> model. This QoS model could have entities such as a QoS
> |initiator and a
> |> QoS controller.
> |
> |Yes, that is what the framework document does.
> Exactly. The framework should be a result of scenarios and the
> requirements derived from them. As it is now in the [NSIS] WG
> draft the things are done in a different order. And as we could
> see it the "problem discussion model" has a problem when one wants
> to apply it in other scenarios rather than the ones described in
> the [NSIS] WG draft.
> 
> |> The problem I have with the NSIS WG requirements draft is that these
> |> sequence of doing things is very much opposite to the
> |sequence mentioned
> |> above. In the NSIS WG requirements draft the following sequence of
> |> actions is followed:
> |
> |> First a QoS model and its QoS model entities are
> |> defined. At this stage, these    QoS model entities, e.g.,
> |QoS initiator
> |> and QoS controller, are not representing network entities.
> |
> |This is the second step in the draft and it is ment to reduce the node
> |types.
> Yes, but it does also impact the QoS requirements.
> 
> |I understand that some people have problems to see the value
> |of it, others
> |very much appreciated the more abstract way of thinking. I
> |would say it is
> |50:50 so far.
> |
> |And some even think we should get more abstract
> |
> |>  * Second, the QoS requirements are grouped according to
> |these QoS  model
> |> entities     and not grouped according to any network
> |interface or any
> |> network node type!
> |
> |No they are grouped into topics like security, flow definition,
> |architectural, etc. The grouping actually as nothing to do
> |with the model
> Right. But, I think the grouping should be done based on the
> agreement in the meeting at Salt Lake City.
> 
> |>*Third, the QoS model entites are assigned to
> |> specific network node types. In my opinion    this  step is
> |difficult to
> |> be accomplished and for some scenarios is impossible to be done.
> |
> |You might be right, but we have done it so far. Currently I do
> |not see it
> |as too difficult, but I might be wrong.
> We already heard from Danny that in their scenarios it was not
> an "easy exercise"...
> So, could someone (other than the authors) please try to relate
> one of the Scenarios from draft-partain-nsis-requirements-00.txt
> with "Problem Discussion Model" from the [NSIS] WG draft such that
> we can close the discussion on the generality of the model? That
> would be appreciated very much.
> 
> Regards,
> Vlora
> 
> _______________________________________________
> 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 Feb 27 12:42: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 MAA05678
	for <nsis-archive@odin.ietf.org>; Wed, 27 Feb 2002 12:42:50 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id MAA05734
	for nsis-archive@odin.ietf.org; Wed, 27 Feb 2002 12:42: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 MAA04580;
	Wed, 27 Feb 2002 12:30: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 MAA04540
	for <nsis@optimus.ietf.org>; Wed, 27 Feb 2002 12:29:58 -0500 (EST)
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 MAA04871
	for <nsis@ietf.org>; Wed, 27 Feb 2002 12:29:52 -0500 (EST)
Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19)
	id <1S9WN4T5>; Wed, 27 Feb 2002 17:27:23 -0000
Message-ID: <76C92FBBFB58D411AE760090271ED4181EA17F@rsys002a.roke.co.uk>
From: "Hancock, Robert" <robert.hancock@roke.co.uk>
To: "'Brian Williams'" <brian.williams@ericsson.com.au>
Cc: "'Jukka Manner'" <jmanner@cs.Helsinki.FI>,
        Gabor Fodor
	 <Gabor.Fodor@era-t.ericsson.se>, nsis@ietf.org
Subject: another requirements question (was: RE: [NSIS] A few comments to 
	draft-fodor-reqts-cellular-netwks-00 .txt)
Date: Wed, 27 Feb 2002 17:27:22 -0000
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 <nsis.ietf.org>
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"

Hi Brian,

[others: the requirements question is at the end if you want to skip to it.]

It seems we all probably agree that the scenario where the node responsible for requesting QoS (which might commonly be the application node) is not attached to the wireless link is an important one, in which case it's clear (to me) that wireless related parameters are relevant to NSIS QoS classes. We should probably have a scenario like this in the requirements draft. [I might have described this as 'QoS initiator not directly attached to the wireless link' but some people might have regarded this phrasing as provocative...]

But the more general question of NSIS-L2 interactions (also stimulated by your point about 'other wireless networks') raises a requirements/scope issue about NSIS:
Given a pair of independently implemented NSIS signalling entities (either side of the wireless link), it should be the case that NSIS protocol(s) will define how the QoS negotiation proceeds. But is this enough to make the lower layer negotiation proceed in a sensible way, or could there be reservation collisions (or neither side bothers at all...)?

In our framework document (draft-hancock-whatsit), we basically assumed that this would be defined somehow specifically to the lower layers in use (maybe in some kind of NSIS-over-foo document), but I'm not certain this is good enough. For example, if we believe that NSIS might get used in UMTS packet domain [warning: abandon all hope of following the rest of this sentence those not familiar with UMTS], then either the GGSN or UE or both or neither could do PDP context activation when they saw an NSIS message at the upper layers - the same ambiguity arises currently when they see an RSVP RESV (and I don't believe there is a standardised way for things to be done in that case either).

*** Requirements question ***
Does the NSIS signalling need to be able to convey/negotiate information about which end of a link is going to be responsible for initiating lower layer bearer setup?

I don't think the answer is obviously yes or no here. There's a lot of different wireless link types out there.

Yours,

Robert H.

> -----Original Message-----
> From: Brian Williams [mailto:brian.williams@ericsson.com.au]
> Sent: 21 February 2002 07:41
> To: Hancock, Robert
> Cc: 'Jukka Manner'; Gabor Fodor; nsis@ietf.org
> Subject: RE: [NSIS] A few comments to
> draft-fodor-reqts-cellular-netwks-00 .txt
> 
> 
> Hi Robert.
> I would definitely agree that there are many different scenarios, and
> one with the application node sitting behind a wireless router/gateway
> is the most obvious situation which introduces signalling 
> requirements.
> 
> I would also add though that even within one physical node, 
> there can be
> scenarios that effectively become an equivalent to this 
> application node
> behind a gateway router. For example, on my PC I have run multiple
> virtual machines. The communication between these virtual machines
> occurs over a virtual ethernet, but it is all within one node.
> 
> There can also be cases where a node works towards one 
> logical interface
> internally, which is then adapted one or more times until it 
> reaches the
> real interface such as with levels of tunneling.
> 
> And finally, we should not rule out that other wireless networks could
> control the link layer signalling from the network instead of from the
> terminal.  
> 
> In all of these cases, there are reasons to have additional 
> information
> important for the wireless operation available from the application
> level QoS interface, and possibly carried in the IP level QoS 
> protocol.
> I do agree though that dependent on the exact scenario, this 
> information
> may not need to be transmitted over the wireless link.
> /brian
> 
> On Thu, 2002-02-21 at 01:18, Hancock, Robert wrote:
> > Hi Jukka, Gabor,
> > 
> > On the UDP-lite issue, my understanding is that UDP-lite 
> only tells you that some of the packet is checksum protected 
> and some isn't. The sophistication of signalling required for 
> full UEP (e.g. to support AMR codec operation) is much 
> greater. I guess if you had UEP QoS signalling you wouldn't 
> need UDP-lite, you could just switch the checksum off 
> altogether (at least for IPv4).
> > 
> > I was more concerned about whether the scenario as 
> presented really justifies the need for wireless-related 
> parameters at all. It seems to concentrate on the case where 
> the wireless link is the last hop, directly connected to the 
> node where the end application is running. In that case, it's 
> clear that good quality IP QoS (fine grained, efficient, 
> local etc.) is important, more so than in fixed networks. I 
> think it's less clear that the IP layer signalling needs to 
> have link (or 'link-ish') parameters in it. After all, the 
> link layers already have their own signalling, and can tune 
> the link to the required QoS even more tightly.
> > 
> > It's true that if applications use the IntServ classes to 
> request QoS from their network stack, these classes need to 
> be extended with wireless hints. But that's a comment on the 
> deficiency of basing inter-layer interfaces on protocols, not 
> a requirement to extend the protocol itself.
> > 
> > One reason we thought to be very careful here was that if 
> you have wireless-related parameters being exchanged at both 
> IP (RSVP) and link layers, it might be hard for independent 
> implementors of each end to work out which layer to use for 
> negotiation and in which order, and which layer was in 
> charge. This was raised after SLC as an open issue on the 
> list, but the argument wasn't really clear (partly my fault).
> > 
> > I think there _is_ actually a good case for having wireless 
> related parameters, but that the justifying scenario is where 
> the wireless link is 'interior' (e.g. 3G mobile acting as a 
> wireless router for a local subnet), but in that case you 
> might need take into account other considerations as well. 
> Then you need to get the wireless-related information from 
> the application into the router. But in either case, we need 
> to have a clear model of how the link layer negotiation 
> interacts with the IP layer negotiation.
> > 
> > Or did I miss something?
> > 
> > Robert H.
> > 
> > > -----Original Message-----
> > > From: Jukka Manner [mailto:jmanner@cs.Helsinki.FI]
> > > Sent: 20 February 2002 12:00
> > > To: Gabor Fodor
> > > Cc: nsis@ietf.org
> > > Subject: [NSIS] A few comments to
> > > draft-fodor-reqts-cellular-netwks-00.txt
> > > 
> > > 
> > > 
> > > 	Hi,
> > > 
> > > 	As I read the draft, two requirements left me wondering:
> > > 
> > > 	R2: how does this match with the UDP-lite proposal, 
> > > where the UDP
> > > header indicates the need for UEP. Thus, does the QoS primitives /
> > > signalling need to indicate the need for UEP? If the 
> > > transport protocol
> > > does not support UEP, you won't get the packet sent 
> to/accepted at the
> > > receiver. Also, you don't even need any QoS mechanism to 
> use UDP-lite.
> > > 
> > > 	R3: you seem to assume that doing bi-directional resource 
> > > allocations also implies that routing is symmetric for uplink and 
> > > downlink. Since IP routing is asymmetric, I doubt that 
> bi-directional 
> > > reservations are possible with a single mechanism, but rather 
> > > imply that 
> > > there must be separate signalling for the two directions. 
> > > Thus, eg. RSVP 
> > > makes it possible to have asymmetric reservations on the two 
> > > directions.
> > > 
> > > 	Cheers,
> > > 
> > > 	Jukka
> > > 
> > > 
> > > _______________________________________________
> > > nsis mailing list
> > > nsis@ietf.org
> > > https://www1.ietf.org/mailman/listinfo/nsis
> > > 
> > 
> > ----
> > 
> 
> > 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
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 Feb 27 13:33: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 NAA08878
	for <nsis-archive@odin.ietf.org>; Wed, 27 Feb 2002 13:33:21 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id NAA17545
	for nsis-archive@odin.ietf.org; Wed, 27 Feb 2002 13:33: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 NAA16765;
	Wed, 27 Feb 2002 13:25:46 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA16733
	for <nsis@optimus.ietf.org>; Wed, 27 Feb 2002 13:25:43 -0500 (EST)
Received: from cmail.packetcom.com ([63.108.173.139])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08410
	for <nsis@ietf.org>; Wed, 27 Feb 2002 13:25:40 -0500 (EST)
Received: from caspiannetworks.com ([192.168.5.104])
	by cmail.packetcom.com (Mirapoint)
	with ESMTP id ABU21629 (AUTH tso@caspiannetworks.com);
	Wed, 27 Feb 2002 10:25:11 -0800 (PST)
Message-ID: <3C7D1DBA.4FAA5061@caspiannetworks.com>
Date: Wed, 27 Feb 2002 09:56:10 -0800
From: Tricci So <tso@caspiannetworks.com>
Organization: Caspian Networks
X-Mailer: Mozilla 4.78 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: nsis@ietf.org
Content-Type: multipart/mixed;
 boundary="------------2CED341D4B857CFC3B6F848A"
Subject: [NSIS] [Fwd: I-D ACTION:draft-so-nsis-scope-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 <nsis.ietf.org>
X-BeenThere: nsis@ietf.org

This is a multi-part message in MIME format.
--------------2CED341D4B857CFC3B6F848A
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit



--------------2CED341D4B857CFC3B6F848A
Content-Type: message/rfc822
Content-Disposition: inline

Return-Path: <ietf-123-owner@loki.ietf.org>
Received: from cmail.packetcom.com (cmail.packetcom.com [63.108.173.139])
	by dhl.caspiannetworks.com (Mirapoint)
	with ESMTP id AAW21626;
	Wed, 27 Feb 2002 09:26:56 -0800 (PST)
Received: from loki.ietf.org (loki.ietf.org [132.151.1.177])
	by cmail.packetcom.com (Mirapoint)
	with ESMTP id ABU21230;
	Wed, 27 Feb 2002 09:26:54 -0800 (PST)
Received: (from adm@localhost)
	by loki.ietf.org (8.9.1b+Sun/8.9.1) id MAA07037
	for ietf-123-outbound.02@ietf.org; Wed, 27 Feb 2002 12:25:00 -0500 (EST)
Received: from ietf.org (odin.ietf.org [10.27.2.28])
	by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id HAA04218
	for <all-ietf@loki.ietf.org>; Wed, 27 Feb 2002 07:25:03 -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 HAA18219
	for <all-ietf@ietf.org>; Wed, 27 Feb 2002 07:25:01 -0500 (EST)
Message-Id: <200202271225.HAA18219@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-so-nsis-scope-00.txt
Date: Wed, 27 Feb 2002 07:25:01 -0500
Sender: nsyracus@cnri.reston.va.us

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: NSIS Scope Recommendations
	Author(s)	: T. So
	Filename	: draft-so-nsis-scope-00.txt
	Pages		: 6
	Date		: 26-Feb-02
	
The intent of this draft is to recommend the scope of the work for 
the NSIS working group so that the team can focus on the key work 
signaling issues that need to be resolved and to develop the 
solutions promptly.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-so-nsis-scope-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-so-nsis-scope-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-so-nsis-scope-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:	<20020226130752.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-so-nsis-scope-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-so-nsis-scope-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20020226130752.I-D@ietf.org>

--OtherAccess--

--NextPart--



--------------2CED341D4B857CFC3B6F848A--


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



From daemon@optimus.ietf.org  Wed Feb 27 14:12: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 OAA11225
	for <nsis-archive@odin.ietf.org>; Wed, 27 Feb 2002 14:12:40 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id OAA22013
	for nsis-archive@odin.ietf.org; Wed, 27 Feb 2002 14:12: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 NAA20477;
	Wed, 27 Feb 2002 13:59: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 NAA20446
	for <nsis@optimus.ietf.org>; Wed, 27 Feb 2002 13:59:27 -0500 (EST)
Received: from eccles.ee.ryerson.ca (eccles.ee.ryerson.ca [141.117.1.2])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10289
	for <nsis@ietf.org>; Wed, 27 Feb 2002 13:59:22 -0500 (EST)
Received: from ee.ryerson.ca ([172.16.30.72])
	by eccles.ee.ryerson.ca (8.11.1/8.11.1) with ESMTP id g1RIxCI19180;
	Wed, 27 Feb 2002 13:59:12 -0500
Message-ID: <3C7D2C48.3040806@ee.ryerson.ca>
Date: Wed, 27 Feb 2002 13:58:16 -0500
From: Muhammad Jaseemuddin <jaseem@ee.ryerson.ca>
Organization: Ryerson University
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: "Geib, Ruediger" <Ruediger.Geib@t-systems.com>
CC: bless@tm.uka.de, nsis@ietf.org
Subject: Re: Definition of QI was: Re: [NSIS] WG requirements draft
References: <DFD875E85664D3118FA6080006277DE70362C8D2@U8PN2>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
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 <nsis.ietf.org>
X-BeenThere: nsis@ietf.org
Content-Transfer-Encoding: 8bit

Ruediger:

 I agree that the requirement should also consider the case where QC may 
act as QI. I am not sure if I understood the example you gave. But, I 
know for example in GPRS there is a network initiated PDP context 
activation procedure, where the GGSN (QC) requests MS (QI) to initiate 
the PDP context activation procedure. This is a genuine case because a 
QC (e.g. GGSN or a an edge router) may receive packets for delivery to 
the hosts (normally a QI) for which QoS needs to be setup along the 
path. In this case essentially QI remains the actual initiaor, but it 
initiates at the request of QC.

Cheers,
- Muhammad Jaseemuddin

Geib, Ruediger wrote:

>Roland,
>
>I agree with your view completely. Let's go on with the requirements and stop a discussion of architectures. That's part of the solutions.
>
>A requirement may be that in some cases a "QC" may act as "QI": An edge to edge QoS tunnel set up (maybe even spanning several domains). This would allow the tunnel entry point QC to do per flow edge to edge admission control once the QI requests service for the tunnel destination domain. To me this is the simplest and therefore most desireable way of per service reservation aggregation.
>
>Regards, Rüdiger 
>
>>Hi all,
>>
>>I think we can solve this issue by not complicating the role model. 
>>It is also mentioned in section 4.1 of the nsis-req draft that QoS
>>Controllers interact with other QoS Controllers (as I understood). 
>>Therefore, there is signaling between different QCs. I don't think 
>>that we should complicate the model by explicitly defining every QC 
>>also as QI, although the QC initiates a further signaling transaction 
>>with another QC. I also don't think that the terms QC and QI are not 
>>generic enough to also cover a distributed approach. For a more 
>>complete model my suggestion (we add also a QoS Responder):
>>
>>          Domain A             Domain B
>>        .......................      .......................
>>        .                     .      .                     .
>>QI <--> . QC <==> ... <==> QC . <==> . QC <==> ... <==> QC . <--> QR
>>        .......................      .......................
>>     a)       b)                  c)                           a)
>>
>>1.) The QI can be an end system or signaling proxy acting on
>>    behalf of an end system. 
>>2.) There can be several QoS Controllers involved in signaling. 
>>    Some of the QCs may be located within one administrative
>>    domain (allowing the distributed case where each router 
>>    or each edge router or several BBs are involved within
>>    such a domain) whereas others are located within different
>>    domains. 
>>3.) Finally, we should add the QoS Responder (QR) in order to have 
>>    a "symmetric" model where the corresponding end system
>>    can be also involved in signaling (e.g., to let a mobile terminal 
>>    decide about the priority of requests due to scarce bandwidth).
>>    As with the QI the QR could be also a signaling proxy. 
>>    Alternatively, the QC can act as proxy.
>>
>>I think that this model covers all the different signaling cases:
>>a) end <-> edge/network
>>b) network internal, also covering edge to edge (intra-domain)
>>c) network <-> network (inter-domain)
>>and considering the whole signaling scenario by combining
>>the parts
>>d) end to end (QI <--> QR indirectly via a)b)c), not at 
>>application level)
>>
>>Won't this fit most use cases?
>>
>
>_______________________________________________
>nsis mailing list
>nsis@ietf.org
>https://www1.ietf.org/mailman/listinfo/nsis
>

-- 
==================================================
Muhammad Jaseemuddin
Associate Professor
Departement of Electrical and Computer Engineering
Ryerson University
350 Victoria Street
Toronto, ON M5B 2K3
Tel: +1 416 979-5000x6073
Fax: +1 416 979-5280
Email: jaseem@ee.ryerson.ca
Web: http://www.ee.ryerson.ca/~jaseem
==================================================




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



From daemon@optimus.ietf.org  Wed Feb 27 14:49: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 OAA13640
	for <nsis-archive@odin.ietf.org>; Wed, 27 Feb 2002 14:49:56 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id OAA24426
	for nsis-archive@odin.ietf.org; Wed, 27 Feb 2002 14:49:59 -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 OAA24142;
	Wed, 27 Feb 2002 14:45:08 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA24099
	for <nsis@optimus.ietf.org>; Wed, 27 Feb 2002 14:45: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 OAA13415
	for <nsis@ietf.org>; Wed, 27 Feb 2002 14:45:01 -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.1.0/Switch-2.1.0) with ESMTP id g1RJjBZ15345
	for <nsis@ietf.org>; Wed, 27 Feb 2002 21:45:11 +0200 (EET)
Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T5955f66de2ac158f23078@esvir03nok.nokia.com>;
 Wed, 27 Feb 2002 21:45:02 +0200
Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779);
	 Wed, 27 Feb 2002 21:45:02 +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"
Date: Wed, 27 Feb 2002 21:45:02 +0200
Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFA22AF9@esebe004.NOE.Nokia.com>
Thread-Topic: Modularity and grouping QoS requirements
Thread-Index: AcG/niiILMLtaLuzQa2j4OVM8pAS4gAJ3pYw
To: <Georgios.Karagiannis@eln.ericsson.se>, <brunner@ccrle.nec.de>
Cc: <nsis@ietf.org>
X-OriginalArrivalTime: 27 Feb 2002 19:45:02.0508 (UTC) FILETIME=[3F55F6C0:01C1BFC7]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id OAA24100
Subject: [NSIS] RE: Modularity and grouping QoS requirements
Sender: nsis-admin@ietf.org
Errors-To: nsis-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Next Steps in Signaling <nsis.ietf.org>
X-BeenThere: nsis@ietf.org
Content-Transfer-Encoding: 8bit

Hi Georgios,

A point of procedure:

[clip]
> that is in line with what has been agreed during the 
> NSIS WG meeting in Salt Lake City.

Agreements cannot be made during the meetings, but only
on the mailing list.  However, we need to get consensus
on this issue.

John

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



From daemon@ns.ietf.org  Thu Feb 28 05:26: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 FAA16279
	for <nsis-archive@odin.ietf.org>; Thu, 28 Feb 2002 05:26:59 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id FAA19062
	for nsis-archive@odin.ietf.org; Thu, 28 Feb 2002 05:27:03 -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 FAA18908;
	Thu, 28 Feb 2002 05:22:26 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA18877
	for <nsis@ns.ietf.org>; Thu, 28 Feb 2002 05:22:24 -0500 (EST)
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 FAA16182
	for <nsis@ietf.org>; Thu, 28 Feb 2002 05:22:19 -0500 (EST)
Received: from KOM.tu-darmstadt.de by mailserver.KOM.e-technik.tu-darmstadt.de (8.7.5/8.7.5) with ESMTP id LAA04156 for <nsis@ietf.org>; Thu, 28 Feb 2002 11:21:46 +0100 (MET)
From: Martin Karsten <Martin.Karsten@KOM.tu-darmstadt.de>
Received: from KOM.tu-darmstadt.de by KOM.tu-darmstadt.de (8.11.2/8.7.5) id g1SALGg32328 for nsis@ietf.org; Thu, 28 Feb 2002 11:21:16 +0100
Message-Id: <200202281021.g1SALGg32328@KOM.tu-darmstadt.de>
To: nsis@ietf.org
Date: Thu, 28 Feb 2002 11:21:16 +0100 (CET)
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
Subject: [NSIS] suggestions for draft-ietf-nsis-req-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 <nsis.ietf.org>
X-BeenThere: nsis@ietf.org
Content-Transfer-Encoding: 7bit

I have a few suggestions for draft-ietf-nsis-req-00.txt. Apologies, if these
have already been adressed.

Section 2, Terminology

'Aggregate'
- add an explicit statement that packets belonging to an aggregate must be
  commonly and uniquely identifiable, because otherwise aggregation doesn't
  make much sense.

'Edge-to-edge QoS'
- change "administrative domain" to "QoS domain" (as it is defined earlier)
- remove second half of the sentence (beginning with "that connects"),
  because it unnecessarily restricts the scope of the definition

'QoS Service Class'
- The term seems to be overloaded. Its definition is similar to the usual
  definition of "service class" as describing a particular set of QoS
  parameters. However, the usage of QSC e.g. in 'Mapping' and 'QoS
  Initiator' does not seem to make sense (a service class is not initiated). 
  It might be more suitable to additionally use a term like "service
  invocation" to describe actual instances of QoS requests.

Section 5.2.5, IP Fragmentation

I would suggest to remove this requirement as it increases the complexity
without much benefit. There are good reasons, why IP fragmentation is
usually not supported by QoS signalling. Further, IPv6 does not support IP
fragmentation at forwarding nodes.

Greetings,
Martin

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



From daemon@ns.ietf.org  Thu Feb 28 05:56: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 FAA16627
	for <nsis-archive@odin.ietf.org>; Thu, 28 Feb 2002 05:56:14 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id FAA20426
	for nsis-archive@odin.ietf.org; Thu, 28 Feb 2002 05:56: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 FAA20072;
	Thu, 28 Feb 2002 05:43: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 FAA19989
	for <nsis@ns.ietf.org>; Thu, 28 Feb 2002 05:43:47 -0500 (EST)
Received: from mail1.telekom.de ([62.225.183.235])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16512
	for <nsis@ietf.org>; Thu, 28 Feb 2002 05:43:38 -0500 (EST)
Received: from g8pbq.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Thu, 28 Feb 2002 11:41:34 +0100
Received: by G8PBQ.blf01.telekom.de with Internet Mail Service (5.5.2653.19)
	id <FYZSZLWJ>; Thu, 28 Feb 2002 11:43:04 +0100
Message-Id: <DFD875E85664D3118FA6080006277DE70362C8DA@U8PN2>
From: "Geib, Ruediger" <Ruediger.Geib@t-systems.com>
To: jaseem@ee.ryerson.ca, "Geib, Ruediger" <Ruediger.Geib@t-systems.com>
Cc: bless@tm.uka.de, nsis@ietf.org
Subject: RE: Definition of QI was: Re: [NSIS] WG requirements draft
Date: Thu, 28 Feb 2002 09:29:31 +0100
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 FAA19990
Sender: nsis-admin@ietf.org
Errors-To: nsis-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Next Steps in Signaling <nsis.ietf.org>
X-BeenThere: nsis@ietf.org
Content-Transfer-Encoding: 8bit

Muhammed,

I'm a core network engineer and I prefer fat pipes instead of per flow reservations. I also prefer "provisioning" to "on the fly" aggregation as the mode of "fat pipe" set up. That's the background. What I'd like to get may look like that:

a) Initial situation:

      Edge QC--QC--QC--QC--QC--Edge QC

Note that also the "internal" QC's could be edge QC's. It's not relevant.

b) QoS Tunnel set up (being triggered by management, not by terminal per flow signalling)

      Edge QC==="Fat Pipe"===Edge QC

All the involved QC's should use standard NSIS signaling to set up the "fat pipe". During the fat pipe set up, the systems marked as "edge QCs" act as QI. Note that than one requirement for NSIS would be to support reservations to IP address + prefix range instead of IP address only. (Maybe even several IP adress + prefix ranges!)

c) Now per flow reservations may turn up, being handled by direct QC edge to edge signaling:

Host QI--Edge QC==signals directly to==Edge QC--Host QI

This saves per flow signalling and state from all the intermediate QCs (and hence improves scaleability). Admission Control decisions are speeded up too. It's of course not a general solution, and some "per flow" signaling will have to be done by the intermediate QCs for destinations without pre-installed "fat pipes".
If you'd like to look at it that way, it's a requirement for NSIS signalling to support some kind of traffic engineering. Support here is limited to control "fat pipe" set up, maintenance and release.

Another requirement in the above case is that the tunnel entry point must recognize a per flow reservation fitting to a specific tunnel.

Regards, Rüdiger
   

> -----Original Message-----
> From: Muhammad Jaseemuddin [mailto:jaseem@ee.ryerson.ca]
> Sent: Wednesday, February 27, 2002 7:58 PM
> To: Geib, Ruediger
> Cc: bless@tm.uka.de; nsis@ietf.org
> Subject: Re: Definition of QI was: Re: [NSIS] WG requirements draft
> 
> 
> Ruediger:
> 
>  I agree that the requirement should also consider the case 
> where QC may 
> act as QI. I am not sure if I understood the example you gave. But, I 
> know for example in GPRS there is a network initiated PDP context 
> activation procedure, where the GGSN (QC) requests MS (QI) to 
> initiate 
> the PDP context activation procedure. This is a genuine case 
> because a 
> QC (e.g. GGSN or a an edge router) may receive packets for 
> delivery to 
> the hosts (normally a QI) for which QoS needs to be setup along the 
> path. In this case essentially QI remains the actual initiaor, but it 
> initiates at the request of QC.
> 
> Cheers,
> - Muhammad Jaseemuddin
> 
> Geib, Ruediger wrote:
> 
> >Roland,
> >
> >I agree with your view completely. Let's go on with the 
> requirements and stop a discussion of architectures. That's 
> part of the solutions.
> >
> >A requirement may be that in some cases a "QC" may act as 
> "QI": An edge to edge QoS tunnel set up (maybe even spanning 
> several domains). This would allow the tunnel entry point QC 
> to do per flow edge to edge admission control once the QI 
> requests service for the tunnel destination domain. To me 
> this is the simplest and therefore most desireable way of per 
> service reservation aggregation.
> >
> >Regards, Rüdiger 
> >
> >>Hi all,
> >>
> >>I think we can solve this issue by not complicating the role model. 
> >>It is also mentioned in section 4.1 of the nsis-req draft that QoS
> >>Controllers interact with other QoS Controllers (as I understood). 
> >>Therefore, there is signaling between different QCs. I don't think 
> >>that we should complicate the model by explicitly defining every QC 
> >>also as QI, although the QC initiates a further signaling 
> transaction 
> >>with another QC. I also don't think that the terms QC and 
> QI are not 
> >>generic enough to also cover a distributed approach. For a more 
> >>complete model my suggestion (we add also a QoS Responder):
> >>
> >>          Domain A             Domain B
> >>        .......................      .......................
> >>        .                     .      .                     .
> >>QI <--> . QC <==> ... <==> QC . <==> . QC <==> ... <==> QC . <--> QR
> >>        .......................      .......................
> >>     a)       b)                  c)                           a)
> >>
> >>1.) The QI can be an end system or signaling proxy acting on
> >>    behalf of an end system. 
> >>2.) There can be several QoS Controllers involved in signaling. 
> >>    Some of the QCs may be located within one administrative
> >>    domain (allowing the distributed case where each router 
> >>    or each edge router or several BBs are involved within
> >>    such a domain) whereas others are located within different
> >>    domains. 
> >>3.) Finally, we should add the QoS Responder (QR) in order to have 
> >>    a "symmetric" model where the corresponding end system
> >>    can be also involved in signaling (e.g., to let a 
> mobile terminal 
> >>    decide about the priority of requests due to scarce bandwidth).
> >>    As with the QI the QR could be also a signaling proxy. 
> >>    Alternatively, the QC can act as proxy.
> >>
> >>I think that this model covers all the different signaling cases:
> >>a) end <-> edge/network
> >>b) network internal, also covering edge to edge (intra-domain)
> >>c) network <-> network (inter-domain)
> >>and considering the whole signaling scenario by combining
> >>the parts
> >>d) end to end (QI <--> QR indirectly via a)b)c), not at 
> >>application level)
> >>
> >>Won't this fit most use cases?
> >>
> >
> >_______________________________________________
> >nsis mailing list
> >nsis@ietf.org
> >https://www1.ietf.org/mailman/listinfo/nsis
> >
> 
> -- 
> ==================================================
> Muhammad Jaseemuddin
> Associate Professor
> Departement of Electrical and Computer Engineering
> Ryerson University
> 350 Victoria Street
> Toronto, ON M5B 2K3
> Tel: +1 416 979-5000x6073
> Fax: +1 416 979-5280
> Email: jaseem@ee.ryerson.ca
> Web: http://www.ee.ryerson.ca/~jaseem
> ==================================================
> 
> 
> 

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



From daemon@ns.ietf.org  Thu Feb 28 07:13: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 HAA18622
	for <nsis-archive@odin.ietf.org>; Thu, 28 Feb 2002 07:13:56 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id HAA24415
	for nsis-archive@odin.ietf.org; Thu, 28 Feb 2002 07:13:59 -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 HAA24232;
	Thu, 28 Feb 2002 07:09: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 HAA24202
	for <nsis@ns.ietf.org>; Thu, 28 Feb 2002 07:09:42 -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 HAA18450
	for <nsis@ietf.org>; Thu, 28 Feb 2002 07:09:34 -0500 (EST)
From: danny.goderis@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 g1SC8dc29207;
	Thu, 28 Feb 2002 13:08:40 +0100 (MET)
Received: from alcatel.be ([138.203.67.19])
          by bemail04.net.alcatel.be (Lotus Domino Release 5.0.8)
          with ESMTP id 2002022813083726:811 ;
          Thu, 28 Feb 2002 13:08:37 +0100 
Message-ID: <3C7E1DC4.5B653321@alcatel.be>
Date: Thu, 28 Feb 2002 13:08:36 +0100
Organization: Alcatel CRC Antwerp
X-Mailer: Mozilla 4.72 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: David Partain <David.Partain@ericsson.com>,
        "Georgios Karagiannis (ELN)" <Georgios.Karagiannis@eln.ericsson.se>,
        "Greis Marc (NRC/Dallas)" <marc.greis@nokia.com>,
        Ping Pan <pingpan@juniper.net>,
        "Vlora Rexhepi (ELN)" <Vlora.Rexhepi@eln.ericsson.se>
CC: "nsis@ietf.org" <nsis@ietf.org>
X-MIMETrack: Itemize by SMTP Server on BEMAIL04/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at
 02/28/2002 13:08:37,
	Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at
 02/28/2002 13:08:39,
	Serialize complete at 02/28/2002 13:08:39
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: [NSIS] questions on partain draft-partain-...
Sender: nsis-admin@ietf.org
Errors-To: nsis-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Next Steps in Signaling <nsis.ietf.org>
X-BeenThere: nsis@ietf.org
Content-Transfer-Encoding: 7bit

Hi David, Vlora and co-authors,

I have been reading with interest the draft you submitted recently and,
of course, i have quite some questions. 

First, let me start with the figures.
Figure 1: the Joint Point of Reservation (JPR). I find it an interesting
idea and want to have a better understanding. In an UMTS access network,
is this JPR meant to be the SGSN or the GGSN, or could it be both? 

MH --- (UMTS access) --- SGSN ---(UMTS backbone)--- GGSN -- BR (e.g. A
DiffServ edge router). 

If I want to map this figure 2 on figure 3: 
--- is the JPR (fig 2) = BGW (fig 3) (which could be a GGSN) or 
----is the JPR = ER before the backbone (... SGSN).

Returning now to figure 1. I like the figure, but I have two remarks.
First, I think it should better elaborate the access - edge- core
interworking. For example

host ----(access network)---- EN - BN----(interios core)----BN-BN---

EN is edge node, which, in the UMTS case, is the GGSN. In our draft we
gave this box the generic term "access gate" (AG), which can thus be a
GGSN (UMTS), a BAS (xDSL), CMTS (PacketCable) or even a trunking GW in
case of connection with the PSTN.

For me figure 1 (enlarged with the above suggstion) gives a high-level
(but clear) view on the QoS segments in the end-to-end path. However, I
have one important question concerning the applicability of the figure:
a BN is this restricted to a border Router or can it be any box at the
network edge/border. In other words, i should like that out-of-band
mechanisms are not a-priori excluded and i think it should try to aline
with the suggestions for out-of-band approaches in draft-brunner...

So, if i quote the draft, i share your viewpoint on the following:

"  End-to-end QoS management does not necessarily mean that a single
   one-size-fits-all QoS signalling protocol must be applied end-to-end.
   In fact, it is most likely that the end-to-end QoS management
   architecture will consist of many interoperable and concatenated QoS
   management architectures rather than one global end-to-end QoS
   infrastructure."

This is also the viewpoint we expressed in our draft. I also support the
following:

"  Each QoS domain is responsible for taking its own decisions in its
own domain-
   specific ways."

For me this is an important requirement. It means to a certain extend
that QoS provisioning (at the end of the day this is about bandwidth and
buffer resources in the routers) and QoS signaling  (request for
consuming the resources) should be kept separated to the extend
possible. In the extreme case of "over-provisioning" (whatever this
might be), resources are pre-provisioned and signaling is (almost ?)
trivial.

However, If I follow the above arguments, then I must admit I can not
support the following restriction of the QoS signaling/framework

" In all the scenarios ... the data MUST follow the same path as the
signalling messages."

Don't agree with this restriction. 

It should e.g. be possible for a DiffServ network operator to
pre-provision his network for EF traffic and nevertheless participate in
NSIS signaling without the need to upgrade all his routers. So, he may
opt to install (an almost trivial ?) QoS policy server with an NSIS
agent to put himself into the NSIS QoS inter-network. It least, this may
not be excluded at this moment.

One way to make it concrete is e.g. to try to "inter-connect your use
case 3.1/3.2 with our use case UMTS (figure 2, figure 3)

I have also a question on the use case 3.3 PSTN gateways ans IP
backbone. We have the same use case, and so it could be interesting to
compare both and lign-up. I appreciate the analysis (page 8) made on how
the backbone may provision resources (4 possibilities). In our use we
outline (what i think) is a combination of your points 2 and 4 (2= AC
per policy server) 4 (par call AC based on 5-tuple). 

Anyhow, we need some more discussion here, and i also am interested to
see your comments, in particular about the use cases.

Still a lot of questions, but let it keep it here for the moment...

Regards,
Danny

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



From daemon@ns.ietf.org  Thu Feb 28 07:20: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 HAA18891
	for <nsis-archive@odin.ietf.org>; Thu, 28 Feb 2002 07:20:21 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id HAA24631
	for nsis-archive@odin.ietf.org; Thu, 28 Feb 2002 07:20: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 HAA23892;
	Thu, 28 Feb 2002 07:06:59 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA23861
	for <nsis@ns.ietf.org>; Thu, 28 Feb 2002 07:06:57 -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 HAA18019
	for <nsis@ietf.org>; Thu, 28 Feb 2002 07:06:54 -0500 (EST)
Received: from irams1.ira.uka.de ([129.13.10.5])
	by iraun2.uka.de with esmtp (Exim 3.30 #7 (Debian))
	id 16gPKp-0002g4-00; Thu, 28 Feb 2002 13:06:55 +0100
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 16gPKp-0003LI-00; Thu, 28 Feb 2002 13:06:55 +0100
Received: from i72pc127.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 g1SC6sW30600;
	Thu, 28 Feb 2002 13:06:54 +0100
Message-Id: <200202281206.g1SC6sW30600@i72pc127.tm.uka.de>
X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4+dev
To: "Geib, Ruediger" <Ruediger.Geib@t-systems.com>
cc: nsis@ietf.org
Subject: Re: Definition of QI was: Re: [NSIS] WG requirements draft 
In-Reply-To: Message from "Geib, Ruediger" <Ruediger.Geib@t-systems.com> 
   of "Thu, 28 Feb 2002 09:29:31 +0100." <DFD875E85664D3118FA6080006277DE70362C8DA@U8PN2> 
References: <DFD875E85664D3118FA6080006277DE70362C8DA@U8PN2> 
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Date: Thu, 28 Feb 2002 13:06:54 +0100
From: Roland Bless <bless@tm.uka.de>
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 <nsis.ietf.org>
X-BeenThere: nsis@ietf.org
Content-Transfer-Encoding: 8bit

Hi Ruediger,

> b) QoS Tunnel set up (being triggered by management, not by terminal
> per flow signalling)

>      Edge QC==="Fat Pipe"===Edge QC

> All the involved QC's should use standard NSIS signaling to set up the
> "fat pipe". During the fat pipe set up, the systems marked as "edge QCs"
> act as QI. Note that than one requirement for NSIS would be to support
> reservations to IP address + prefix range instead of IP address only.
> (Maybe even several IP adress + prefix ranges!)

I prefer the term reservation aggregate, because "tunnel" is often associated with 
encapsulation of packets in packets. I know that the Q-Bone approach used this term.

> c) Now per flow reservations may turn up, being handled by direct QC edge to edge signaling:
> 
> Host QI--Edge QC==signals directly to==Edge QC--Host QI
> 

> This saves per flow signalling and state from all the intermediate QCs
> (and hence improves scaleability). Admission Control decisions are
> speeded up too. It's of course not a general solution, and some "per
> flow" signaling will have to be done by the intermediate QCs for
> destinations without pre-installed "fat pipes".

I think this is a very good point according to scalability. Hence, in my
view the nsis protocol should allow to set up and manage reservation
aggregates. The DARIS approach is a bit more general, because it also
supports full hierachical aggregation of reservations between arbitrary
domains. Therefore, the "fat pipes" are not restricted to reach from
Edge network to Edge network: every domain can decide by itself to set
up an aggregate to any other domain, and, aggregates can be nested.

Moreover, I designed a signaling protocol that allows more efficient
aggregation management (saving more than one RTT in delay, for instance
in case the aggregate capacity has to be changed).

> If you'd like to look at it that way, it's a requirement for NSIS
> signalling to support some kind of traffic engineering. Support here is
> limited to control "fat pipe" set up, maintenance and release.

Yes, but not limited to pipes reaching from edge to edge network.

> Another requirement in the above case is that the tunnel entry point
> must recognize a per flow reservation fitting to a specific tunnel.

Right. Additionally, it can also decide when to set up a new aggregate.

Regards,
 Roland

> -----Original Message-----
> From: Muhammad Jaseemuddin [mailto:jaseem@ee.ryerson.ca]
> Sent: Wednesday, February 27, 2002 7:58 PM
> To: Geib, Ruediger
> Cc: bless@tm.uka.de; nsis@ietf.org
> Subject: Re: Definition of QI was: Re: [NSIS] WG requirements draft
> 
> 
> Ruediger:
> 
>  I agree that the requirement should also consider the case 
> where QC may 
> act as QI. I am not sure if I understood the example you gave. But, I 
> know for example in GPRS there is a network initiated PDP context 
> activation procedure, where the GGSN (QC) requests MS (QI) to 
> initiate 
> the PDP context activation procedure. This is a genuine case 
> because a 
> QC (e.g. GGSN or a an edge router) may receive packets for 
> delivery to 
> the hosts (normally a QI) for which QoS needs to be setup along the 
> path. In this case essentially QI remains the actual initiaor, but it 
> initiates at the request of QC.
> 
> Cheers,
> - Muhammad Jaseemuddin
> 
> Geib, Ruediger wrote:
> 
> >Roland,
> >
> >I agree with your view completely. Let's go on with the 
> requirements and stop a discussion of architectures. That's 
> part of the solutions.
> >
> >A requirement may be that in some cases a "QC" may act as 
> "QI": An edge to edge QoS tunnel set up (maybe even spanning 
> several domains). This would allow the tunnel entry point QC 
> to do per flow edge to edge admission control once the QI 
> requests service for the tunnel destination domain. To me 
> this is the simplest and therefore most desireable way of per 
> service reservation aggregation.
> >
> >Regards, Rüdiger 
> >
> >>Hi all,
> >>
> >>I think we can solve this issue by not complicating the role model. 
> >>It is also mentioned in section 4.1 of the nsis-req draft that QoS
> >>Controllers interact with other QoS Controllers (as I understood). 
> >>Therefore, there is signaling between different QCs. I don't think 
> >>that we should complicate the model by explicitly defining every QC 
> >>also as QI, although the QC initiates a further signaling 
> transaction 
> >>with another QC. I also don't think that the terms QC and 
> QI are not 
> >>generic enough to also cover a distributed approach. For a more 
> >>complete model my suggestion (we add also a QoS Responder):
> >>
> >>          Domain A             Domain B
> >>        .......................      .......................
> >>        .                     .      .                     .
> >>QI <--> . QC <==> ... <==> QC . <==> . QC <==> ... <==> QC . <--> QR
> >>        .......................      .......................
> >>     a)       b)                  c)                           a)
> >>
> >>1.) The QI can be an end system or signaling proxy acting on
> >>    behalf of an end system. 
> >>2.) There can be several QoS Controllers involved in signaling. 
> >>    Some of the QCs may be located within one administrative
> >>    domain (allowing the distributed case where each router 
> >>    or each edge router or several BBs are involved within
> >>    such a domain) whereas others are located within different
> >>    domains. 
> >>3.) Finally, we should add the QoS Responder (QR) in order to have 
> >>    a "symmetric" model where the corresponding end system
> >>    can be also involved in signaling (e.g., to let a 
> mobile terminal 
> >>    decide about the priority of requests due to scarce bandwidth).
> >>    As with the QI the QR could be also a signaling proxy. 
> >>    Alternatively, the QC can act as proxy.
> >>
> >>I think that this model covers all the different signaling cases:
> >>a) end <-> edge/network
> >>b) network internal, also covering edge to edge (intra-domain)
> >>c) network <-> network (inter-domain)
> >>and considering the whole signaling scenario by combining
> >>the parts
> >>d) end to end (QI <--> QR indirectly via a)b)c), not at 
> >>application level)
> >>
> >>Won't this fit most use cases?
> >>
> >
> >_______________________________________________
> >nsis mailing list
> >nsis@ietf.org
> >https://www1.ietf.org/mailman/listinfo/nsis
> >
> 
> -- 
> ==================================================
> Muhammad Jaseemuddin
> Associate Professor
> Departement of Electrical and Computer Engineering
> Ryerson University
> 350 Victoria Street
> Toronto, ON M5B 2K3
> Tel: +1 416 979-5000x6073
> Fax: +1 416 979-5280
> Email: jaseem@ee.ryerson.ca
> Web: http://www.ee.ryerson.ca/~jaseem
> ==================================================



-- 
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  Thu Feb 28 07:27: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 HAA19134
	for <nsis-archive@odin.ietf.org>; Thu, 28 Feb 2002 07:27:48 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id HAA24951
	for nsis-archive@odin.ietf.org; Thu, 28 Feb 2002 07: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 HAA24847;
	Thu, 28 Feb 2002 07:23: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 HAA24806
	for <nsis@ns.ietf.org>; Thu, 28 Feb 2002 07:23:54 -0500 (EST)
Received: from mail1.telekom.de ([62.225.183.235])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18980
	for <nsis@ietf.org>; Thu, 28 Feb 2002 07:23:50 -0500 (EST)
Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Thu, 28 Feb 2002 13:21:34 +0100
Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19)
	id <F3BA1XX8>; Thu, 28 Feb 2002 13:23:08 +0100
Message-Id: <DFD875E85664D3118FA6080006277DE70362C8DC@U8PN2>
From: "Geib, Ruediger" <Ruediger.Geib@t-systems.com>
To: bless@tm.uka.de
Cc: nsis@ietf.org
Subject: RE: Definition of QI was: Re: [NSIS] WG requirements draft 
Date: Thu, 28 Feb 2002 13:23:04 +0100
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 HAA24807
Sender: nsis-admin@ietf.org
Errors-To: nsis-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Next Steps in Signaling <nsis.ietf.org>
X-BeenThere: nsis@ietf.org
Content-Transfer-Encoding: 8bit

Hi Roland,

I don't know details of the DARIS approach. I agree to all of your statements which may be understood without assuming knowledge of the DARIS approach (i.e. "reservation aggregate" instead of "tunnel", hierachical stacking of reservation aggregates which means nested aggregates).

Regards, Rüdiger

Rolands comments were:
.....
> I prefer the term reservation aggregate, because "tunnel" is 
> often associated with encapsulation of packets in packets.
> I know that the Q-Bone approach used this term.
.....
> I think this is a very good point according to scalability. 
> Hence, in my view the nsis protocol should allow to set up
> and manage reservation aggregates. The DARIS approach is
> a bit more general, because it also supports full
> hierachical aggregation of reservations between arbitrary
> domains. Therefore, the "fat pipes" are not restricted to reach from
> Edge network to Edge network: every domain can decide by itself to set
> up an aggregate to any other domain, and, aggregates can be nested.
..... 
> Moreover, I designed a signaling protocol that allows more efficient
> aggregation management (saving more than one RTT in delay, 
> for instance in case the aggregate capacity has to be changed).
..... 
> Yes, but not limited to pipes reaching from edge to edge network.

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



From daemon@ns.ietf.org  Thu Feb 28 07:43: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 HAA19805
	for <nsis-archive@odin.ietf.org>; Thu, 28 Feb 2002 07:43:03 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id HAA25927
	for nsis-archive@odin.ietf.org; Thu, 28 Feb 2002 07:43:06 -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 HAA25794;
	Thu, 28 Feb 2002 07:39: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 HAA25765
	for <nsis@ns.ietf.org>; Thu, 28 Feb 2002 07:39:01 -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 HAA19631
	for <nsis@ietf.org>; Thu, 28 Feb 2002 07:38:57 -0500 (EST)
Received: from irams1.ira.uka.de ([129.13.10.5])
	by iraun2.uka.de with esmtp (Exim 3.30 #7 (Debian))
	id 16gPpr-0003A0-00; Thu, 28 Feb 2002 13:38:59 +0100
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 16gPpq-00040x-00; Thu, 28 Feb 2002 13:38:58 +0100
Received: from i72pc127.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 g1SCcwW30793;
	Thu, 28 Feb 2002 13:38:58 +0100
Message-Id: <200202281238.g1SCcwW30793@i72pc127.tm.uka.de>
X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4+dev
To: Martin Karsten <Martin.Karsten@KOM.tu-darmstadt.de>
Cc: nsis@ietf.org
Subject: Re: [NSIS] suggestions for draft-ietf-nsis-req-00.txt 
In-Reply-To: Your message of "Thu, 28 Feb 2002 11:21:16 +0100."
             <200202281021.g1SALGg32328@KOM.tu-darmstadt.de> 
References: <200202281021.g1SALGg32328@KOM.tu-darmstadt.de> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 28 Feb 2002 13:38:58 +0100
From: Roland Bless <bless@tm.uka.de>
Sender: nsis-admin@ietf.org
Errors-To: nsis-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Next Steps in Signaling <nsis.ietf.org>
X-BeenThere: nsis@ietf.org

Hi Martin,

> I have a few suggestions for draft-ietf-nsis-req-00.txt. Apologies, if these
> have already been adressed.
> 
> Section 2, Terminology
> 
> 'Aggregate'
> - add an explicit statement that packets belonging to an aggregate must be
>   commonly and uniquely identifiable, because otherwise aggregation doesn't
>   make much sense.

I disagree here, because aggregation is usually performed at service level,
i.e., the service has to have technically the same characteristics/attributes,
e.g., a guaranteed rate. If one considers DiffServ domains as a possible QoS 
implementation architecture, each DiffServ domain may use different PHBs 
(with different codepoints) to provide an equivalent service. Therefore,
packets will usually be different along the path of an aggregate.

> 'Edge-to-edge QoS'
> - change "administrative domain" to "QoS domain" (as it is defined earlier)
> - remove second half of the sentence (beginning with "that connects"),
>   because it unnecessarily restricts the scope of the definition

The most general case should be the one where we have several "QoS
domains" that are grouped together within an Autonomous System. 
I'm a little bit confused about the overloaded term "edge". In one case,
"edge-to-edge" means boundary to boundary within a single domain,
whereas in other cases "edge-to-edge" means edge _network_ to edge
_network_. Shouldn't we be more precise here?

> Section 5.2.5, IP Fragmentation
> 
> I would suggest to remove this requirement as it increases the complexity
> without much benefit. There are good reasons, why IP fragmentation is
> usually not supported by QoS signalling. Further, IPv6 does not support IP
> fragmentation at forwarding nodes.

IPv6 is definitely not a problem in this context, because nsis signaling
will always mean fragmentation from end to end between to adjacent nsis
nodes. Thus, every nsis node will able to fragment its signaling
messages and any router will be able to forward these messages (but it
will not fragment by itself at all). On the other hand, why shouldn't we
allow fragmentation? It will be an implementation decision whether the
nsis protocol should require a reliable transport protocol such as SCTP
or whether it should do all the stuff by itself (IMHO it shouldn't).
Sure, in the latter case an implementation without fragmentation 
will be easier.

Best 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  Thu Feb 28 08:06: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 IAA20749
	for <nsis-archive@odin.ietf.org>; Thu, 28 Feb 2002 08:06:36 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id IAA27299
	for nsis-archive@odin.ietf.org; Thu, 28 Feb 2002 08: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 IAA27027;
	Thu, 28 Feb 2002 08:02:40 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA26998
	for <nsis@ns.ietf.org>; Thu, 28 Feb 2002 08:02:38 -0500 (EST)
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 IAA20632
	for <nsis@ietf.org>; Thu, 28 Feb 2002 08:02:34 -0500 (EST)
Received: from KOM.tu-darmstadt.de by mailserver.KOM.e-technik.tu-darmstadt.de (8.7.5/8.7.5) with ESMTP id OAA15660; Thu, 28 Feb 2002 14:02:06 +0100 (MET)
From: Martin Karsten <Martin.Karsten@KOM.tu-darmstadt.de>
Received: from KOM.tu-darmstadt.de by KOM.tu-darmstadt.de (8.11.2/8.7.5) id g1SD1Z500986; Thu, 28 Feb 2002 14:01:35 +0100
Message-Id: <200202281301.g1SD1Z500986@KOM.tu-darmstadt.de>
Subject: Re: [NSIS] suggestions for draft-ietf-nsis-req-00.txt
In-Reply-To: <200202281238.g1SCcwW30793@i72pc127.tm.uka.de> from Roland Bless
 at "Feb 28, 2002 01:38:58 pm"
To: Roland Bless <bless@tm.uka.de>
Date: Thu, 28 Feb 2002 14:01:35 +0100 (CET)
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 <nsis.ietf.org>
X-BeenThere: nsis@ietf.org
Content-Transfer-Encoding: 7bit

Hi Roland.

> > 'Aggregate'
> > - add an explicit statement that packets belonging to an aggregate must be
> >   commonly and uniquely identifiable, because otherwise aggregation doesn't
> >   make much sense.
> 
> I disagree here, because aggregation is usually performed at service level,
> i.e., the service has to have technically the same characteristics/attributes,
> e.g., a guaranteed rate. If one considers DiffServ domains as a possible QoS 
> implementation architecture, each DiffServ domain may use different PHBs 
> (with different codepoints) to provide an equivalent service. Therefore,
> packets will usually be different along the path of an aggregate.

Correct, but then all packets will all have the same DSCP within a domain,
which essentially is the common and unique identifier I'm referring to.

Let me rephrase:
... packets belonging to an aggregate must be commonly and uniquely
identifiable per QoS domain ...

> > Section 5.2.5, IP Fragmentation
> > 
> > I would suggest to remove this requirement as it increases the complexity
> > without much benefit. There are good reasons, why IP fragmentation is
> > usually not supported by QoS signalling. Further, IPv6 does not support IP
> > fragmentation at forwarding nodes.
> 
> IPv6 is definitely not a problem in this context, because nsis signaling
> will always mean fragmentation from end to end between to adjacent nsis
> nodes. Thus, every nsis node will able to fragment its signaling
> messages and any router will be able to forward these messages (but it
> will not fragment by itself at all). On the other hand, why shouldn't we
> allow fragmentation? It will be an implementation decision whether the
> nsis protocol should require a reliable transport protocol such as SCTP
> or whether it should do all the stuff by itself (IMHO it shouldn't).
> Sure, in the latter case an implementation without fragmentation 
> will be easier.

I was assuming that the requirement in 5.2.5 refers to the data packets
rather than signalling packets. If it only refers to signalling packets,
then of course, forget my comment.

Best,
Martin

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



From daemon@ns.ietf.org  Thu Feb 28 08:11: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 IAA21046
	for <nsis-archive@odin.ietf.org>; Thu, 28 Feb 2002 08:11:33 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id IAA27478
	for nsis-archive@odin.ietf.org; Thu, 28 Feb 2002 08:11:37 -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 HAA26362;
	Thu, 28 Feb 2002 07:59: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 HAA26334
	for <nsis@ns.ietf.org>; Thu, 28 Feb 2002 07:58:59 -0500 (EST)
Received: from iraun1.uka.de (iraun1.uka.de [129.13.10.90])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20537
	for <nsis@ietf.org>; Thu, 28 Feb 2002 07:58:55 -0500 (EST)
Received: from irams1.ira.uka.de ([129.13.10.5])
	by iraun1.uka.de with esmtp (Exim 3.30 #10 (Debian))
	id 16gQ9B-0000Cg-00; Thu, 28 Feb 2002 13:58:57 +0100
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 16gQ9A-0004Sa-00; Thu, 28 Feb 2002 13:58:56 +0100
Received: from i72pc127.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 g1SCwuW30981;
	Thu, 28 Feb 2002 13:58:56 +0100
Message-Id: <200202281258.g1SCwuW30981@i72pc127.tm.uka.de>
X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4+dev
To: "Geib, Ruediger" <Ruediger.Geib@t-systems.com>
cc: nsis@ietf.org
Subject: Re: Definition of QI was: Re: [NSIS] WG requirements draft 
In-Reply-To: Message from "Geib, Ruediger" <Ruediger.Geib@t-systems.com> 
   of "Thu, 28 Feb 2002 13:23:04 +0100." <DFD875E85664D3118FA6080006277DE70362C8DC@U8PN2> 
References: <DFD875E85664D3118FA6080006277DE70362C8DC@U8PN2> 
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Date: Thu, 28 Feb 2002 13:58:56 +0100
From: Roland Bless <bless@tm.uka.de>
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 <nsis.ietf.org>
X-BeenThere: nsis@ietf.org
Content-Transfer-Encoding: 8bit

Hi Ruediger,

> I don't know details of the DARIS approach. I agree to all of your
> statements which may be understood without assuming knowledge of the
> DARIS approach (i.e. "reservation aggregate" instead of "tunnel",
> hierachical stacking of reservation aggregates which means nested
> aggregates).

Yes, that was my intention. It is not required to know details
of the approach now. The basic principle is just to let QCs decide
when to aggregate and where the aggregate should end. It allows
nearly arbitrary nestings of aggregates (in principle, there is
a conflict case, but this case is manageable) and to integrate reservations
into new or existing aggregates as well as to shift them between aggregates.
Finally, the signaling protocol supports some kind of parallelism that
can be used to speed up signaling as mentioned earlier.

Regards,
 Roland

> Rolands comments were:
> .....
> > I prefer the term reservation aggregate, because "tunnel" is 
> > often associated with encapsulation of packets in packets.
> > I know that the Q-Bone approach used this term.
> .....
> > I think this is a very good point according to scalability. 
> > Hence, in my view the nsis protocol should allow to set up
> > and manage reservation aggregates. The DARIS approach is
> > a bit more general, because it also supports full
> > hierachical aggregation of reservations between arbitrary
> > domains. Therefore, the "fat pipes" are not restricted to reach from
> > Edge network to Edge network: every domain can decide by itself to set
> > up an aggregate to any other domain, and, aggregates can be nested.
> ..... 
> > Moreover, I designed a signaling protocol that allows more efficient
> > aggregation management (saving more than one RTT in delay, 
> > for instance in case the aggregate capacity has to be changed).
> ..... 
> > Yes, but not limited to pipes reaching from edge to edge network.
> 
> _______________________________________________
> 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



From daemon@ns.ietf.org  Thu Feb 28 08:18: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 IAA21359
	for <nsis-archive@odin.ietf.org>; Thu, 28 Feb 2002 08:18:03 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id IAA27828
	for nsis-archive@odin.ietf.org; Thu, 28 Feb 2002 08:18: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 IAA27608;
	Thu, 28 Feb 2002 08:13: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 IAA27581
	for <nsis@ns.ietf.org>; Thu, 28 Feb 2002 08:13:41 -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 IAA21122
	for <nsis@ietf.org>; Thu, 28 Feb 2002 08:13:37 -0500 (EST)
Received: from irams1.ira.uka.de ([129.13.10.5])
	by iraun2.uka.de with esmtp (Exim 3.30 #7 (Debian))
	id 16gQNP-0003il-00; Thu, 28 Feb 2002 14:13:39 +0100
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 16gQNP-0004my-00; Thu, 28 Feb 2002 14:13:39 +0100
Received: from i72pc127.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 g1SDDcW31129;
	Thu, 28 Feb 2002 14:13:38 +0100
Message-Id: <200202281313.g1SDDcW31129@i72pc127.tm.uka.de>
X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4+dev
To: Martin Karsten <Martin.Karsten@KOM.tu-darmstadt.de>
cc: nsis@ietf.org
Subject: Re: [NSIS] suggestions for draft-ietf-nsis-req-00.txt 
In-Reply-To: Message from Martin Karsten <Martin.Karsten@KOM.tu-darmstadt.de> 
   of "Thu, 28 Feb 2002 14:01:35 +0100." <200202281301.g1SD1Z500986@KOM.tu-darmstadt.de> 
References: <200202281301.g1SD1Z500986@KOM.tu-darmstadt.de> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 28 Feb 2002 14:13:38 +0100
From: Roland Bless <bless@tm.uka.de>
Sender: nsis-admin@ietf.org
Errors-To: nsis-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Next Steps in Signaling <nsis.ietf.org>
X-BeenThere: nsis@ietf.org

Hi Martin,

> > > 'Aggregate'
> > > - add an explicit statement that packets belonging to an aggregate must be
> > >   commonly and uniquely identifiable, because otherwise aggregation doesn't
> > >   make much sense.
> > 
> > I disagree here, because aggregation is usually performed at service level,
> > i.e., the service has to have technically the same characteristics/attributes,
> > e.g., a guaranteed rate. If one considers DiffServ domains as a possible QoS 
> > implementation architecture, each DiffServ domain may use different PHBs 
> > (with different codepoints) to provide an equivalent service. Therefore,
> > packets will usually be different along the path of an aggregate.
> 
> Correct, but then all packets will all have the same DSCP within a domain,
> which essentially is the common and unique identifier I'm referring to.
> 
> Let me rephrase:
> ... packets belonging to an aggregate must be commonly and uniquely
> identifiable per QoS domain ...

Ok, I considered the multi-domain case...

> > > Section 5.2.5, IP Fragmentation
> > > 
> > > I would suggest to remove this requirement as it increases the complexity
> > > without much benefit. There are good reasons, why IP fragmentation is
> > > usually not supported by QoS signalling. Further, IPv6 does not support IP
> > > fragmentation at forwarding nodes.
> > 
> > IPv6 is definitely not a problem in this context, because nsis signaling
> > will always mean fragmentation from end to end between to adjacent nsis
> > nodes. Thus, every nsis node will able to fragment its signaling
> > messages and any router will be able to forward these messages (but it
> > will not fragment by itself at all). On the other hand, why shouldn't we
> > allow fragmentation? It will be an implementation decision whether the
> > nsis protocol should require a reliable transport protocol such as SCTP
> > or whether it should do all the stuff by itself (IMHO it shouldn't).
> > Sure, in the latter case an implementation without fragmentation 
> > will be easier.
> 
> I was assuming that the requirement in 5.2.5 refers to the data packets
> rather than signalling packets. If it only refers to signalling packets,
> then of course, forget my comment.

Conclusion: This different interpretation indicates that 5.2.5 needs to be 
more precise... :-)

Cheers,
 Roland


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



From daemon@ns.ietf.org  Thu Feb 28 08:18: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 IAA21379
	for <nsis-archive@odin.ietf.org>; Thu, 28 Feb 2002 08:18:10 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id IAA27851
	for nsis-archive@odin.ietf.org; Thu, 28 Feb 2002 08:18: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 IAA27261;
	Thu, 28 Feb 2002 08:05:46 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA27226
	for <nsis@ns.ietf.org>; Thu, 28 Feb 2002 08:05:43 -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 IAA20734
	for <nsis@ietf.org>; Thu, 28 Feb 2002 08:05:39 -0500 (EST)
Received: from irams1.ira.uka.de ([129.13.10.5])
	by iraun2.uka.de with esmtp (Exim 3.30 #7 (Debian))
	id 16gQFh-0003bV-00; Thu, 28 Feb 2002 14:05:41 +0100
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 16gQFg-0004dX-00; Thu, 28 Feb 2002 14:05:40 +0100
Received: from i72pc127.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 g1SD5eW31056;
	Thu, 28 Feb 2002 14:05:40 +0100
Message-Id: <200202281305.g1SD5eW31056@i72pc127.tm.uka.de>
X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4+dev
To: danny.goderis@alcatel.be
cc: "Vlora Rexhepi (ELN)" <Vlora.Rexhepi@eln.ericsson.se>,
        "'David.Partain@ericsson.com'" <David.Partain@ericsson.com>,
        NSIS Mailing List <nsis@ietf.org>
Subject: Re: [NSIS] WG requirements draft 
In-Reply-To: Message from danny.goderis@alcatel.be 
   of "Wed, 27 Feb 2002 10:20:53 +0100." <3C7CA4F5.1BF53A0B@alcatel.be> 
References: <OF2E477E48.F9BDC17D-ONC1256B6C.007F27B1@alcatel.be>  <3C7CA4F5.1BF53A0B@alcatel.be> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 28 Feb 2002 14:05:40 +0100
From: Roland Bless <bless@tm.uka.de>
Sender: nsis-admin@ietf.org
Errors-To: nsis-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Next Steps in Signaling <nsis.ietf.org>
X-BeenThere: nsis@ietf.org

Hi Danny,

Yes, I agree that we have to define the interfaces for which we are
developing nsis protocols. But in this context we have also to name
the entities that talk to each other via these interfaces/protocols. 
We should consider a wide range of scenarios to find a common 
denominator for these interfaces.

Regards,
 Roland

Danny wrote:

> It was not my intention to exclude whatever approach. 
> Basically i agree that NSIS QoS signaling should allow for interworking
> of different QoS approaches/provisioning and the NSIS protocol could be
> a kind of "signaling glue" between different approaches. 
> 
> My main concern for now is that requirements are discussed for an
> "abstract" protocol without taking into account the concrete interfaces
> (scenarios) where the protocol will be applied and thus to forget
> concrete problems (like scalability) that are already discussed for a
> long time.


-- 
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 Feb 28 09:49: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 JAA25961
	for <nsis-archive@odin.ietf.org>; Thu, 28 Feb 2002 09:49:50 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id JAA03808
	for nsis-archive@odin.ietf.org; Thu, 28 Feb 2002 09: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 JAA03594;
	Thu, 28 Feb 2002 09:45: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 JAA03560
	for <nsis@optimus.ietf.org>; Thu, 28 Feb 2002 09:45:22 -0500 (EST)
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 JAA25607
	for <nsis@ietf.org>; Thu, 28 Feb 2002 09:45:18 -0500 (EST)
Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19)
	id <1S9WNV7M>; Thu, 28 Feb 2002 14:44:45 -0000
Message-ID: <76C92FBBFB58D411AE760090271ED4181EA184@rsys002a.roke.co.uk>
From: "Hancock, Robert" <robert.hancock@roke.co.uk>
To: nsis@ietf.org
Subject: RE: [NSIS] RE: Modularity and grouping QoS requirements
Date: Thu, 28 Feb 2002 14:44:42 -0000
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 <nsis.ietf.org>
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"

A question on what is really being proposed here (about modularity/grouping):

When people say that we should group the requirements according to things like UNI(access) or NNI(backbone), do they mean

1. that we should annotate requirements according to which network environments they are particularly applicable to or crucial for (e.g. 'scalability is important in the core' and so on)

OR do they mean

2. that we already know there will be a UNI NSIS protocol and an NNI NSIS protocol and we are actually trying to write requirements specifications for these particular protocols

?

I'm entirely in sympathy with (1) - indeed, that's what I thought section 6 of the WG draft was trying to do. (More scenarios and the format might start to be tricky, but that's another question...)

I'm less in sympathy with (2), certainly at this stage - we need have the requirements and an overall framework first before making such a concrete decision. (And even then, I'm not sure that such clear network hierarchy boundaries are always so easy to draw in the Internet-in-the-wild. I would expect that allowing multiple protocols is needed, but it doesn't seem that we can yet constrain the solution by knowing exactly how many and where they are to be used.)

Or is there already a consensus on the 'two protocols is the solution' view within the WG?

Yours,

Robert H.

> -----Original Message-----
> From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]
> Sent: 27 February 2002 19:45
> To: Georgios.Karagiannis@eln.ericsson.se; brunner@ccrle.nec.de
> Cc: nsis@ietf.org
> Subject: [NSIS] RE: Modularity and grouping QoS requirements
> 
> 
> Hi Georgios,
> 
> A point of procedure:
> 
> [clip]
> > that is in line with what has been agreed during the 
> > NSIS WG meeting in Salt Lake City.
> 
> Agreements cannot be made during the meetings, but only
> on the mailing list.  However, we need to get consensus
> on this issue.
> 
> John
> 
> _______________________________________________
> 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  Thu Feb 28 09:50: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 JAA26067
	for <nsis-archive@odin.ietf.org>; Thu, 28 Feb 2002 09:50:51 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id JAA03906
	for nsis-archive@odin.ietf.org; Thu, 28 Feb 2002 09:50: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 JAA03087;
	Thu, 28 Feb 2002 09:38: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 JAA03000
	for <nsis@optimus.ietf.org>; Thu, 28 Feb 2002 09:38:06 -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 JAA25210
	for <nsis@ietf.org>; Thu, 28 Feb 2002 09:38:03 -0500 (EST)
From: danny.goderis@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 g1SEauJ10477;
	Thu, 28 Feb 2002 15:36:57 +0100 (MET)
Received: from alcatel.be ([138.203.67.19])
          by bemail04.net.alcatel.be (Lotus Domino Release 5.0.8)
          with ESMTP id 2002022815365440:1114 ;
          Thu, 28 Feb 2002 15:36:54 +0100 
Message-ID: <3C7E4084.77DB1740@alcatel.be>
Date: Thu, 28 Feb 2002 15:36:52 +0100
Organization: Alcatel CRC Antwerp
X-Mailer: Mozilla 4.72 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: "Geib, Ruediger" <Ruediger.Geib@t-systems.com>
Cc: jaseem@ee.ryerson.ca, bless@tm.uka.de, nsis@ietf.org
Subject: Re: Definition of QI was: Re: [NSIS] WG requirements draft
References: <OF565D9420.89432FC2-ONC1256B6E.003B2170@alcatel.be>
X-MIMETrack: Itemize by SMTP Server on BEMAIL04/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at
 02/28/2002 15:36:54,
	Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at
 02/28/2002 15:36:56,
	Serialize complete at 02/28/2002 15:36:56
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 JAA03001
Sender: nsis-admin@ietf.org
Errors-To: nsis-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Next Steps in Signaling <nsis.ietf.org>
X-BeenThere: nsis@ietf.org
Content-Transfer-Encoding: 8bit

Hi Geib,

Good point to bring in  also the concerns related to core networks. The
QoS problem space is quite different than in access (e.g. scalability is
a headache, while mobility is non-issue (just to put a trivial thing :-) 

see further in-line...

"Geib, Ruediger" wrote:
> 
> Muhammed,
> 
> I'm a core network engineer and I prefer fat pipes instead of per flow reservations. 

[DG] OK, we don't want to make the mistake of per-microflow processing
in core routers again, I think nobody objects to that.

I also prefer "provisioning" to "on the fly" aggregation as the mode of
"fat pipe" set up. That's the background. What I'd like to get may look
like that:

[DG] However, I think we should make distinction between provisioning
(making the resources available, e.g. fat-pipe set-up) and signaling
(consuming the resources, e.g. multiplexing microflows in the pipes at
the edges). Clearly resource provisioning may depend on the actual
technology of the concrete network (and is an operator's policy). I
should like to call this "local provisioning means" and the end-to-end
NSIS signaling should, in my opinion, be independent of this local
mechanisms. 

> 
> a) Initial situation:
> 
>       Edge QC--QC--QC--QC--QC--Edge QC
> 
> Note that also the "internal" QC's could be edge QC's. It's not relevant.
> 
> b) QoS Tunnel set up (being triggered by management, not by terminal per flow signalling)
> 
>       Edge QC==="Fat Pipe"===Edge QC
> 
> All the involved QC's should use standard NSIS signaling to set up the "fat pipe". 

[DG] I have some questions here. There might be some confusion
concerning "THE NSIS protocol". As I see it now, there could be a
"local" signaling and an "end-to-end" signaling. The local signaling is
reserving resources locally, e.g. in the core it could be RSVP-TE (or
just by management, in which case this "local signaling" might be
trivial) for setting up the fat pipes. Another example is maybe
signaling in UMTS from MT to (access) network edge, for reserving
resources in the access network. A lot of things exist already today,
which could be studied for improvement by NSIS. However, the missing
thing is the end-to-end stuff yielding really QoS end-to-end. 


During the fat pipe set up, the systems marked as "edge QCs" act as QI.
Note that than one requirement for NSIS would be to support reservations
to IP address + prefix range instead of IP address only. (Maybe even
several IP adress + prefix ranges!)
> 
> c) Now per flow reservations may turn up, being handled by direct QC edge to edge signaling:
> 
> Host QI--Edge QC==signals directly to==Edge QC--Host QI
> 
> This saves per flow signalling and state from all the intermediate QCs (and hence improves scaleability). Admission Control decisions are speeded up too. It's of course not a general solution, and some "per flow" signaling will have to be done by the intermediate QCs for destinations without pre-installed "fat pipes".

[DG] I have similar ideas regarding this "two-step" approach (at least
for core networks): pre-provision "fat pipes" by any means (RSVP-TE,
Network management or whatever) and then signal for per-flow resources
(AC is barely filling up the pipe until it's full).

> If you'd like to look at it that way, it's a requirement for NSIS signalling to support some kind of traffic engineering. Support here is limited to control "fat pipe" set up, maintenance and release.

[DG$ Here I am not sure it should be the first focus of NSIS, imho, NSIS
should have as first target the per-flow signaling and make the "local
provisioning means" transparant for the QoS signaling.

> 
> Another requirement in the above case is that the tunnel entry point must recognize a per flow reservation fitting to a specific tunnel.
> 
> Regards, Rüdiger
> 

Regards,
Danny


> 
> > -----Original Message-----
> > From: Muhammad Jaseemuddin [mailto:jaseem@ee.ryerson.ca]
> > Sent: Wednesday, February 27, 2002 7:58 PM
> > To: Geib, Ruediger
> > Cc: bless@tm.uka.de; nsis@ietf.org
> > Subject: Re: Definition of QI was: Re: [NSIS] WG requirements draft
> >
> >
> > Ruediger:
> >
> >  I agree that the requirement should also consider the case
> > where QC may
> > act as QI. I am not sure if I understood the example you gave. But, I
> > know for example in GPRS there is a network initiated PDP context
> > activation procedure, where the GGSN (QC) requests MS (QI) to
> > initiate
> > the PDP context activation procedure. This is a genuine case
> > because a
> > QC (e.g. GGSN or a an edge router) may receive packets for
> > delivery to
> > the hosts (normally a QI) for which QoS needs to be setup along the
> > path. In this case essentially QI remains the actual initiaor, but it
> > initiates at the request of QC.
> >
> > Cheers,
> > - Muhammad Jaseemuddin
> >
> > Geib, Ruediger wrote:
> >
> > >Roland,
> > >
> > >I agree with your view completely. Let's go on with the
> > requirements and stop a discussion of architectures. That's
> > part of the solutions.
> > >
> > >A requirement may be that in some cases a "QC" may act as
> > "QI": An edge to edge QoS tunnel set up (maybe even spanning
> > several domains). This would allow the tunnel entry point QC
> > to do per flow edge to edge admission control once the QI
> > requests service for the tunnel destination domain. To me
> > this is the simplest and therefore most desireable way of per
> > service reservation aggregation.
> > >
> > >Regards, Rüdiger
> > >
> > >>Hi all,
> > >>
> > >>I think we can solve this issue by not complicating the role model.
> > >>It is also mentioned in section 4.1 of the nsis-req draft that QoS
> > >>Controllers interact with other QoS Controllers (as I understood).
> > >>Therefore, there is signaling between different QCs. I don't think
> > >>that we should complicate the model by explicitly defining every QC
> > >>also as QI, although the QC initiates a further signaling
> > transaction
> > >>with another QC. I also don't think that the terms QC and
> > QI are not
> > >>generic enough to also cover a distributed approach. For a more
> > >>complete model my suggestion (we add also a QoS Responder):
> > >>
> > >>          Domain A             Domain B
> > >>        .......................      .......................
> > >>        .                     .      .                     .
> > >>QI <--> . QC <==> ... <==> QC . <==> . QC <==> ... <==> QC . <--> QR
> > >>        .......................      .......................
> > >>     a)       b)                  c)                           a)
> > >>
> > >>1.) The QI can be an end system or signaling proxy acting on
> > >>    behalf of an end system.
> > >>2.) There can be several QoS Controllers involved in signaling.
> > >>    Some of the QCs may be located within one administrative
> > >>    domain (allowing the distributed case where each router
> > >>    or each edge router or several BBs are involved within
> > >>    such a domain) whereas others are located within different
> > >>    domains.
> > >>3.) Finally, we should add the QoS Responder (QR) in order to have
> > >>    a "symmetric" model where the corresponding end system
> > >>    can be also involved in signaling (e.g., to let a
> > mobile terminal
> > >>    decide about the priority of requests due to scarce bandwidth).
> > >>    As with the QI the QR could be also a signaling proxy.
> > >>    Alternatively, the QC can act as proxy.
> > >>
> > >>I think that this model covers all the different signaling cases:
> > >>a) end <-> edge/network
> > >>b) network internal, also covering edge to edge (intra-domain)
> > >>c) network <-> network (inter-domain)
> > >>and considering the whole signaling scenario by combining
> > >>the parts
> > >>d) end to end (QI <--> QR indirectly via a)b)c), not at
> > >>application level)
> > >>
> > >>Won't this fit most use cases?
> > >>
> > >
> > >_______________________________________________
> > >nsis mailing list
> > >nsis@ietf.org
> > >https://www1.ietf.org/mailman/listinfo/nsis
> > >
> >
> > --
> > ==================================================
> > Muhammad Jaseemuddin
> > Associate Professor
> > Departement of Electrical and Computer Engineering
> > Ryerson University
> > 350 Victoria Street
> > Toronto, ON M5B 2K3
> > Tel: +1 416 979-5000x6073
> > Fax: +1 416 979-5280
> > Email: jaseem@ee.ryerson.ca
> > Web: http://www.ee.ryerson.ca/~jaseem
> > ==================================================
> >
> >
> >
> 
> _______________________________________________
> 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 Feb 28 10:09: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 KAA27164
	for <nsis-archive@odin.ietf.org>; Thu, 28 Feb 2002 10:09:13 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id KAA05242
	for nsis-archive@odin.ietf.org; Thu, 28 Feb 2002 10:09:16 -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 JAA04172;
	Thu, 28 Feb 2002 09:56: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 JAA04143
	for <nsis@optimus.ietf.org>; Thu, 28 Feb 2002 09:56:32 -0500 (EST)
Received: from mail1.telekom.de ([62.225.183.235])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26380
	for <nsis@ietf.org>; Thu, 28 Feb 2002 09:56:27 -0500 (EST)
Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Thu, 28 Feb 2002 15:54:04 +0100
Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19)
	id <F3BAFCJJ>; Thu, 28 Feb 2002 15:55:37 +0100
Message-Id: <DFD875E85664D3118FA6080006277DE70362C8E0@U8PN2>
From: "Geib, Ruediger" <Ruediger.Geib@t-systems.com>
To: danny.goderis@alcatel.be
Cc: nsis@ietf.org
Subject: RE: Definition of QI was: Re: [NSIS] WG requirements draft
Date: Thu, 28 Feb 2002 15:55:29 +0100
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 JAA04144
Sender: nsis-admin@ietf.org
Errors-To: nsis-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Next Steps in Signaling <nsis.ietf.org>
X-BeenThere: nsis@ietf.org
Content-Transfer-Encoding: 8bit

Hi Danny

> [DG] I have similar ideas regarding this "two-step" approach (at least
> for core networks): pre-provision "fat pipes" by any means (RSVP-TE,
> Network management or whatever) and then signal for per-flow resources
> (AC is barely filling up the pipe until it's full).

That's not quite what I'm thinking of. If the mechanism I suggested should support E2E services, RSVP-TE and network management aren't the vehicles to set up reservation aggregates accross arbitrary domains (especially concatenations of domains). RSVP-TE is a layer 2 specific protocol (currently supporting only routing area related TE) and network management is domain specific. What I am looking for is a mechanism to carry the reservation aggregate related signaling also through a full domain (and not only a single routing area) and between domains. How a network provider modifies resources within his domain and at which layer doesn't matter to NSIS and therefore isn't relevant for my proposal. 

Regards, Rüdiger

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



From daemon@optimus.ietf.org  Thu Feb 28 10:16: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 KAA27611
	for <nsis-archive@odin.ietf.org>; Thu, 28 Feb 2002 10:16:37 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id KAA05685
	for nsis-archive@odin.ietf.org; Thu, 28 Feb 2002 10:16: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 KAA05289;
	Thu, 28 Feb 2002 10:09:22 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA05255
	for <nsis@optimus.ietf.org>; Thu, 28 Feb 2002 10:09:20 -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 KAA27178
	for <nsis@ietf.org>; Thu, 28 Feb 2002 10:09:16 -0500 (EST)
From: danny.goderis@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 g1SF8l719574;
	Thu, 28 Feb 2002 16:08:47 +0100 (MET)
Received: from alcatel.be ([138.203.67.19])
          by bemail04.net.alcatel.be (Lotus Domino Release 5.0.8)
          with ESMTP id 2002022816083705:1175 ;
          Thu, 28 Feb 2002 16:08:37 +0100 
Message-ID: <3C7E47F2.329E6067@alcatel.be>
Date: Thu, 28 Feb 2002 16:08:34 +0100
Organization: Alcatel CRC Antwerp
X-Mailer: Mozilla 4.72 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: "Geib, Ruediger" <Ruediger.Geib@t-systems.com>
CC: nsis@ietf.org
Subject: Re: Definition of QI was: Re: [NSIS] WG requirements draft
References: <OF27904E2E.00067FF9-ONC1256B6E.005233EE@alcatel.be>
X-MIMETrack: Itemize by SMTP Server on BEMAIL04/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at
 02/28/2002 16:08:37,
	Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at
 02/28/2002 16:08:47,
	Serialize complete at 02/28/2002 16:08:47
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 KAA05256
Sender: nsis-admin@ietf.org
Errors-To: nsis-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Next Steps in Signaling <nsis.ietf.org>
X-BeenThere: nsis@ietf.org
Content-Transfer-Encoding: 8bit

Hi Geib,

see in-line...


"Geib, Ruediger" wrote:
> 
> Hi Danny
> 
> > [DG] I have similar ideas regarding this "two-step" approach (at least
> > for core networks): pre-provision "fat pipes" by any means (RSVP-TE,
> > Network management or whatever) and then signal for per-flow resources
> > (AC is barely filling up the pipe until it's full).
> 
> That's not quite what I'm thinking of. If the mechanism I suggested should support E2E services, RSVP-TE and network management aren't the vehicles to set up reservation aggregates accross arbitrary domains (especially concatenations of domains). RSVP-TE is a layer 2 specific protocol (currently supporting only routing area related TE) and network management is domain specific. 

[DG] Indeed, that's why I didn't understand it should be part of NSIS
scope (clarified now: it is not!)

What I am looking for is a mechanism to carry the reservation aggregate
related signaling also through a full domain (and not only a single
routing area) and between domains. 

So, this is another problem statement than the one I had actually in
mind (enabling e.g. real-time multimedia over the Internet). The problem
if "inter-domain" fat pipes seems different and (as you suggested in
previous mail) is indeed related with some traffic engineering aspects.
Is this in the NSIS scope ?

Regards,
Danny

How a network provider modifies resources within his domain and at which
layer doesn't matter to NSIS and therefore isn't relevant for my
proposal.
> 
> Regards, Rüdiger
> 
> _______________________________________________
> 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 Feb 28 10:44: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 KAA29188
	for <nsis-archive@odin.ietf.org>; Thu, 28 Feb 2002 10:44:37 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id KAA07435
	for nsis-archive@odin.ietf.org; Thu, 28 Feb 2002 10:44: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 KAA07249;
	Thu, 28 Feb 2002 10: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 KAA07214
	for <nsis@optimus.ietf.org>; Thu, 28 Feb 2002 10:39:39 -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 KAA28893
	for <nsis@ietf.org>; Thu, 28 Feb 2002 10:39:35 -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 g1SFd7A26953
	for <nsis@ietf.org>; Thu, 28 Feb 2002 16:39:07 +0100 (MET)
To: nsis@ietf.org
X-Mailer: Lotus Notes Release 5.0.5  September 22, 2000
Message-ID: <OF7F077DFA.CD701161-ONC1256B6E.004020E0@net.alcatel.be>
Date: Thu, 28 Feb 2002 16:38:51 +0100
X-MIMETrack: Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at
 02/28/2002 16:39:06
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Subject: [NSIS] interface model or QC/QI model
Sender: nsis-admin@ietf.org
Errors-To: nsis-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Next Steps in Signaling <nsis.ietf.org>
X-BeenThere: nsis@ietf.org

Hi all,

I have been thinking about the (many) discussions we have had about the
QC/QI model and what I will call the 'topological interfaces' model. Let me
try to give my take on this.
If we try to make a topological separation in the network we might come up
with:

                +-------------+             +-------------+
                |             |             |             |
+---+         +---+         +---+         +---+         +---+
| H |-------->| EN|-------->| EN|-------->| BN|-------->| BN|
+---+         +---+         +---+         +---+         +---+
                |access       |             |core         |
                +-------------+             +-------------+
host            edge node                   border node

Let's now look at how end-to-end QoS could be signalled in this network. We
deliberately made a distinction between end-to-end QoS signalling (item
(2)) and local QoS signaling (item(1)). Local QoS signaling may be used to
set up 'fat pipes' that can be used by the end-to-end flows.

(1) For the local QoS provisioning and signaling, the situation is fairly
obvious. For each section of the network, we have a local QI (LQI) a local
QoS terminator (LQT), and possibly local QCs (LQC, not shown for
simplicity). Existing local QoS provisioning and signaling solutions could
be reused here. Alternatively, the NSIS protocol could be used here as
well.

+---+    +---++---+         +---+         +---+         +---+
|LQI|--->|LQT||LQI|-------->|LQT|-------->|LQI|-------->|LQT|
+---+    +---++---+         +---+         +---+         +---+

If we try to address the end-to-end responsabilites of the different nodes,
we have three possibilities (note that this lines up with the
host-access-core picture above):

(2.a) host is QI

+---+  NSIS   +---+   NSIS  +---+   NSIS  +---+  NSIS   +---+
| QI|-------->| QC|-------->| QC|-------->| QC|-------->| QC|  end-to-end
+---+         +---+         +---+         +---+         +---+
+---+    +---++---+         +---+         +---+         +---+
|LQI|--->|LQT||LQI|-------->|LQT|-------->|LQI|-------->|LQT|  local
+---+    +---++---+         +---+         +---+         +---+

(2.b) QI before access network

              +---+  NSIS   +---+  NSIS   +---+  NSIS   +---+
              | QI|-------->| QC|-------->| QC|-------->| QC|  end-to-end
              +---+         +---+         +---+         +---+
+---+    +---++---+         +---+         +---+         +---+
|LQI|--->|LQT||LQI|-------->|LQT|-------->|LQI|-------->|LQT|  local
+---+    +---++---+         +---+         +---+         +---+

(2.c) QI before the core network

                            +---+  NSIS   +---+   NSIS  +---+
                            | QI|-------->| QC|-------->| QC|  end-to-end
                            +---+         +---+         +---+
+---+    +---++---+         +---+         +---+         +---+
|LQI|--->|LQT||LQI|-------->|LQT|-------->|LQI|-------->|LQT|  local
+---+    +---++---+         +---+         +---+         +---+

The path to the end-to-end QI is then supported by the local QoS
technologies only (which presupposes the possibility to have a mapiing
between them). It is interesting to note that the location of the logical
(end-to-end) QI-QC interface can map to different topological interfaces
(with different requirements). For instance, in case (2.b) the QI-QC
interface would need to support mobility, whereas in (2.c) it does not. The
conclusion from these pictures is that the split QC/QI is not sufficient in
order to separate NSIS signaling requirements. Note that the QC/QI does
have its merits (see below) and that it could be fixed if we introduce
additional entities (e.g. Proxy QI which relays QI info).

On the other hand, if we look at in-band/out-of-band signaling we can have
the following situations:

(3.a)
                +-------------+             +-------------+
                |             |             |             |
+---+         +---+         +---+         +---+         +---+
| QI|- - - - >| QC|- - - - >| QC|- - - - >| QC|- - - - >| QC|
+---+         +---+         +---+         +---+         +---+
+---+         +---+         +---+         +---+         +---+
| H |-------->| EN|-------->| EN|-------->| BN|-------->| BN|
+---+         +---+         +---+         +---+         +---+
                |access       |             |core         |
                +-------------+             +-------------+
host            edge node                   border node

(3.b)

+---+ - - - - - - - >+---+ - - - - - - - - - - ->+---+
| QI|           +----| QC|----+             +----| QC|----+
+---+           |    +---+    |             |    +---+    |
                |             |             |             |
+---+         +---+         +---+         +---+         +---+
| H |-------->| EN|-------->| EN|-------->| BN|-------->| BN|
+---+         +---+         +---+         +---+         +---+
                |access       |             |core         |
                +-------------+             +-------------+
host            edge node                   border node

This means that we can not necessarily identify a QC or QI with a
particular node on the data path. The QC/QI paradigm, however, is useful
when considering local provisioning actions because a QC (be it distributed
or not) will be responsible to manage the local QoS provisioning. This
means that the usefulness of the QC/QI might lie in the parameters that
need to be considered (for e.g. provisioning) in QC or QI.

In conclusion:
- We need to use topological considerations in order to group the NSIS
signaling requirements.
- QC/QI is a natural way to discuss parameters that need to be available
for provisioning.

We could exploit this by making a distinction between:
- protocol content requirements (per QC/QI)
- protocol signaling requirements (per topological interface)

This would already give a first grouping of requirements and it would also
be inline with the requirement to separate the protocol from 'the
information it carries'.

Regards,
Sven.



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



From daemon@optimus.ietf.org  Thu Feb 28 11:59: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 LAA04106
	for <nsis-archive@odin.ietf.org>; Thu, 28 Feb 2002 11:59:23 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id LAA12788
	for nsis-archive@odin.ietf.org; Thu, 28 Feb 2002 11:59: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 LAA11732;
	Thu, 28 Feb 2002 11:43: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 LAA11701
	for <nsis@optimus.ietf.org>; Thu, 28 Feb 2002 11:43:36 -0500 (EST)
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 LAA03062
	for <nsis@ietf.org>; Thu, 28 Feb 2002 11:43:31 -0500 (EST)
Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19)
	id <1S9WNWFC>; Thu, 28 Feb 2002 16:40:43 -0000
Message-ID: <76C92FBBFB58D411AE760090271ED4181EA186@rsys002a.roke.co.uk>
From: "Hancock, Robert" <robert.hancock@roke.co.uk>
To: "'Roland Bless'" <bless@tm.uka.de>,
        Martin Karsten
	 <Martin.Karsten@KOM.tu-darmstadt.de>
Cc: nsis@ietf.org
Subject: comments on: RE: [NSIS] suggestions for draft-ietf-nsis-req-00.tx
	t 
Date: Thu, 28 Feb 2002 16:40:34 -0000
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 <nsis.ietf.org>
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"

hi all,

A number of these issues are to do with flow/aggregate identification/classification, which we did not write a specific definition for. Identification can be a hard issue (especially for aggregates or fragments), and there's a dependency on router technology (some routers may only be capable of classifying on particular fields, for example). However, from a definition point of view, it seems that the 'filter spec' concept of RSVP is directly applicable here, with the exception that
*) we aren't prejudging what fields the filter spec might refer to (OR people should say what they think should be possible)
*) the filter spec might be mutable (e.g. DSCP might change).
Given a definition of 'filter', we could then amend the definition of aggregate to say
"To be of practical use, an aggregate must be associated with a filter."
[We could say the same about flows as well.] Would this address the concerns?

On the fragmentation issue, it was certainly (IIRC) the intention that this applied to QoS treatment for fragmented user packets. So, maybe 5.2.5 should contain
"User data flows [or aggregates] which contain IP-fragmented packets should not have their QoS degraded."
In practical terms, this is mainly about having filters that can identify the fragments, which can be hard (unless you allow state in the classifier, you are restricted to traffic class fields, or the flow label for IPv6). I'm not sure whether there is any other practical impact of this requirement.
Since it's hard/restrictive, do people want to leave this out (in which case we should state it explicitly as a non-requirement)?

On the QSC case, I think the term is not overloaded, but some of the other definitions might make it look that way. In particular, 'Mapping' is just a statement that QSCs are pieces of data that are subject to transformation into other pieces of data; 'QoS initiator' is a statement that the QI is responsible for working out what the QSC for a flow is from upper layer information. The QSC is not invoked, the QSC is some of the data that is transferred in the invocation. Maybe we should change QI to
"this is responsible for initiating the QoS signaling for user traffic flow(s). This includes deriving the QSCs used in the signaling, based on user or application requirements (from the higher layers). The Initiator can also invoke local QoS provisioning mechanisms.  It can be located in the end system, but may reside elsewhere in network."

Is this clearer?

Robert H.

> -----Original Message-----
> From: Roland Bless [mailto:bless@tm.uka.de]
> Sent: 28 February 2002 13:14
> To: Martin Karsten
> Cc: nsis@ietf.org
> Subject: Re: [NSIS] suggestions for draft-ietf-nsis-req-00.txt 
> 
> 
> Hi Martin,
> 
> > > > 'Aggregate'
> > > > - add an explicit statement that packets belonging to 
> an aggregate must be
> > > >   commonly and uniquely identifiable, because otherwise 
> aggregation doesn't
> > > >   make much sense.
> > > 
> > > I disagree here, because aggregation is usually performed 
> at service level,
> > > i.e., the service has to have technically the same 
> characteristics/attributes,
> > > e.g., a guaranteed rate. If one considers DiffServ 
> domains as a possible QoS 
> > > implementation architecture, each DiffServ domain may use 
> different PHBs 
> > > (with different codepoints) to provide an equivalent 
> service. Therefore,
> > > packets will usually be different along the path of an aggregate.
> > 
> > Correct, but then all packets will all have the same DSCP 
> within a domain,
> > which essentially is the common and unique identifier I'm 
> referring to.
> > 
> > Let me rephrase:
> > ... packets belonging to an aggregate must be commonly and uniquely
> > identifiable per QoS domain ...
> 
> Ok, I considered the multi-domain case...
> 
> > > > Section 5.2.5, IP Fragmentation
> > > > 
> > > > I would suggest to remove this requirement as it 
> increases the complexity
> > > > without much benefit. There are good reasons, why IP 
> fragmentation is
> > > > usually not supported by QoS signalling. Further, IPv6 
> does not support IP
> > > > fragmentation at forwarding nodes.
> > > 
> > > IPv6 is definitely not a problem in this context, because 
> nsis signaling
> > > will always mean fragmentation from end to end between to 
> adjacent nsis
> > > nodes. Thus, every nsis node will able to fragment its signaling
> > > messages and any router will be able to forward these 
> messages (but it
> > > will not fragment by itself at all). On the other hand, 
> why shouldn't we
> > > allow fragmentation? It will be an implementation 
> decision whether the
> > > nsis protocol should require a reliable transport 
> protocol such as SCTP
> > > or whether it should do all the stuff by itself (IMHO it 
> shouldn't).
> > > Sure, in the latter case an implementation without fragmentation 
> > > will be easier.
> > 
> > I was assuming that the requirement in 5.2.5 refers to the 
> data packets
> > rather than signalling packets. If it only refers to 
> signalling packets,
> > then of course, forget my comment.
> 
> Conclusion: This different interpretation indicates that 
> 5.2.5 needs to be 
> more precise... :-)
> 
> Cheers,
>  Roland
> 
> 
> _______________________________________________
> 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  Thu Feb 28 12:20: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 MAA05981
	for <nsis-archive@odin.ietf.org>; Thu, 28 Feb 2002 12:20:53 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id MAA16102
	for nsis-archive@odin.ietf.org; Thu, 28 Feb 2002 12: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 MAA14817;
	Thu, 28 Feb 2002 12:06: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 MAA14782
	for <nsis@optimus.ietf.org>; Thu, 28 Feb 2002 12:06:07 -0500 (EST)
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 MAA04702
	for <nsis@ietf.org>; Thu, 28 Feb 2002 12:05:57 -0500 (EST)
Received: from KOM.tu-darmstadt.de by mailserver.KOM.e-technik.tu-darmstadt.de (8.7.5/8.7.5) with ESMTP id SAA16843; Thu, 28 Feb 2002 18:05:30 +0100 (MET)
From: Martin Karsten <Martin.Karsten@KOM.tu-darmstadt.de>
Received: from KOM.tu-darmstadt.de by KOM.tu-darmstadt.de (8.11.2/8.7.5) id g1SH4x802946; Thu, 28 Feb 2002 18:04:59 +0100
Message-Id: <200202281704.g1SH4x802946@KOM.tu-darmstadt.de>
Subject: Re: comments on: RE: [NSIS] suggestions for draft-ietf-nsis-req-00.tx
 t
In-Reply-To: <76C92FBBFB58D411AE760090271ED4181EA186@rsys002a.roke.co.uk> from
 "Hancock, Robert" at "Feb 28, 2002 04:40:34 pm"
To: "Hancock, Robert" <robert.hancock@roke.co.uk>
Date: Thu, 28 Feb 2002 18:04:59 +0100 (CET)
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 <nsis.ietf.org>
X-BeenThere: nsis@ietf.org
Content-Transfer-Encoding: 7bit

> "To be of practical use, an aggregate must be associated with a filter."
> [We could say the same about flows as well.] Would this address the concerns?

Yep.

> On the fragmentation issue, it was certainly (IIRC) the intention that
> this applied to QoS treatment for fragmented user packets. So, maybe 5.2.5
> should contain "User data flows [or aggregates] which contain
> IP-fragmented packets should not have their QoS degraded." In practical
> terms, this is mainly about having filters that can identify the
> fragments, which can be hard (unless you allow state in the classifier,
> you are restricted to traffic class fields, or the flow label for IPv6).
> I'm not sure whether there is any other practical impact of this
> requirement. Since it's hard/restrictive, do people want to leave this out
> (in which case we should state it explicitly as a non-requirement)?

Another practical issue is that of translating an NSIS QoS specification
into anything that is handed over to the QoS enforcement system (QoS
technology?). Many QoS technologies and algorithms need or benefit from
(some) knowledge about the packet rates in order to decide about admission.
I believe that allowing fragmentation increases complexity here, as well.

> On the QSC case, I think the term is not overloaded, but some of the other
> definitions might make it look that way. In particular, 'Mapping' is just
> a statement that QSCs are pieces of data that are subject to
> transformation into other pieces of data; 'QoS initiator' is a statement
> that the QI is responsible for working out what the QSC for a flow is from
> upper layer information. The QSC is not invoked, the QSC is some of the
> data that is transferred in the invocation. Maybe we should change QI to
> "this is responsible for initiating the QoS signaling for user traffic
> flow(s). This includes deriving the QSCs used in the signaling, based on
> user or application requirements (from the higher layers). The Initiator
> can also invoke local QoS provisioning mechanisms.  It can be located in
> the end system, but may reside elsewhere in network."
> 
> Is this clearer?

I'm undediced and I would draw the following analogy. In an OO programming
language, there are 'classes' and 'objects'. I believe that terms like
'service class' and 'service invocation' are needed to express a similar
distinction in the context of QoS signalling.

Martin

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



From daemon@optimus.ietf.org  Thu Feb 28 14:59: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 OAA16345
	for <nsis-archive@odin.ietf.org>; Thu, 28 Feb 2002 14:59:22 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id OAA25589
	for nsis-archive@odin.ietf.org; Thu, 28 Feb 2002 14:59: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 OAA25408;
	Thu, 28 Feb 2002 14:55: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 OAA25375
	for <nsis@optimus.ietf.org>; Thu, 28 Feb 2002 14:55:04 -0500 (EST)
Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16102
	for <nsis@ietf.org>; Thu, 28 Feb 2002 14:54:55 -0500 (EST)
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 g1SGe7Zc010938
	for <nsis@ietf.org>; Thu, 28 Feb 2002 17:40:21 +0100 (MET)
Received: FROM esealnt747.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Thu Feb 28 17:38:58 2002 +0100
Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <F4H17PCD>; Thu, 28 Feb 2002 17:37:58 +0100
Message-ID: <E244E44D6AB85E40AEEF7EAABE3545FAF78464@enleent104.nl.eu.ericsson.se>
From: "Vlora Rexhepi (ELN)" <Vlora.Rexhepi@eln.ericsson.se>
To: "'Hancock, Robert'" <robert.hancock@roke.co.uk>, nsis@ietf.org
Subject: RE: [NSIS] RE: Modularity and grouping QoS requirements
Date: Thu, 28 Feb 2002 17:38:54 +0100
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 <nsis.ietf.org>
X-BeenThere: nsis@ietf.org

Hi Robert,

|1. that we should annotate requirements according to which 
|network environments they are particularly applicable to or 
|crucial for (e.g. 'scalability is important in the core' and so on)

I would rather say that the QoS requirements would be derived 
from different scenarios/use cases and than grouped according to
the interfaces they apply to.
 
|OR do they mean
|
|2. that we already know there will be a UNI NSIS protocol and an 
|NNI NSIS protocol and we are actually trying to write requirements
|specifications for these particular protocols

I don't think this is a discussion issue at this point.

|I'm entirely in sympathy with (1) - indeed, that's what I 
|thought section 6 of the WG draft was trying to do. (More 
|scenarios and the format might start to be tricky, but that's 
|another question...)

Section 6 of the WG draft gives a good overview on the importance 
of the requirements to the Scenarios 1 - 5, but I would prefer 
to see which requirements apply to particular interfaces 
in the Scenarios 1-5.


Regards,
Vlora 



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



From daemon@optimus.ietf.org  Thu Feb 28 16:24: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 QAA20380
	for <nsis-archive@odin.ietf.org>; Thu, 28 Feb 2002 16:24:14 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id QAA01590
	for nsis-archive@odin.ietf.org; Thu, 28 Feb 2002 16:24: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 QAA00809;
	Thu, 28 Feb 2002 16:11: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 QAA00778
	for <nsis@optimus.ietf.org>; Thu, 28 Feb 2002 16:11:34 -0500 (EST)
Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19885
	for <nsis@ietf.org>; Thu, 28 Feb 2002 16:11:29 -0500 (EST)
Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137])
	by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g1SGDeZc003398;
	Thu, 28 Feb 2002 17:15:06 +0100 (MET)
Received: from wrtw014.wrn.ki.sw.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T))
	id RAA06518; Thu, 28 Feb 2002 17:13:29 +0100
From: Gabor.Fodor@era-t.ericsson.se (Gabor Fodor)
Received: by wrtw014.wrn.ki.sw.ericsson.se (8.8.8+Sun/client-1.3)
	id RAA26821; Thu, 28 Feb 2002 17:13:28 +0100 (MET)
Date: Thu, 28 Feb 2002 17:13:28 +0100 (MET)
Message-Id: <200202281613.RAA26821@wrtw014.wrn.ki.sw.ericsson.se>
To: robert.hancock@roke.co.uk
Subject: Re: another requirements question (was: RE: [NSIS] A few comments to draft-fodor-reqts-cellular-netwks-00 .txt)
Cc: jmanner@cs.Helsinki.FI, brian.williams@ericsson.com.au, 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 <nsis.ietf.org>
X-BeenThere: nsis@ietf.org

Hi Robert,

thnaks for these comments, please see my comments inline :


> From robert.hancock@roke.co.uk Wed Feb 27 18:29:21 2002
> From: "Hancock, Robert" <robert.hancock@roke.co.uk>
> To: "'Brian Williams'" <brian.williams@ericsson.com.au>
> Cc: "'Jukka Manner'" <jmanner@cs.Helsinki.FI>,
>         Gabor Fodor
> 	 <Gabor.Fodor@era-t.ericsson.se>, nsis@ietf.org
> Subject: another requirements question (was: RE: [NSIS] A few comments to 
> 	draft-fodor-reqts-cellular-netwks-00 .txt)
> Date: Wed, 27 Feb 2002 17:27:22 -0000
> MIME-Version: 1.0
> X-Status: 
> X-Keywords:
> X-UID: 18
> 
> Hi Brian,
> 
> [others: the requirements question is at the end if you want to skip to it.]
> 
> It seems we all probably agree that the scenario where the node responsible for requesting QoS (which might commonly be the application node) is not attached to the wireless link is an important one, in which case it's clear (to me) that wireless related parameters are relevant to NSIS QoS classes. We should probably have a scenario like this in the requirements draft. [I might have described this as 'QoS initiator not directly attached to the wireless link' but some people might have regarded this phrasing as provocative...]
> 
[GF]
Yes, I agree that we definitely need such a scenario. Actually, the scenario that we have
in the draft can be developed further to such a scenario quite easily. I understand from
the comments on the draft that such a scenario would be useful to clarify further our
requirements (R1-R7). 
[GF]

> But the more general question of NSIS-L2 interactions (also stimulated by your point about 'other wireless networks') raises a requirements/scope issue about NSIS:
> Given a pair of independently implemented NSIS signalling entities (either side of the wireless link), it should be the case that NSIS protocol(s) will define how the QoS negotiation proceeds. But is this enough to make the lower layer negotiation proceed in a sensible way, or could there be reservation collisions (or neither side bothers at all...)?
> 
> In our framework document (draft-hancock-whatsit), we basically assumed that this would be defined somehow specifically to the lower layers in use (maybe in some kind of NSIS-over-foo document), but I'm not certain this is good enough. For example, if we believe that NSIS might get used in UMTS packet domain [warning: abandon all hope of following the rest of this sentence those not familiar with UMTS], then either the GGSN or UE or both or neither could do PDP context activation when they saw an NSIS message at the upper layers - the same ambiguity arises currently when they see an RSVP RESV (and I don't believe there is a standardised way for things to be done in that case either).
> 
> *** Requirements question ***
> Does the NSIS signalling need to be able to convey/negotiate information about which end of a link is going to be responsible for initiating lower layer bearer setup?
> 
> I don't think the answer is obviously yes or no here. There's a lot of different wireless link types out there.
>
[GF]
Good point and I agree that the answer to this important question is not obvious.
The general intention with the wireless hints is to help the lower
layers to establish a L2 bearer, and from this point of view any information
element that helps to eliminate such an ambiguity is useful.
For instance, it may cause an additional delay if there is ambiguity at L2
which node should initiate the setup or the modification of a L2 bearer.

I would also find it useful at a later stage if such an NSIS-over-foo 
document provided guidelines as to how to use the protocol over some important
L2 technologies.
[GF]

 
> Yours,
> 
> Robert H.
> 

/Gabor

> > -----Original Message-----
> > From: Brian Williams [mailto:brian.williams@ericsson.com.au]
> > Sent: 21 February 2002 07:41
> > To: Hancock, Robert
> > Cc: 'Jukka Manner'; Gabor Fodor; nsis@ietf.org
> > Subject: RE: [NSIS] A few comments to
> > draft-fodor-reqts-cellular-netwks-00 .txt
> > 
> > 
> > Hi Robert.
> > I would definitely agree that there are many different scenarios, and
> > one with the application node sitting behind a wireless router/gateway
> > is the most obvious situation which introduces signalling 
> > requirements.
> > 
> > I would also add though that even within one physical node, 
> > there can be
> > scenarios that effectively become an equivalent to this 
> > application node
> > behind a gateway router. For example, on my PC I have run multiple
> > virtual machines. The communication between these virtual machines
> > occurs over a virtual ethernet, but it is all within one node.
> > 
> > There can also be cases where a node works towards one 
> > logical interface
> > internally, which is then adapted one or more times until it 
> > reaches the
> > real interface such as with levels of tunneling.
> > 
> > And finally, we should not rule out that other wireless networks could
> > control the link layer signalling from the network instead of from the
> > terminal.  
> > 
> > In all of these cases, there are reasons to have additional 
> > information
> > important for the wireless operation available from the application
> > level QoS interface, and possibly carried in the IP level QoS 
> > protocol.
> > I do agree though that dependent on the exact scenario, this 
> > information
> > may not need to be transmitted over the wireless link.
> > /brian
> > 
> > On Thu, 2002-02-21 at 01:18, Hancock, Robert wrote:
> > > Hi Jukka, Gabor,
> > > 
> > > On the UDP-lite issue, my understanding is that UDP-lite 
> > only tells you that some of the packet is checksum protected 
> > and some isn't. The sophistication of signalling required for 
> > full UEP (e.g. to support AMR codec operation) is much 
> > greater. I guess if you had UEP QoS signalling you wouldn't 
> > need UDP-lite, you could just switch the checksum off 
> > altogether (at least for IPv4).
> > > 
> > > I was more concerned about whether the scenario as 
> > presented really justifies the need for wireless-related 
> > parameters at all. It seems to concentrate on the case where 
> > the wireless link is the last hop, directly connected to the 
> > node where the end application is running. In that case, it's 
> > clear that good quality IP QoS (fine grained, efficient, 
> > local etc.) is important, more so than in fixed networks. I 
> > think it's less clear that the IP layer signalling needs to 
> > have link (or 'link-ish') parameters in it. After all, the 
> > link layers already have their own signalling, and can tune 
> > the link to the required QoS even more tightly.
> > > 
> > > It's true that if applications use the IntServ classes to 
> > request QoS from their network stack, these classes need to 
> > be extended with wireless hints. But that's a comment on the 
> > deficiency of basing inter-layer interfaces on protocols, not 
> > a requirement to extend the protocol itself.
> > > 
> > > One reason we thought to be very careful here was that if 
> > you have wireless-related parameters being exchanged at both 
> > IP (RSVP) and link layers, it might be hard for independent 
> > implementors of each end to work out which layer to use for 
> > negotiation and in which order, and which layer was in 
> > charge. This was raised after SLC as an open issue on the 
> > list, but the argument wasn't really clear (partly my fault).
> > > 
> > > I think there _is_ actually a good case for having wireless 
> > related parameters, but that the justifying scenario is where 
> > the wireless link is 'interior' (e.g. 3G mobile acting as a 
> > wireless router for a local subnet), but in that case you 
> > might need take into account other considerations as well. 
> > Then you need to get the wireless-related information from 
> > the application into the router. But in either case, we need 
> > to have a clear model of how the link layer negotiation 
> > interacts with the IP layer negotiation.
> > > 
> > > Or did I miss something?
> > > 
> > > Robert H.
> > > 
> > > > -----Original Message-----
> > > > From: Jukka Manner [mailto:jmanner@cs.Helsinki.FI]
> > > > Sent: 20 February 2002 12:00
> > > > To: Gabor Fodor
> > > > Cc: nsis@ietf.org
> > > > Subject: [NSIS] A few comments to
> > > > draft-fodor-reqts-cellular-netwks-00.txt
> > > > 
> > > > 
> > > > 
> > > > 	Hi,
> > > > 
> > > > 	As I read the draft, two requirements left me wondering:
> > > > 
> > > > 	R2: how does this match with the UDP-lite proposal, 
> > > > where the UDP
> > > > header indicates the need for UEP. Thus, does the QoS primitives /
> > > > signalling need to indicate the need for UEP? If the 
> > > > transport protocol
> > > > does not support UEP, you won't get the packet sent 
> > to/accepted at the
> > > > receiver. Also, you don't even need any QoS mechanism to 
> > use UDP-lite.
> > > > 
> > > > 	R3: you seem to assume that doing bi-directional resource 
> > > > allocations also implies that routing is symmetric for uplink and 
> > > > downlink. Since IP routing is asymmetric, I doubt that 
> > bi-directional 
> > > > reservations are possible with a single mechanism, but rather 
> > > > imply that 
> > > > there must be separate signalling for the two directions. 
> > > > Thus, eg. RSVP 
> > > > makes it possible to have asymmetric reservations on the two 
> > > > directions.
> > > > 
> > > > 	Cheers,
> > > > 
> > > > 	Jukka
> > > > 
> > > > 
> > > > _______________________________________________
> > > > nsis mailing list
> > > > nsis@ietf.org
> > > > https://www1.ietf.org/mailman/listinfo/nsis
> > > > 
> > > 
> > > ----
> > > 
> > 
> > > 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.
> > 
> > 

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



From daemon@optimus.ietf.org  Thu Feb 28 16:35: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 QAA20992
	for <nsis-archive@odin.ietf.org>; Thu, 28 Feb 2002 16:35:10 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id QAA02300
	for nsis-archive@odin.ietf.org; Thu, 28 Feb 2002 16:35: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 QAA02159;
	Thu, 28 Feb 2002 16:31: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 QAA02119
	for <nsis@optimus.ietf.org>; Thu, 28 Feb 2002 16:30: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 QAA20714
	for <nsis@ietf.org>; Thu, 28 Feb 2002 16:30:52 -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.1.0/Switch-2.1.0) with ESMTP id g1SLV4Z06091
	for <nsis@ietf.org>; Thu, 28 Feb 2002 23:31:04 +0200 (EET)
Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T595b7dbe65ac158f24077@esvir04nok.ntc.nokia.com>;
 Thu, 28 Feb 2002 23:30:56 +0200
Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779);
	 Thu, 28 Feb 2002 23:30:55 +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] RE: Modularity and grouping QoS requirements
Date: Thu, 28 Feb 2002 23:30:54 +0200
Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD38D48@esebe004.NOE.Nokia.com>
Thread-Topic: [NSIS] RE: Modularity and grouping QoS requirements
Thread-Index: AcHAkeG4mmtWbeUTRV2gMl6yk1/cGAAC+8vQ
To: <Vlora.Rexhepi@eln.ericsson.se>, <robert.hancock@roke.co.uk>,
        <nsis@ietf.org>
X-OriginalArrivalTime: 28 Feb 2002 21:30:55.0284 (UTC) FILETIME=[344C6740:01C1C09F]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id QAA02120
Sender: nsis-admin@ietf.org
Errors-To: nsis-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Next Steps in Signaling <nsis.ietf.org>
X-BeenThere: nsis@ietf.org
Content-Transfer-Encoding: 8bit

Hi All,

> |1. that we should annotate requirements according to which 
> |network environments they are particularly applicable to or 
> |crucial for (e.g. 'scalability is important in the core' and so on)
> 
> I would rather say that the QoS requirements would be derived 
> from different scenarios/use cases and than grouped according to
> the interfaces they apply to.

I agree.  For example, on a small lightweight device, scalability
is very important as well.
  
> |I'm entirely in sympathy with (1) - indeed, that's what I 
> |thought section 6 of the WG draft was trying to do. (More 
> |scenarios and the format might start to be tricky, but that's 
> |another question...)
> 
> Section 6 of the WG draft gives a good overview on the importance 
> of the requirements to the Scenarios 1 - 5, but I would prefer 
> to see which requirements apply to particular interfaces 
> in the Scenarios 1-5.

My feeling is that requirements should be left as requirements,
and we will specify the interfaces in the framework document.
If we need to provide some textual wrapping to help frame the 
requirement, then we should.

For example, what does scalablity mean?  It could mean several
things:

	1) Create minimal state in nodes.
	2) Ability to aggrate traffic.
	3) ... others ...

If we define all of the requirements in terms of existing solutions or
scenarios, I think we will have done the wrong job.

John

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



From daemon@optimus.ietf.org  Thu Feb 28 16:59: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 QAA21917
	for <nsis-archive@odin.ietf.org>; Thu, 28 Feb 2002 16:59:24 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id QAA03517
	for nsis-archive@odin.ietf.org; Thu, 28 Feb 2002 16:59: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 QAA02872;
	Thu, 28 Feb 2002 16:46: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 QAA02844
	for <nsis@optimus.ietf.org>; Thu, 28 Feb 2002 16:46:14 -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 QAA21411
	for <nsis@ietf.org>; Thu, 28 Feb 2002 16:46:10 -0500 (EST)
Received: from irams1.ira.uka.de ([129.13.10.5])
	by iraun2.uka.de with esmtp (Exim 3.30 #7 (Debian))
	id 16gYNQ-00043A-00; Thu, 28 Feb 2002 22:46:12 +0100
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 16gYNQ-0006G1-00; Thu, 28 Feb 2002 22:46:12 +0100
Received: from i72pc127.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 g1SLkBW01565;
	Thu, 28 Feb 2002 22:46:11 +0100
Message-Id: <200202282146.g1SLkBW01565@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: "Vlora Rexhepi (ELN)" <Vlora.Rexhepi@eln.ericsson.se>,
        NSIS Mailing List <nsis@ietf.org>,
        Marcus Brunner <brunner@ccrle.nec.de>
Subject: Re: Definition of QI was: Re: [NSIS] WG requirements draft 
In-Reply-To: Message from Alban.Couturier@alcatel.fr 
   of "Wed, 27 Feb 2002 11:22:37 +0100." <3C7CB36D.DB00E206@alcatel.fr> 
References: <E244E44D6AB85E40AEEF7EAABE3545FAF78454@enleent104.nl.eu.ericsson.se> <3C7BB55E.F088C54F@alcatel.fr> <200202262249.g1QMnoW01222@i72pc127.tm.uka.de>  <3C7CB36D.DB00E206@alcatel.fr> 
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Date: Thu, 28 Feb 2002 22:46:11 +0100
From: Roland Bless <bless@tm.uka.de>
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 <nsis.ietf.org>
X-BeenThere: nsis@ietf.org
Content-Transfer-Encoding: 8bit

Hi Alban,

> Roland, any model works fine, I don't think the current wg draft is not
> generic enough. I remarked there is was a subtle misunderstanding about
> QoS initiator and controller definition.(cf Can the QI be part of the
> interior node?)
> 
> Some people think a QoS controller is a function, and that is your
> opinion. You make a model based on that definition, and it is OK for me
> (I would add QR should be optionnal because the last QC could decide not
> to forward it. This depends of course of the precise definition of QR).

Yes, this makes perfectly sense, and was the itention of my last point
(QC can act as proxy, so that QR is not necessarily present as host). 
My point was that we should avoid things by explicitly mention all 
possible roles at the same time such as QC/QI.


> But with this formalism, you can't say that an RSVP node is a QoS
> initiator and controler: it is only a QoS controller.

Why not? Within the RSVP aggregation scheme an RSVP aggregator will
act as an initiator.
 
> I proposed to say the QoS controller is a role, this allows to say an
> RSVP router is a QoS controler, and initiator at the same time. (by the
> way, this looks like the PDP and PEP definition in COPS, or the
> agent/manager in SNMP. A server can be a PDP, while talking to a router,
> and a PEP, while talking to another server.)
> 
> I invite the authors of the wg draft to fix this misunderstanding.
> Anyway, this has a very little impact (if any) on the work done. 

Clarification would be nice. In my understanding a QI is the entity that
sends the first request message (e.g. setting the start- and endpoint of
the reservation), whereas a QC just does its local admission control
stuff and forwards this request to the next QC on the path (possibly
some QoS parameters need to be changed before). However, the next QC
should not consider the previous QC as original initiator of the
request. Sure, a QC initiates a new signaling transaction and requests 
a new service invocation, but on behalf of the original initiator. 

In my case this lead to an extrem simple signaling protocol 
specification between two adjacent entities (QI<->QC, QC<->QC
or QC<->QR). However, if one considers the complete signaling
transaction along the complete path from end to end (composed 
of the simple point-to-point signaling transactions), the overall
signaling scenario might get quite complex anyway.

Regards,
 Roland

> > > > A question related to the definition of QI:
> > > > The QoS Initiator is located in "the end system or within some
> > > > part of the network, such as the edge router for an access
> > > > network, or even an application layer proxy" and is used to
> > > > communicate with higher layers. What does this mean for any other
> > > > node, e.g. interior node? Can the QI be part of the interior node?
> > >
> > > Marcus said on the list : "In todays RSVP you exactly have one QoS
> > > controller and initiator on each node".
> > > I understand here that the QoS controller receives signaling, while QoS
> > > initiator sends it. If this is true, I would say that the figure 1 of
> > > the WG draft could modified in order to be inline. Instead of :
> > >
> > >
> > >             |         |        ...............
> > >             |         |        . QoS Control .
> > >             V         |        . Information .
> > >        +----------------+      ...............     +----------------+
> > >    --->|                |------------------------->|                |->
> > >        |                |      QoS signalling      |                |
> > >        | QoS Initiator  |     (request/query,      | QoS Controller |
> > >        |                |   response/error etc.)   |                |
> > >    <---|                |<-------------------------|                |<-
> > >        +----------------+                          +----------------+
> > >         ^              |                            ^              |
> > >
> > > I believe we could have:
> > >
> > >
> > >             |         |        ...............
> > >             |         |        . QoS Control .
> > >             V         |        . Information .
> > >        +----------------+      ...............     +----------------+
> > >        |                |------------------------->|QoS        /    |->
> > >        |                |      QoS signalling      |Controller/     |
> > >        | QoS Initiator  |     (request/query,      |         /  QoS |
> > >        |                |   response/error etc.)   |        /initi- |
> > >        |                |<-------------------------|       /  -ator |<-
> > >        +----------------+                          +----------------+
> > >         ^              |                            ^              |
> > >
> > >
> > >
> > >
> > > Vlora, I think that could answer your question (in case of an RSVP
> > > network).
> > >
> > >
> > > To conclude, in order to make things clear, I would propose a small
> > > update of the QoS initiator and controller definition, without changing
> > > its meaning -at least the one I understood-.
> > > I would propose to add at the beginning of the definition for QoS
> > > controller and initiator: "role of an entity responsible for...". The
> > > same entity (an RSVP node) could have both roles.



-- 
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 Feb 28 17:05: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 RAA22257
	for <nsis-archive@odin.ietf.org>; Thu, 28 Feb 2002 17:05:17 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id RAA04562
	for nsis-archive@odin.ietf.org; Thu, 28 Feb 2002 17:05:20 -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 RAA03962;
	Thu, 28 Feb 2002 17:00: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 RAA03930
	for <nsis@optimus.ietf.org>; Thu, 28 Feb 2002 17:00:27 -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 RAA21990
	for <nsis@ietf.org>; Thu, 28 Feb 2002 17:00:18 -0500 (EST)
Received: from irams1.ira.uka.de ([129.13.10.5])
	by iraun2.uka.de with esmtp (Exim 3.30 #7 (Debian))
	id 16gYb6-0004Ex-00; Thu, 28 Feb 2002 23:00:20 +0100
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 16gYb6-0006S6-00; Thu, 28 Feb 2002 23:00:20 +0100
Received: from i72pc127.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 g1SM0KW01661;
	Thu, 28 Feb 2002 23:00:20 +0100
Message-Id: <200202282200.g1SM0KW01661@i72pc127.tm.uka.de>
X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4+dev
To: "Vlora Rexhepi (ELN)" <Vlora.Rexhepi@eln.ericsson.se>
cc: "'Alban.Couturier@alcatel.fr'" <Alban.Couturier@alcatel.fr>,
        NSIS Mailing List <nsis@ietf.org>,
        Marcus Brunner <brunner@ccrle.nec.de>
Subject: Re: Definition of QI was: Re: [NSIS] WG requirements draft 
In-Reply-To: Message from "Vlora Rexhepi (ELN)" <Vlora.Rexhepi@eln.ericsson.se> 
   of "Wed, 27 Feb 2002 11:54:53 +0100." <E244E44D6AB85E40AEEF7EAABE3545FAF7845D@enleent104.nl.eu.ericsson.se> 
References: <E244E44D6AB85E40AEEF7EAABE3545FAF7845D@enleent104.nl.eu.ericsson.se> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 28 Feb 2002 23:00:20 +0100
From: Roland Bless <bless@tm.uka.de>
Sender: nsis-admin@ietf.org
Errors-To: nsis-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Next Steps in Signaling <nsis.ietf.org>
X-BeenThere: nsis@ietf.org

Hi Vlora,

> QoS Initiator and QoS Controller. I believe this is not right. I 
> would rather prefer to define the requirements based on typical 
> scenarios and without relating them to a model nor to a resource
> management scheme.

Requirements based on "typical" scenarios will be fine, but I don't
think it's possible without any sort of (interaction) model. In your
mentioned scenarios some entities are communicating with each other. So
between any two such entities we have some kind of "interface" and
therefore the requirement for a protocol definition for communication
over that interface. But IMHO we always have to name the entities and we
have to know their basic functions. Thus, any scenario is just a concrete
example of such an interaction scenario, isn't it?

> I liked Danny's proposal:
> "
> - Another possibility is to try to identify the basic scenarios, to
> recognise that there are possibly different Qos interfaces (with
> different requirements). For example, i clearly see a difference between
> access QoS and core QoS (interface host - edge and edge -core). In the
> core, we could, as you suggest, identify two approaches (centralised
> /distributed) and try to see how then can interwork."
> 
> And I definitely agree with Georgios.

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 Feb 28 17:21: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 RAA23002
	for <nsis-archive@odin.ietf.org>; Thu, 28 Feb 2002 17:21:19 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id RAA05236
	for nsis-archive@odin.ietf.org; Thu, 28 Feb 2002 17:21: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 RAA04720;
	Thu, 28 Feb 2002 17:08: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 RAA04688
	for <nsis@optimus.ietf.org>; Thu, 28 Feb 2002 17:08:54 -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 RAA22429
	for <nsis@ietf.org>; Thu, 28 Feb 2002 17:08:50 -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.1.0/Switch-2.1.0) with ESMTP id g1SM92Z14623
	for <nsis@ietf.org>; Fri, 1 Mar 2002 00:09:02 +0200 (EET)
Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T595ba08087ac158f24077@esvir04nok.ntc.nokia.com>;
 Fri, 1 Mar 2002 00:08:54 +0200
Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779);
	 Fri, 1 Mar 2002 00:08:52 +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: another requirements question (was: RE: [NSIS] A few comments to draft-fodor-reqts-cellular-netwks-00 .txt)
Date: Fri, 1 Mar 2002 00:08:52 +0200
Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD38D4A@esebe004.NOE.Nokia.com>
Thread-Topic: another requirements question (was: RE: [NSIS] A few comments to draft-fodor-reqts-cellular-netwks-00 .txt)
Thread-Index: AcG/tHdPS08/E7KVSzybeFWM7uQTDQA7o2cQ
To: <robert.hancock@roke.co.uk>, <brian.williams@ericsson.com.au>
Cc: <jmanner@cs.Helsinki.FI>, <Gabor.Fodor@era-t.ericsson.se>, <nsis@ietf.org>
X-OriginalArrivalTime: 28 Feb 2002 22:08:53.0078 (UTC) FILETIME=[81F82F60:01C1C0A4]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id RAA04689
Sender: nsis-admin@ietf.org
Errors-To: nsis-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Next Steps in Signaling <nsis.ietf.org>
X-BeenThere: nsis@ietf.org
Content-Transfer-Encoding: 8bit

Hi Robert,

> Does the NSIS signalling need to be able to convey/negotiate 
> information about which end of a link is going to be 
> responsible for initiating lower layer bearer setup?

One problem with the above requirement might be that the
entity that does that layer 2 bearer setup might not be
visible to the IP layer.

However, we could put some fuzzyness into the requirement,
such as:

 NSIS signaling MAY interact with layer 2 entities for 
 setting layer 2 resources.

Or something like that.

John

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



From daemon@optimus.ietf.org  Thu Feb 28 18:13: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 SAA25360
	for <nsis-archive@odin.ietf.org>; Thu, 28 Feb 2002 18:13:56 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id SAA08810
	for nsis-archive@odin.ietf.org; Thu, 28 Feb 2002 18:13:59 -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 SAA08656;
	Thu, 28 Feb 2002 18:09: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 SAA08625
	for <nsis@optimus.ietf.org>; Thu, 28 Feb 2002 18:09:28 -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 SAA25200
	for <nsis@ietf.org>; Thu, 28 Feb 2002 18:09:23 -0500 (EST)
Received: from irams1.ira.uka.de ([129.13.10.5])
	by iraun2.uka.de with esmtp (Exim 3.30 #7 (Debian))
	id 16gZfz-00052x-00
	for <nsis@ietf.org>; Fri, 01 Mar 2002 00:09:27 +0100
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 16gZfz-0007Tj-00
	for <nsis@ietf.org>; Fri, 01 Mar 2002 00:09:27 +0100
Received: from i72pc127.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 g1SN9QW02525
	for <nsis@ietf.org>; Fri, 1 Mar 2002 00:09:26 +0100
Message-Id: <200202282309.g1SN9QW02525@i72pc127.tm.uka.de>
X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4+dev
To: nsis@ietf.org
In-Reply-To: Message from john.loughney@nokia.com 
   of "Wed, 27 Feb 2002 14:48:00 +0200." <0C1353ABB1DEB74DB067ADFF749C4EEFD38D46@esebe004.NOE.Nokia.com> 
References: <0C1353ABB1DEB74DB067ADFF749C4EEFD38D46@esebe004.NOE.Nokia.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 01 Mar 2002 00:09:26 +0100
From: Roland Bless <bless@tm.uka.de>
Subject: [NSIS] Automatic Discovery of QCs
Sender: nsis-admin@ietf.org
Errors-To: nsis-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Next Steps in Signaling <nsis.ietf.org>
X-BeenThere: nsis@ietf.org

Hi,

John Loughney wrote:

> Finally, I would suggest that everyone try to comment directly on 
> the draft - add text, delete text, etc. rather then having 
> gerneralized concerns.

I would add another point to section 5.3 of draft-ietf-nsis-req-00:
5.3.8 Automatic discovery of QoS Controllers.
      This will allow some degree of auto configuration which can
      be useful in many scenarios. For instance, hosts (especially 
      mobile ones) will be able to find out the next adjacent QCs.      

In a conrete implementation, several multicast groups of different
scopes can be used to send QC "advertisements" periodically. 
Additionally, hosts should be able to send discovery requests to 
a multicast group, triggering immediate individual responses from 
adjacent QCs. Further example uses are: distribution of status
(e.g., active/stand-by QCs) or pricing information.

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 Feb 28 21:00: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 VAA29078
	for <nsis-archive@odin.ietf.org>; Thu, 28 Feb 2002 21:00:39 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id VAA16695
	for nsis-archive@odin.ietf.org; Thu, 28 Feb 2002 21:00:42 -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 UAA15897;
	Thu, 28 Feb 2002 20:47: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 UAA15823
	for <nsis@optimus.ietf.org>; Thu, 28 Feb 2002 20:47:47 -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 UAA28856
	for <nsis@ietf.org>; Thu, 28 Feb 2002 20:47:43 -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 RAA01209;
	Thu, 28 Feb 2002 17:47:15 -0800 (PST)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g211lE121938;
	Thu, 28 Feb 2002 17:47:14 -0800
X-mProtect:  Thu, 28 Feb 2002 17:47:14 -0800 Nokia Silicon Valley Messaging Protection
Received: from mvdhcp141150.americas.nokia.com (172.18.141.150, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com smtpdx59YNx; Thu, 28 Feb 2002 17:47:12 PST
Message-ID: <3C7EDD9A.1010609@iprg.nokia.com>
Date: Thu, 28 Feb 2002 17:47:06 -0800
From: Cedric Westphal <cedric@iprg.nokia.com>
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: "Vlora Rexhepi (ELN)" <Vlora.Rexhepi@eln.ericsson.se>
CC: "'brunner@ccrle.nec.de'" <brunner@ccrle.nec.de>,
        "Georgios Karagiannis (ELN)" <Georgios.Karagiannis@eln.ericsson.se>,
        "'john.loughney@nokia.com'" <john.loughney@nokia.com>, nsis@ietf.org
Subject: Re: [NSIS] Re: Modularity and grouping QoS requirements
References: <E244E44D6AB85E40AEEF7EAABE3545FAF78460@enleent104.nl.eu.ericsson.se>
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 <nsis.ietf.org>
X-BeenThere: nsis@ietf.org
Content-Transfer-Encoding: 7bit

Vlora and all,

one reason for using the model in draft-nsis rather than the one in
draft-partain is that it allows to define mobility requirements.
For instance, think of a handoff, where the previous access router (PAR)
transfers QoS context to the new access router (NAR).
There is no NAR-PAR interface in draft-partain; however, it is easy
to see that the NAR is a QC (making the CAC decision at least) for
the new path, and PAR a QI.

Another drawback of the 'interface' framework is that QoS signaling is
not necessary limited to interfaces. For instance, to update some 
reservation
after a handoff, you'd need to signal to the crossover router(s), 
wherever it
is. Most likely this crossover router does not correspond to any interface.
Note that draft-nsis either does not provide such framework, but it could
easily (should) be added with a QoS Termination point abstraction. I think
it is a dead end to assume the starting point and the end point of the 
QoS signaling to
be some pre-defined interface. Draft-nsis goes a half step in the right
direction by allowing the starting point to be anywhere and abstracting 
it into
the QI, which is a better starting point.

Cheers,

Cedric.


Vlora Rexhepi (ELN) wrote:

>Hi Marcus,
>
>|I am open to the consensus of the WG. Just some remarks inline.
>Great.
>
>|> One of the outcomes of the NSIS meeting in Salt Lake City was
>|> to start working on defining QoS requirements based on 
>|scenario cases.
>|>
>|> Furthermore, we all agreed that modularity is very important;
>|> During that meeting many people agreed that after the QoS 
>|requirements
>|> are defined, then they will be grouped according to network
>|> interfaces (e.g., UNI (access), NNI (backbone));
>|
>|Here you have at least 4 types (UNI with home network, UNI 
>|with foreign 
>|network, NNI within same administrative domain, NNI across 
>|admin domains.
>
>In draft-partain-nsis-requirements-00.txt there are three types
>of interfaces identified:
>- interior <-> interior interface
>- border node <-> border node interface
>- host <-> border node interface
>Please see the draft for detailed info.
>
>
>|> A reasonable way of doing the above, is in my opinion the following:
>|> * First define the scenario cases;
>|Agreed
>Great. 
>
>
>|> * Second using these scenario cases, define which QoS 
>|requirements will
>|> have     to be satisfied on each network interface, and on 
>|each network
>|> node type, e.g.,    host, access router, interior router, 
>|border router,
>|> edge router, proxy, bandwidth broker, ...
>|
>|We can still do it my concern is that we have then with N scenarios (N 
>|currently 5 to be more) and M interfaces (M as mentioned above 
>|=4) and L 
>|node types (L=7 in your proposal)
>|
>|This implies NxMxL entities we have to define requirements 
>|for. And this I 
>|am definitly not willing to do.
>Understandable. No one is suggesting to have more entities than
>the number of typical network nodes known in the Internet
>community. 
>What, Georgios is suggesting is that the [NSIS] WG derives requirements
>from the scenarios and group them into particular interfaces between 
>different nodes they apply to.  This is already done in
>draft-partain-nsis-requirements-00.txt. 
>Based on this, the QoS model entities would be defined later. 
>
>
>|> Third the outcome of this
>|> separation of QoS requirements it will result in    an 
>|efficient grouping
>|> of the QoS requirements.
>|
>|We can discuss the grouping (I was just to lazy to change it so far)
>I already mentioned above one possible way to do it :-). 
>
>
>|> After the QOS requirements grouping is done, then we could 
>|define a QoS
>|> model. This QoS model could have entities such as a QoS 
>|initiator and a
>|> QoS controller.
>|
>|Yes, that is what the framework document does.
>Exactly. The framework should be a result of scenarios and the 
>requirements derived from them. As it is now in the [NSIS] WG 
>draft the things are done in a different order. And as we could 
>see it the "problem discussion model" has a problem when one wants
>to apply it in other scenarios rather than the ones described in 
>the [NSIS] WG draft.
>
>
>|> The problem I have with the NSIS WG requirements draft is that these
>|> sequence of doing things is very much opposite to the 
>|sequence mentioned
>|> above. In the NSIS WG requirements draft the following sequence of
>|> actions is followed:
>|
>|> First a QoS model and its QoS model entities are
>|> defined. At this stage, these    QoS model entities, e.g., 
>|QoS initiator
>|> and QoS controller, are not representing network entities.
>|
>|This is the second step in the draft and it is ment to reduce the node 
>|types.
>Yes, but it does also impact the QoS requirements. 
>
>
>|I understand that some people have problems to see the value 
>|of it, others 
>|very much appreciated the more abstract way of thinking. I 
>|would say it is 
>|50:50 so far.
>|
>|And some even think we should get more abstract
>|
>|>  * Second, the QoS requirements are grouped according to 
>|these QoS  model
>|> entities     and not grouped according to any network 
>|interface or any
>|> network node type!
>|
>|No they are grouped into topics like security, flow definition, 
>|architectural, etc. The grouping actually as nothing to do 
>|with the model
>Right. But, I think the grouping should be done based on the 
>agreement in the meeting at Salt Lake City.  
>
>|>*Third, the QoS model entites are assigned to
>|> specific network node types. In my opinion    this  step is 
>|difficult to
>|> be accomplished and for some scenarios is impossible to be done.
>|
>|You might be right, but we have done it so far. Currently I do 
>|not see it 
>|as too difficult, but I might be wrong.
>We already heard from Danny that in their scenarios it was not 
>an "easy exercise"...
>So, could someone (other than the authors) please try to relate 
>one of the Scenarios from draft-partain-nsis-requirements-00.txt
>with "Problem Discussion Model" from the [NSIS] WG draft such that
>we can close the discussion on the generality of the model? That 
>would be appreciated very much.
>
>Regards,
>Vlora  
>
>
>
>
>_______________________________________________
>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