From daemon@optimus.ietf.org  Wed Jan  9 22:19: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 WAA27227
	for <nsis-archive@odin.ietf.org>; Wed, 9 Jan 2002 22:19:37 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id WAA00456
	for nsis-archive@odin.ietf.org; Wed, 9 Jan 2002 22:19: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 WAA00426;
	Wed, 9 Jan 2002 22:18:42 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA00390
	for <nsis@optimus.ietf.org>; Wed, 9 Jan 2002 22:18:40 -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 WAA27218
	for <nsis@ietf.org>; Wed, 9 Jan 2002 22:18:35 -0500 (EST)
From: Zhigang.Kan@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 g0A3Ick19575
	for <nsis@ietf.org>; Thu, 10 Jan 2002 05:18:39 +0200 (EET)
Received: from esebh01nok.ntc.nokia.com (unverified) by esvir01nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T585b3e137fac158f21083@esvir01nok.ntc.nokia.com> for <nsis@ietf.org>;
 Thu, 10 Jan 2002 05:18:36 +0200
Received: by esebh01nok with Internet Mail Service (5.5.2652.78)
	id <CHNT5FQZ>; Thu, 10 Jan 2002 05:18:36 +0200
Message-ID: <4AE1AC3D692F55488F2D03518907B8AD0411A8@beebe001.NOE.Nokia.com>
To: nsis@ietf.org
Date: Thu, 10 Jan 2002 05:17:27 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
content-class: urn:content-classes:message
Content-Type: text/plain;
	charset="ISO-8859-1"
Subject: [NSIS] Why do not I receive any mail?
Sender: nsis-admin@ietf.org
Errors-To: nsis-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Next Steps in Signaling <nsis.ietf.org>
X-BeenThere: nsis@ietf.org

Hi,

Is there any mail in the nsis group these days? I am a newer to nsis. I
want to know whether or not my mail box works.
BR/Kan Zhigang

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



From daemon@optimus.ietf.org  Wed Jan  9 23:23: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 XAA29319
	for <nsis-archive@odin.ietf.org>; Wed, 9 Jan 2002 23:23:01 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id XAA02147
	for nsis-archive@odin.ietf.org; Wed, 9 Jan 2002 23:23: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 XAA02128;
	Wed, 9 Jan 2002 23:22: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 XAA02097
	for <nsis@optimus.ietf.org>; Wed, 9 Jan 2002 23:22:16 -0500 (EST)
Received: from inet11.jrc.co.jp (inet11.jrc.co.jp [203.180.124.3])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29271
	for <nsis@ietf.org>; Wed, 9 Jan 2002 23:22:11 -0500 (EST)
Received: from gate1 by inet11.jrc.co.jp (8.9.3/3.7W)
	id NAA25392; Thu, 10 Jan 2002 13:22:08 +0900 (JST)
Received: from jrcgw1 ([10.8.1.31]) by gate1.noc.jrc.co.jp; Thu, 10 Jan 2002 13:21:54 +0000 (JST)
Received: from labgw1.lab.jrc.co.jp by jrcgw1.noc.jrc.co.jp (8.9.3/3.7WSaTaMa99081014)
	id NAA27539; Thu, 10 Jan 2002 13:21:53 +0900 (JST)
Received: from sakai.Network_lab (sakai [10.38.58.12])
	by labgw1.lab.jrc.co.jp (8.9.3+3.2W/3.7W-labgw1) with ESMTP id NAA08541;
	Thu, 10 Jan 2002 13:21:50 +0900 (JST)
Date: Thu, 10 Jan 2002 13:20:50 +0900
From: Yutaka SAKAI <sakai@lab.jrc.co.jp>
To: Zhigang.Kan@nokia.com
Cc: nsis@ietf.org
In-Reply-To: <4AE1AC3D692F55488F2D03518907B8AD0411A8@beebe001.NOE.Nokia.com>
References: <4AE1AC3D692F55488F2D03518907B8AD0411A8@beebe001.NOE.Nokia.com>
Message-Id: <20020110131003.7EF9.SAKAI@lab.jrc.co.jp>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Becky! ver. 2.00.08
Content-Transfer-Encoding: 7bit
Subject: [NSIS] Discussion Archive
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

Don't worry about it. Go to
http://www.ietf.org/mail-archive/working-groups/nsis/current/maillist.html

yutaka


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



From daemon@optimus.ietf.org  Thu Jan 10 11:43: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 LAA18610
	for <nsis-archive@odin.ietf.org>; Thu, 10 Jan 2002 11:43:30 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id LAA03943
	for nsis-archive@odin.ietf.org; Thu, 10 Jan 2002 11:43: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 LAA03595;
	Thu, 10 Jan 2002 11:35: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 LAA03567
	for <nsis@optimus.ietf.org>; Thu, 10 Jan 2002 11:35:36 -0500 (EST)
Received: from wells.cisco.com (wells.cisco.com [171.71.177.223])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18395
	for <nsis@ietf.org>; Thu, 10 Jan 2002 11:35:33 -0500 (EST)
Received: from JMPOLK-W2K (ssh-sj1.cisco.com [171.68.225.134]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id IAA29238 for <nsis@ietf.org>; Thu, 10 Jan 2002 08:35:04 -0800 (PST)
Message-Id: <4.1.20020110103346.02c90b48@localhost>
X-Sender: jmpolk@localhost
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Thu, 10 Jan 2002 10:34:46 -0600
To: nsis@ietf.org
From: "James M. Polk" <jmpolk@cisco.com>
Subject: Re: [NSIS] Why do not I receive any mail?
In-Reply-To: <4AE1AC3D692F55488F2D03518907B8AD0411A8@beebe001.NOE.Nokia.
 com>
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="=====================_67644557==_.ALT"
Sender: nsis-admin@ietf.org
Errors-To: nsis-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Next Steps in Signaling <nsis.ietf.org>
X-BeenThere: nsis@ietf.org

--=====================_67644557==_.ALT
Content-Type: text/plain; charset="us-ascii"


I didn't receive any email from this list either from 12/23 to 1/10 (21 days)
-- and that seams odd to me as well....

At 05:17 AM 1/10/2002 +0200, Zhigang.Kan@nokia.com wrote:
>Hi,
>
>Is there any mail in the nsis group these days? I am a newer to nsis. I
>want to know whether or not my mail box works.
>BR/Kan Zhigang
>
>_______________________________________________
>nsis mailing list
>nsis@ietf.org
>https://www1.ietf.org/mailman/listinfo/nsis

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

James M. Polk
Consulting Engineer
Office of the CTO

Cisco Systems
2200 East President George Bush Turnpike 
Richardson, TX  75082 USA
w) 972.813.5208
f)  972.813.5280
www.cisco.com
--=====================_67644557==_.ALT
Content-Type: text/html; charset="us-ascii"

<html><div>I didn't receive any email from this list either from 12/23 to
1/10 (21 days) -- and that seams odd to me as well....</div>
<br>
<div>At 05:17 AM 1/10/2002 +0200, Zhigang.Kan@nokia.com wrote:</div>
<div>&gt;Hi,</div>
<div>&gt;</div>
<div>&gt;Is there any mail in the nsis group these days? I am a newer to
nsis. I</div>
<div>&gt;want to know whether or not my mail box works.</div>
<div>&gt;BR/Kan Zhigang</div>
<div>&gt;</div>
<div>&gt;_______________________________________________</div>
<div>&gt;nsis mailing list</div>
<div>&gt;nsis@ietf.org</div>
<div>&gt;<a href="https://www1.ietf.org/mailman/listinfo/nsis" EUDORA=AUTOURL>https://www1.ietf.org/mailman/listinfo/nsis</a></div>
<br>

<div align="center">
*************************************<br>
&quot;People generally demand more respect for their own rights than they
are willing to allow for others&quot;<br>
<br>
</div>
James M. Polk<br>
Consulting Engineer<br>
Office of the CTO<br>
<br>
Cisco Systems<br>
2200 East President George Bush Turnpike <br>
Richardson, TX&nbsp; 75082 USA<br>
w) 972.813.5208<br>
f)&nbsp; 972.813.5280<br>
<a href="http://www.cisco.com/" eudora="autourl">www.cisco.com</a></html>

--=====================_67644557==_.ALT--


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



From daemon@optimus.ietf.org  Thu Jan 10 12:36: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 MAA19859
	for <nsis-archive@odin.ietf.org>; Thu, 10 Jan 2002 12:36:10 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id MAA07321
	for nsis-archive@odin.ietf.org; Thu, 10 Jan 2002 12:36: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 MAA06585;
	Thu, 10 Jan 2002 12: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 MAA06553
	for <nsis@optimus.ietf.org>; Thu, 10 Jan 2002 12:23:49 -0500 (EST)
Received: from wells.cisco.com (wells.cisco.com [171.71.177.223])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19679
	for <nsis@ietf.org>; Thu, 10 Jan 2002 12:23:46 -0500 (EST)
Received: from JMPOLK-W2K (ssh-sj1.cisco.com [171.68.225.134]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id JAA19942; Thu, 10 Jan 2002 09:23:13 -0800 (PST)
Message-Id: <4.1.20020110112122.02c90000@localhost>
X-Sender: jmpolk@localhost
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Thu, 10 Jan 2002 11:22:55 -0600
To: Yutaka SAKAI <sakai@lab.jrc.co.jp>, Zhigang.Kan@nokia.com
From: "James M. Polk" <jmpolk@cisco.com>
Subject: Re: [NSIS] Discussion Archive
Cc: nsis@ietf.org
In-Reply-To: <20020110131003.7EF9.SAKAI@lab.jrc.co.jp>
References: <4AE1AC3D692F55488F2D03518907B8AD0411A8@beebe001.NOE.Nokia.com>
 <4AE1AC3D692F55488F2D03518907B8AD0411A8@beebe001.NOE.Nokia.com>
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="=====================_70533501==_.ALT"
Sender: nsis-admin@ietf.org
Errors-To: nsis-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Next Steps in Signaling <nsis.ietf.org>
X-BeenThere: nsis@ietf.org

--=====================_70533501==_.ALT
Content-Type: text/plain; charset="us-ascii"


At 01:20 PM 1/10/2002 +0900, Yutaka SAKAI wrote:
>Don't worry about it. Go to
>http://www.ietf.org/mail-archive/working-groups/nsis/current/maillist.html

This shows the same 21 day gap between messages.... curious.... however, likely
accurate

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

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

James M. Polk
Consulting Engineer
Office of the CTO

Cisco Systems
2200 East President George Bush Turnpike 
Richardson, TX  75082 USA
w) 972.813.5208
f)  972.813.5280
www.cisco.com
--=====================_70533501==_.ALT
Content-Type: text/html; charset="us-ascii"

<html><div>At 01:20 PM 1/10/2002 +0900, Yutaka SAKAI wrote:</div>
<div>&gt;Don't worry about it. Go to</div>
<div>&gt;<a href="http://www.ietf.org/mail-archive/working-groups/nsis/current/maillist.html" EUDORA=AUTOURL>http://www.ietf.org/mail-archive/working-groups/nsis/current/maillist.html</a></div>
<br>
<div>This shows the same 21 day gap between messages.... curious....
however, likely accurate</div>
<br>
<div>&gt;</div>
<div>&gt;yutaka</div>
<div>&gt;</div>
<div>&gt;</div>
<div>&gt;_______________________________________________</div>
<div>&gt;nsis mailing list</div>
<div>&gt;nsis@ietf.org</div>
<div>&gt;<a href="https://www1.ietf.org/mailman/listinfo/nsis" EUDORA=AUTOURL>https://www1.ietf.org/mailman/listinfo/nsis</a></div>
<br>

<div align="center">
*************************************<br>
&quot;People generally demand more respect for their own rights than they
are willing to allow for others&quot;<br>
<br>
</div>
James M. Polk<br>
Consulting Engineer<br>
Office of the CTO<br>
<br>
Cisco Systems<br>
2200 East President George Bush Turnpike <br>
Richardson, TX&nbsp; 75082 USA<br>
w) 972.813.5208<br>
f)&nbsp; 972.813.5280<br>
<a href="http://www.cisco.com/" eudora="autourl">www.cisco.com</a></html>

--=====================_70533501==_.ALT--


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



From daemon@optimus.ietf.org  Thu Jan 10 20:57:31 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27610
	for <nsis-archive@odin.ietf.org>; Thu, 10 Jan 2002 20:57:31 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id UAA23220
	for nsis-archive@odin.ietf.org; Thu, 10 Jan 2002 20:57:33 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA23158;
	Thu, 10 Jan 2002 20:53: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 UAA23122
	for <nsis@optimus.ietf.org>; Thu, 10 Jan 2002 20:53:11 -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 UAA27571
	for <nsis@ietf.org>; Thu, 10 Jan 2002 20:53:08 -0500 (EST)
From: Zhigang.Kan@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 g0B1rCk23516
	for <nsis@ietf.org>; Fri, 11 Jan 2002 03:53:12 +0200 (EET)
Received: from esebh01nok.ntc.nokia.com (unverified) by esvir01nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T5860162dc0ac158f21083@esvir01nok.ntc.nokia.com> for <nsis@ietf.org>;
 Fri, 11 Jan 2002 03:53:08 +0200
Received: by esebh01nok with Internet Mail Service (5.5.2652.78)
	id <CHNT0YZB>; Fri, 11 Jan 2002 03:53:08 +0200
Message-ID: <4AE1AC3D692F55488F2D03518907B8AD07E33D@beebe001.NOE.Nokia.com>
To: nsis@ietf.org
Date: Fri, 11 Jan 2002 03:49:37 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
content-class: urn:content-classes:message
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 UAA23123
Subject: [NSIS] About QoS singaling for Mobile IP
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,

The following alternatives could be a basis of a solution for QoS
signaling for Mobile IP According to [BCS99]:

*	A new special signaling protocol.
*	Special Mobile IP protocol options to be exchanged between MN /
default router / QoS Agents.
*	Mobile nodes could request reservations via RSVP. These
reservations can be accepted or rejected by some local router dependent
on whether the SLA of the foreign network is sufficient or not. For this
scenario, the concepts developed by the RSVP Admission and Policy work
group of the IETF can be applied. A problem with RSVP might be that RSVP
is able to support receiver-driven reservations only. Probably for
sender-driven reservations, RSVP needs to be modified slightly.
*	Layer-4-Switching concepts or other signaling protocols: Another
approach could be to avoid explicit signaling support for requesting a
service and to try to identify flows which shall get a DiffServ service.
Those flows could be H.323 flows, HTTP flows or any other long-lived or
high-volume traffic flows. Such a flow identification functionality
could be installed at a mobility agent or first-hop-router. The task of
such a router is to identify flows, assign DiffServ Codepoints (DSCPs)
and request the establishment / modification of a SLA at the nearest QoS
Agent or directly at the ISP. This concept is similar to the MF
classification concept.
Binding Update, Binding Acknowledge, Binding Request are defined in the
[MobileIPv6]. They are used for  mobility management of the MN. Based on
the mechanisms of these signalings, we prefer to the second alternative
listed above. We defined some special Mobile IPv6 protocol options to
extend the existing signalings for advance resource reservation and QoS
negotiation which allows a MN to indicate the kind of desired service.
The procedures of QoS negotiation are given when MN is a sender or a
receiver too. 
The main advantage of our idea is as follows:
*	Extending the existing signalings defined in Mobile IPv6 base
protocol;
*	QoS negotation and movement management of MN occurs
simultaneously, so the overhead on network is reduced;
*	Easy implementation.
[BCS99] Braun, Castelluccia, and Stattenberger: An Analysis of the
DiffServ Approach in Mobile Environments, IWQiM´99

Comments and suggestons are welcome!
BR/Kan Zhigang

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



From daemon@optimus.ietf.org  Fri Jan 11 15:00:29 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27601
	for <nsis-archive@odin.ietf.org>; Fri, 11 Jan 2002 15:00:28 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id PAA13949
	for nsis-archive@odin.ietf.org; Fri, 11 Jan 2002 15:00: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 OAA13617;
	Fri, 11 Jan 2002 14:56: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 OAA13582
	for <nsis@optimus.ietf.org>; Fri, 11 Jan 2002 14:56:11 -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 OAA27412
	for <nsis@ietf.org>; Fri, 11 Jan 2002 14:56:07 -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 g0BJuCk22974
	for <nsis@ietf.org>; Fri, 11 Jan 2002 21:56:12 +0200 (EET)
Received: from esebh02nok.ntc.nokia.com (unverified) by esvir01nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T5863f5b0ebac158f21083@esvir01nok.ntc.nokia.com> for <nsis@ietf.org>;
 Fri, 11 Jan 2002 21:56:08 +0200
Received: by esebh02nok with Internet Mail Service (5.5.2652.78)
	id <CT3G90JX>; Fri, 11 Jan 2002 21:56:08 +0200
Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFA21EF1@esebe004.NOE.Nokia.com>
To: nsis@ietf.org
Date: Fri, 11 Jan 2002 21:55:59 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
content-class: urn:content-classes:message
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [NSIS] Next Steps
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'm currently on an extended Christmas vacation, I will return next
week.
For the next steps, I think some discussion on requirement would be
good.  
My feeling is that we should be very strict on what is a requirement.
Anything that is not absolutely necessary is not a requirement.  We
should
look at the individual drafts that have been submitted & strip out
all the requirements that are 'nice to have, but ...' type things.

When I get back to work, I will try to arrange some conference call
times
so that we can get to work in creating a working group document.

However, feel free to discuss the requirements already.

best regards,
John

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



From daemon@optimus.ietf.org  Fri Jan 11 16:33: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 QAA00312
	for <nsis-archive@odin.ietf.org>; Fri, 11 Jan 2002 16:33:09 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id QAA17317
	for nsis-archive@odin.ietf.org; Fri, 11 Jan 2002 16:33: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 QAA16731;
	Fri, 11 Jan 2002 16:29: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 QAA16698
	for <nsis@optimus.ietf.org>; Fri, 11 Jan 2002 16:29:01 -0500 (EST)
Received: from cmail.packetcom.com ([63.108.173.139])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00209
	for <nsis@ietf.org>; Fri, 11 Jan 2002 16:28:58 -0500 (EST)
Received: from caspiannetworks.com ([192.168.5.202])
	by cmail.packetcom.com (Mirapoint)
	with ESMTP id ABQ21981 (AUTH tso@caspiannetworks.com);
	Fri, 11 Jan 2002 13:28:29 -0800 (PST)
Message-ID: <3C3F531A.CC930000@caspiannetworks.com>
Date: Fri, 11 Jan 2002 13:03:22 -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
Subject: Re: [NSIS] Next Steps
References: <0C1353ABB1DEB74DB067ADFF749C4EEF5D935F@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

Oops!! Certainly.  I thought I have replytoall.

Thanks John.

john.loughney@nokia.com wrote:

> Hi Tricci,
>
> > I still believe that it is important to discuss and agree on
> > the scope of the work within the WG, if it is not before, it should
> > be at the same time when discussing the requirements.
>
> Please bring this up on the list, especially with regards to
> what you believe the scope should be.
>
> thanks,
> John


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



From daemon@optimus.ietf.org  Mon Jan 14 05:21: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 FAA00795
	for <nsis-archive@odin.ietf.org>; Mon, 14 Jan 2002 05:21:33 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id FAA01277
	for nsis-archive@odin.ietf.org; Mon, 14 Jan 2002 05:21: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 FAA00982;
	Mon, 14 Jan 2002 05:05: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 FAA00951
	for <nsis@optimus.ietf.org>; Mon, 14 Jan 2002 05:05:12 -0500 (EST)
Received: from cbibipnt05.hc.bt.com (saturn.bt.com [193.113.57.20])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00607
	for <nsis@ietf.org>; Mon, 14 Jan 2002 05:05:08 -0500 (EST)
From: dick.rr.knight@bt.com
Received: by cbibipnt05.hc.bt.com with Internet Mail Service (5.5.2652.35)
	id <CRM79G00>; Mon, 14 Jan 2002 10:04:34 -0000
Message-ID: <451D45016C2CD2119DA50000F8FE7F07080E5A18@mlngcbnt01.hc.bt.com>
To: john.loughney@nokia.com, nsis@ietf.org
Subject: RE: [NSIS] Next Steps
Date: Mon, 14 Jan 2002 10:04:07 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
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

I think we should be discussing both scope and requirements. It was clear
from the Salt Lake City meeting that the AD's believe that the two are
connected.

Regards,

Dick Knight

This electronic message contains information from British Telecommunications
plc which may be privileged or confidential. The information is intended to
be for the use of the individual(s) or entity named above. If you are not
the intended recipient be aware that any disclosure, copying, distribution
or use of the contents of this information is prohibited. If you have
received this electronic message in error, please notify us by telephone or
email (to the numbers or address above) immediately.


-----Original Message-----
From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]
Sent: 11 January 2002 19:56
To: nsis@ietf.org
Subject: [NSIS] Next Steps


Hi all,

I'm currently on an extended Christmas vacation, I will return next
week.
For the next steps, I think some discussion on requirement would be
good.  
My feeling is that we should be very strict on what is a requirement.
Anything that is not absolutely necessary is not a requirement.  We
should
look at the individual drafts that have been submitted & strip out
all the requirements that are 'nice to have, but ...' type things.

When I get back to work, I will try to arrange some conference call
times
so that we can get to work in creating a working group document.

However, feel free to discuss the requirements already.

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 Jan 15 14:46: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 OAA11174
	for <nsis-archive@odin.ietf.org>; Tue, 15 Jan 2002 14:46:36 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id OAA20069
	for nsis-archive@odin.ietf.org; Tue, 15 Jan 2002 14:46: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 OAA19904;
	Tue, 15 Jan 2002 14:40: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 OAA19877
	for <nsis@optimus.ietf.org>; Tue, 15 Jan 2002 14:40:43 -0500 (EST)
Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10954
	for <nsis@ietf.org>; Tue, 15 Jan 2002 14:40:40 -0500 (EST)
Received: from zrchb200.us.nortel.com (zrchb200.us.nortel.com [47.103.121.45])
	by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g0FJeBh04513
	for <nsis@ietf.org>; Tue, 15 Jan 2002 13:40:11 -0600 (CST)
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <CK6Q4HPP>; Tue, 15 Jan 2002 13:40:11 -0600
Message-ID: <933FADF5E673D411B8A30002A5608A0E017CF1A3@zrc2c012.us.nortel.com>
From: "Glenn Morrow"<gmorrow@nortelnetworks.com>
To: nsis@ietf.org
Date: Tue, 15 Jan 2002 13:40:02 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C19DFC.6C952E40"
Subject: [NSIS] NSIS 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

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_01C19DFC.6C952E40
Content-Type: text/plain;
	charset="iso-8859-1"

Hello all,

I have recently read the following draft:

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

and I can find little wrong with it. In my opinion it addresses every facet
that needs to be handled by this WG. It seems to have done this in a very
concise and "to the point" manner.
I must say I could not have done a better job myself.

I suggest that this draft be taken as the base WG requirement document. 

What are the opinions of others?

Thank You,

Glenn

------_=_NextPart_001_01C19DFC.6C952E40
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>NSIS Requirements Draft</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Hello all,</FONT>
</P>

<P><FONT SIZE=3D2>I have recently read the following draft:</FONT>
</P>

<P><FONT SIZE=3D2><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>
</P>

<P><FONT SIZE=3D2>and I can find little wrong with it. In my opinion it =
addresses every facet that needs to be handled by this WG. It seems to =
have done this in a very concise and &quot;to the point&quot; =
manner.</FONT></P>

<P><FONT SIZE=3D2>I must say I could not have done a better job =
myself.</FONT>
</P>

<P><FONT SIZE=3D2>I suggest that this draft be taken as the base WG =
requirement document. </FONT>
</P>

<P><FONT SIZE=3D2>What are the opinions of others?</FONT>
</P>

<P><FONT SIZE=3D2>Thank You,</FONT>
</P>

<P><FONT SIZE=3D2>Glenn</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C19DFC.6C952E40--

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



From daemon@optimus.ietf.org  Wed Jan 16 06:45:41 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04258
	for <nsis-archive@odin.ietf.org>; Wed, 16 Jan 2002 06:45:41 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id GAA27274
	for nsis-archive@odin.ietf.org; Wed, 16 Jan 2002 06:45:43 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA27081;
	Wed, 16 Jan 2002 06:32:00 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA27052
	for <nsis@optimus.ietf.org>; Wed, 16 Jan 2002 06:31: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 GAA04153
	for <nsis@ietf.org>; Wed, 16 Jan 2002 06:31:55 -0500 (EST)
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 g0GBVr910078
	for <nsis@ietf.org>; Wed, 16 Jan 2002 13:31:53 +0200 (EET)
Received: from esebh002.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T587be7d1c4ac158f22078@esvir02nok.ntc.nokia.com>;
 Wed, 16 Jan 2002 13:31:52 +0200
Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779);
	 Wed, 16 Jan 2002 13:31:51 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
content-class: urn:content-classes:message
Subject: RE: [NSIS] Next Steps
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Date: Wed, 16 Jan 2002 13:31:51 +0200
Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF5D9368@esebe004.NOE.Nokia.com>
Thread-Topic: [NSIS] Next Steps
Thread-Index: AcGc4tjNeZFGtwjVEdaJYAAIx6TWpQBnlsWA
From: "Loughney John (NRC/Helsinki)" <john.loughney@nokia.com>
To: <dick.rr.knight@bt.com>, <nsis@ietf.org>
X-OriginalArrivalTime: 16 Jan 2002 11:31:52.0061 (UTC) FILETIME=[64B492D0:01C19E81]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id GAA27053
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 Dick,

> I think we should be discussing both scope and requirements. 
> It was clear from the Salt Lake City meeting that the AD's believe 
> that the two are connected.

This I think should be involved in the discussion of the requirements.
Meaning, if a requirement is out of scope of the working group, we
should not include it.  However, please speak up if you have comments
on either the requirements or scope.

thanks,
John

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



From daemon@optimus.ietf.org  Wed Jan 16 07:03: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 HAA04808
	for <nsis-archive@odin.ietf.org>; Wed, 16 Jan 2002 07:03:32 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id HAA27954
	for nsis-archive@odin.ietf.org; Wed, 16 Jan 2002 07:03: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 HAA27887;
	Wed, 16 Jan 2002 07:02: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 HAA27852
	for <nsis@optimus.ietf.org>; Wed, 16 Jan 2002 07:02:34 -0500 (EST)
Received: from cbibipnt08.hc.bt.com (saturn.bt.com [193.113.57.20])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04639
	for <nsis@ietf.org>; Wed, 16 Jan 2002 07:02:31 -0500 (EST)
From: dick.rr.knight@bt.com
Received: by cbibipnt08.hc.bt.com with Internet Mail Service (5.5.2654.89)
	id <DA1WR5RW>; Wed, 16 Jan 2002 12:00:10 -0000
Message-ID: <451D45016C2CD2119DA50000F8FE7F07080E5A2E@mlngcbnt01.hc.bt.com>
To: brian.williams@ericsson.com.au, lieve.bos@alcatel.be
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements
Date: Wed, 16 Jan 2002 11:59:38 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2654.89)
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

I was waiting for some reaction to Brian's comments, but as there aren't
any, here are my thoughts on the requirements:

I agree with the analysis that discussion has been based around
application-related signalling for QoS (at session level) and QoS signalling
protocols used to actually provision the QoS at the transport level.
Brian is right that there will never be an enhancement to a single session
protocol that will satisfy all applications.
However, for similar reasons, it is never going to be possible to prescribe
a single QoS mechanism to be used in all networks. Existing networks (or
domains) will not be changed overnight and new networks already face several
workable mechanisms to deploy QoS.

I think that what is needed is a new protocol that can signal the
requirements of any session and can be satisfied by any QoS mechanism,
existing or new.
To be more precise, I am suggesting a new protocol that is independent of
the underlying transport technology and the QoS implemented and is also
independent of the session control protocol. Such a new protocol would be
generic, optionally implemented by applications that would benefit from
end-to-end QoS, and would be complimentary to the QoS mechanisms deployed
(and of course other mechanisms, such as the routing).

I think that this implies a more abstract definition of the QoS mechanism
and may lend itself to the signalling of pre-defined QoS classes rather than
parameters.

Dick Knight

-----Original Message-----
From: Brian Williams [mailto:brian.williams@ericsson.com.au]
Sent: 22 December 2001 23:57
To: lieve.bos@alcatel.be
Cc: nsis@ietf.org
Subject: Re: [NSIS] Two kinds of requirements


Hi.
While the two types of signalling may be related, I think there is a
need to develop a QoS bearer mechanism which is independent of any
specific session signalling, and thus can be used for any application. I
believe many of the applications which have identified requirements to
the working group have their own specific session layer signalling (ie
it is not end-to-end SIP).  

Having the session and transport protocols developed separately of
course does not prohibit the two being used in conjunction for a
specific application.
/brian
 
On Fri, 2001-12-21 at 22:24, lieve.bos@alcatel.be wrote:
> Hello all,
> 
> >From the discussion in Salt Lake city and the drafts submitted, one can
> easily see that people are suggesting improvements to QoS signalling at
> two totally different levels (some at session level and some at
> transport level).
> 
> First of all, there are drafts suggesting some improvements in the
> session setup procedures (i.e. the ability to negotiate the preferred
> QoS level between end users during SDP negotiation in SIP, so before the
> actual resources are being setup). The QoS information negotiated at the
> session layer determines the QoS level both endusers have to use for 
> their local access connection. This first kind of 'session level QoS
> negotiation' happens end-to-end between the two end-users.
> 
> Secondly, there are drafts suggesting that we need
> improvements/alternatives for the QoS signalling protocols (e.g. RSVP)
> used to actually provision the QoS at the transport level between two
> endusers. This second kind of 'transport level QoS signalling' can
> consist of several phases: end-to-edge and edge-to-edge. 
> 
> It's important that everybody realises that, in order to give endusers
> true end-to-end Quality of Service, we need improvements for QoS both at
> session and transport level. Also its important to understand that they
> are not uncorrelated. Providers want to be able to control (e.g. via
> policy control mechanisms) that the QoS requested at the transport level
> is not exceeding the QoS negotiated/authorised previously at session
> level. So, what about developing in NSIS a modular framework
> incorporating both session and transport level QoS signalling with
> possible hooks between the two layers (e.g. for policy enforcement).
> 
> Lieve
> 
> _______________________________________________
> 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 Jan 16 09:51: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 JAA09610
	for <nsis-archive@odin.ietf.org>; Wed, 16 Jan 2002 09:51:37 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id JAA03557
	for nsis-archive@odin.ietf.org; Wed, 16 Jan 2002 09:51: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 JAA03419;
	Wed, 16 Jan 2002 09:46: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 JAA03388
	for <nsis@optimus.ietf.org>; Wed, 16 Jan 2002 09:46:50 -0500 (EST)
Received: from G8SBV.dmz.telekom.de ([62.225.183.235])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09508
	for <nsis@ietf.org>; Wed, 16 Jan 2002 09:46:45 -0500 (EST)
Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Wed, 16 Jan 2002 15:44:21 +0100
Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19)
	id <ZLG2MMHK>; Wed, 16 Jan 2002 15:46:04 +0100
Message-Id: <DFD875E85664D3118FA6080006277DE70362C820@U8PN2>
From: "Geib, Ruediger" <Ruediger.Geib@t-systems.com>
To: dick.rr.knight@bt.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements
Date: Wed, 16 Jan 2002 15:45:58 +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 JAA03389
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 Dick,

your suggestion is quite reasonable. I also favour an architecture where a QoS request by and large is predefined in terms of the resources required from the available transport mechanism. Service specific parameters to be signaled during reservation should be strictly limited. The more mapping and evaluation of QoS parameters is required during reservation, the more complex the service gets. Complex services are hard to sell and hard to provide.

Regards,

Rüdiger 

Rüdiger Geib
Senior Project Manager
T-Systems Nova GmbH

> I think that what is needed is a new protocol that can signal the
> requirements of any session and can be satisfied by any QoS
> mechanism, existing or new.
> To be more precise, I am suggesting a new protocol that is 
> independent of the underlying transport technology and the QoS
> implemented and is also independent of the session control
> protocol. Such a new protocol would be generic, optionally
> implemented by applications that would benefit from
> end-to-end QoS, and would be complimentary to the QoS 
> mechanisms deployed (and of course other mechanisms,
> such as the routing).
> 
> I think that this implies a more abstract definition of the 
> QoS mechanism and may lend itself to the signalling of
> pre-defined QoS classes rather than parameters.
> 
> Dick Knight
 

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



From daemon@optimus.ietf.org  Wed Jan 16 10:20:31 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10811
	for <nsis-archive@odin.ietf.org>; Wed, 16 Jan 2002 10:20:27 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id KAA04939
	for nsis-archive@odin.ietf.org; Wed, 16 Jan 2002 10:20: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 KAA04587;
	Wed, 16 Jan 2002 10:07:00 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA04559
	for <nsis@optimus.ietf.org>; Wed, 16 Jan 2002 10:06:57 -0500 (EST)
Received: from howler.tri.sbc.com (howler.tri.sbc.com [205.173.58.4])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10328
	for <nsis@ietf.org>; Wed, 16 Jan 2002 10:06:54 -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 g0GF8wT09015;
	Wed, 16 Jan 2002 09:08:58 -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 g0GF5pD21387;
	Wed, 16 Jan 2002 09:05:51 -0600 (CST)
Received: by TRIMAIL2.ad.tri.sbc.com with Internet Mail Service (5.5.2653.19)
	id <ZND3H067>; Wed, 16 Jan 2002 09:06:17 -0600
Message-ID: <905A1C4ABF353F4C8CC16FA9F53DD0D632240C@TRIMAIL2.ad.tri.sbc.com>
From: "Chen, Weijing" <wchen@tri.sbc.com>
To: "'dick.rr.knight@bt.com'" <dick.rr.knight@bt.com>,
        brian.williams@ericsson.com.au, lieve.bos@alcatel.be
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements
Date: Wed, 16 Jan 2002 09:06:15 -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

I am in pretty much agreement of Dick's comment. I guessed that service
operator has similar need. To elaborate more, I have the following:



 












In here MUNI (Multiprotocol UNI) signaling protocol is the ONE we need from
NSIS. It must have the following criteria:

1. Where: MUNI signaling must support destination on demand.
2. How: MUNI signaling must support QoS (bandwidth, delay, delay variance)
on demand.
3. Multiprotocol: MUNI signaling must be multiprotocol.  a) Signaling
message must be delivered over a multiprotocol network. b) MUNI signaling
must support multiple data stream classifier: IP flow (src/dst address,
port, CoS), MPLS label, VLAN label, MAC address, PPPoE session id, ATM
VPI/VCI, FR DLCI, etc....
4. Independence: MUNI signaling must be independent of the "core" network
technology and signaling (NNI and NNI signaling). a) Separation of MUNI from
NNI ensures a simple and widespread MUNI in PC, network appliance, set top,
gateway, router, switch, wireless handset, etc... b) Separation of MUNI from
NNI also ensures a portable access device market. 

Therefore the scope and requirement of NSIS should be focused on the above.
An extension and modification of RSVP is most likely solution. However we
are flexible to listen to other suggestions.

How the MUNI QoS request and MUNI session mapping onto network NNI QoS and
NNI session may not be the scope of NSIS. Regardless, the following are
several potential mapping schemes:
1. Dedicated trunk connection: One subscriber session per trunk connection.
Ex. ATM SVC (Layer 2) and IP RSVP (Layer 3), MPLS (Layer 2 and 3)
2. Shared trunk connection: Multiple subscriber sessions per trunk
connection. Subscriber session QoS is managed by CAC function of trunk
connection. Ex. a) Best effort: Extreme case of shared trunk connection -
one trunk connection per network with no CAC but best effort.  b) Priority
QoS: Elastic shared trunk connection with CAC by priority only. c) Trunk
reservation: Shared trunk connection with proper CAC. Shared trunk
connections are dynamically pre-reserved between network access nodes with
guaranteed aggregated bandwidth. Individual sessions are admitted into these
trunks provided that the total requested bandwidth of the sessions does not
exceed capacity limit of trunk bandwidth. When the known aggregate bandwidth
approaches the capacity limit, a new trunk is setup through signaling
mechanisms, ex. MPLS (Layer 2 and 3),  ATM PNNI (Layer 2).

--
Weijing Chen
SBC Technology Resources
9505 Arboretum Blvd.
Austin, TX 78759
512 372 5710
wchen@tri.sbc.com

This e-mail and any files transmitted with it are the property of SBC, are
confidential, and are intended solely for the use of the individual or
entity to whom this e-mail is addressed.  If you are not one of the named
recipient(s) or otherwise have reason to believe that you have received this
message in error, please notify the sender at 512 372-5710 and delete this
message immediately from your computer.  Any other use, retention,
dissemination, forwarding, printing, or copying of this e-mail is strictly
prohibited.


 -----Original Message-----
From: 	dick.rr.knight@bt.com [mailto:dick.rr.knight@bt.com] 
Sent:	Wednesday, January 16, 2002 6:00 AM
To:	brian.williams@ericsson.com.au; lieve.bos@alcatel.be
Cc:	nsis@ietf.org
Subject:	RE: [NSIS] Two kinds of requirements

I was waiting for some reaction to Brian's comments, but as there aren't
any, here are my thoughts on the requirements:

I agree with the analysis that discussion has been based around
application-related signalling for QoS (at session level) and QoS signalling
protocols used to actually provision the QoS at the transport level.
Brian is right that there will never be an enhancement to a single session
protocol that will satisfy all applications.
However, for similar reasons, it is never going to be possible to prescribe
a single QoS mechanism to be used in all networks. Existing networks (or
domains) will not be changed overnight and new networks already face several
workable mechanisms to deploy QoS.

I think that what is needed is a new protocol that can signal the
requirements of any session and can be satisfied by any QoS mechanism,
existing or new.
To be more precise, I am suggesting a new protocol that is independent of
the underlying transport technology and the QoS implemented and is also
independent of the session control protocol. Such a new protocol would be
generic, optionally implemented by applications that would benefit from
end-to-end QoS, and would be complimentary to the QoS mechanisms deployed
(and of course other mechanisms, such as the routing).

I think that this implies a more abstract definition of the QoS mechanism
and may lend itself to the signalling of pre-defined QoS classes rather than
parameters.

Dick Knight

-----Original Message-----
From: Brian Williams [mailto:brian.williams@ericsson.com.au]
Sent: 22 December 2001 23:57
To: lieve.bos@alcatel.be
Cc: nsis@ietf.org
Subject: Re: [NSIS] Two kinds of requirements


Hi.
While the two types of signalling may be related, I think there is a
need to develop a QoS bearer mechanism which is independent of any
specific session signalling, and thus can be used for any application. I
believe many of the applications which have identified requirements to
the working group have their own specific session layer signalling (ie
it is not end-to-end SIP).  

Having the session and transport protocols developed separately of
course does not prohibit the two being used in conjunction for a
specific application.
/brian
 
On Fri, 2001-12-21 at 22:24, lieve.bos@alcatel.be wrote:
> Hello all,
> 
> >From the discussion in Salt Lake city and the drafts submitted, one can
> easily see that people are suggesting improvements to QoS signalling at
> two totally different levels (some at session level and some at
> transport level).
> 
> First of all, there are drafts suggesting some improvements in the
> session setup procedures (i.e. the ability to negotiate the preferred
> QoS level between end users during SDP negotiation in SIP, so before the
> actual resources are being setup). The QoS information negotiated at the
> session layer determines the QoS level both endusers have to use for 
> their local access connection. This first kind of 'session level QoS
> negotiation' happens end-to-end between the two end-users.
> 
> Secondly, there are drafts suggesting that we need
> improvements/alternatives for the QoS signalling protocols (e.g. RSVP)
> used to actually provision the QoS at the transport level between two
> endusers. This second kind of 'transport level QoS signalling' can
> consist of several phases: end-to-edge and edge-to-edge. 
> 
> It's important that everybody realises that, in order to give endusers
> true end-to-end Quality of Service, we need improvements for QoS both at
> session and transport level. Also its important to understand that they
> are not uncorrelated. Providers want to be able to control (e.g. via
> policy control mechanisms) that the QoS requested at the transport level
> is not exceeding the QoS negotiated/authorised previously at session
> level. So, what about developing in NSIS a modular framework
> incorporating both session and transport level QoS signalling with
> possible hooks between the two layers (e.g. for policy enforcement).
> 
> Lieve
> 
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis



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

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

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



From daemon@optimus.ietf.org  Wed Jan 16 10:25: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 KAA10973
	for <nsis-archive@odin.ietf.org>; Wed, 16 Jan 2002 10:25:22 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id KAA05131
	for nsis-archive@odin.ietf.org; Wed, 16 Jan 2002 10:25: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 KAA04919;
	Wed, 16 Jan 2002 10:19: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 KAA04886
	for <nsis@optimus.ietf.org>; Wed, 16 Jan 2002 10:19:30 -0500 (EST)
Received: from almso1.proxy.att.com (almso1.att.com [192.128.167.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10793
	for <nsis@ietf.org>; Wed, 16 Jan 2002 10:19:21 -0500 (EST)
Received: from attrh1i.attrh.att.com ([135.71.62.10])
	by almso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id g0GFIZW02344
	for <nsis@ietf.org>; Wed, 16 Jan 2002 10:18:37 -0500 (EST)
Received: from occlust04evs1.ugd.att.com (135.71.164.12) by attrh1i.attrh.att.com (5.5.029)
        id 3C0BA3A500204327; Wed, 16 Jan 2002 09:48:18 -0500
content-class: urn:content-classes:message
Subject: RE: [NSIS] Two kinds of requirements
Date: Wed, 16 Jan 2002 09:48:09 -0500
Message-ID: <62DA45D4963FA747BA1B253E266760F90116BF40@OCCLUST04EVS1.ugd.att.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Thread-Topic: [NSIS] Two kinds of requirements
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
Thread-Index: AcGehdn6AK05gwp5EdazmACQJ2FUNwAEV4PQ
From: "Roy, Radhika R, ALASO" <rrroy@att.com>
To: <dick.rr.knight@bt.com>, <brian.williams@ericsson.com.au>,
        <lieve.bos@alcatel.be>
Cc: <nsis@ietf.org>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id KAA04887
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, Dick:

I agree with you. I have expanded the thoughts how we can achieve this goal. Please see my comments inline [RRR].

Best regards,

Radhika R. Roy
rrroy@att.com

-----Original Message-----
From: dick.rr.knight@bt.com [mailto:dick.rr.knight@bt.com]
Sent: Wednesday, January 16, 2002 7:00 AM
To: brian.williams@ericsson.com.au; lieve.bos@alcatel.be
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements

...

I think that what is needed is a new protocol that can signal the
requirements of any session and can be satisfied by any QoS mechanism,
existing or new.

[RRR] You are right.

To be more precise, I am suggesting a new protocol that is independent of
the underlying transport technology and the QoS implemented and is also
independent of the session control protocol. Such a new protocol would be
generic, optionally implemented by applications that would benefit from
end-to-end QoS, and would be complimentary to the QoS mechanisms deployed
(and of course other mechanisms, such as the routing).

[RRR] Let me add a little more to it. The characteristics of the end-to-end QOS will be at the end user level and can be termed as the application layer QOS. The end-to-end application layer QOS will also be independent of any underlying network layer QOS mechanism that may not have the end-to-end significance. In other words, the end-to-end application layer QOS will be negotiated/signaled at the user level that will remain fixed for the duration of the call/session once agreed.

[RRR] Then the question comes how does the networking layer QOS will be using the end-to-end application layer QOS or what should be the relationship between the application layer (end-to-end) QOS and the network layer QOS. This may be termed as the implementation of the application layer QOS to the network layer QOS. For example, knowing the end-to-end application QOS, we can map this into corresponding network layer QOS.

[RRR] A simple example may help. Let us say, two end users decide that there needs to have 150 ms end-to-end delay for the audio call. However, there may be several domains in the end-to-end path: RSVP (domain 1) + DiffServ (domain 2) + RSVP (domain 3). The delay requirement may need to be satisfied in each domain is as follows: domain 1 = 65 ms, domain 2 = 20 ms and domain 3 = 65 ms. (This requires interaction between the application and the network layer. We can deal with this situation defining implementations. So, when each domain will satisfy its own part, the end-to-end delay of 150 ms is met from the application point of view.

I think that this implies a more abstract definition of the QoS mechanism
and may lend itself to the signalling of pre-defined QoS classes rather than
parameters.

[RRR] The thing that we need to do is to develop the end-to-end application layer QOS signaling protocol. This will only deal with the universal QOS characteristics of the application.

[RRR] Then the question comes: How do we define the universal QOS parameters of the application? An application can consist of audio, video, and/or data. We can define the performance characteristics of each medium from the endusers' perspective that are independent of the underlying transport layer QOS. Some works have already been progressing in this area and we may start examining those things.

Dick Knight


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



From daemon@optimus.ietf.org  Wed Jan 16 10:28: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 KAA11188
	for <nsis-archive@odin.ietf.org>; Wed, 16 Jan 2002 10:28:17 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id KAA05207
	for nsis-archive@odin.ietf.org; Wed, 16 Jan 2002 10:28: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 KAA05068;
	Wed, 16 Jan 2002 10:23: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 KAA05033
	for <nsis@optimus.ietf.org>; Wed, 16 Jan 2002 10:23:48 -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 KAA10899
	for <nsis@ietf.org>; Wed, 16 Jan 2002 10:23:44 -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 g0GFNeH51855;
	Wed, 16 Jan 2002 16:23:40 +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 E79B0C052; Wed, 16 Jan 2002 16:23:03 +0100 (CET)
Date: Wed, 16 Jan 2002 16:34:37 +0100
From: Marcus Brunner <brunner@ccrle.nec.de>
Reply-To: brunner@ccrle.nec.de
To: "Geib, Ruediger" <Ruediger.Geib@t-systems.com>, dick.rr.knight@bt.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements
Message-ID: <22451263.1011198877@[192.168.102.79]>
In-Reply-To: <DFD875E85664D3118FA6080006277DE70362C820@U8PN2>
References:  <DFD875E85664D3118FA6080006277DE70362C820@U8PN2>
X-Mailer: Mulberry/2.1.0 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1; format=flowed
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id KAA05034
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,

The service needs to be defined anyway. Then there are IMO two 
possibilities
- the provider defines the services and offers them. In this case the 
provider needs to describe the offers in a machine readable form (most 
likely with parameter names and values)
- the consumer requests a particular service (this means the consumer has 
to describe the service he wants in a machine readable form)

So it seams one has to move around service specifications which are 
understandable by the other party anyway, what is now your point? Is it 
that you want to limit/fix as many parameters as possible? Or are you more 
think about standardized services everybody understands?

Marcus

--On Wednesday, January 16, 2002 3:45 PM +0100 "Geib, Ruediger" 
<Ruediger.Geib@t-systems.com> wrote:

> Hello Dick,
>
> your suggestion is quite reasonable. I also favour an architecture where
> a QoS request by and large is predefined in terms of the resources
> required from the available transport mechanism. Service specific
> parameters to be signaled during reservation should be strictly limited.
> The more mapping and evaluation of QoS parameters is required during
> reservation, the more complex the service gets. Complex services are hard
> to sell and hard to provide.
>
> Regards,
>
> Rüdiger
>
> Rüdiger Geib
> Senior Project Manager
> T-Systems Nova GmbH
>
>> I think that what is needed is a new protocol that can signal the
>> requirements of any session and can be satisfied by any QoS
>> mechanism, existing or new.
>> To be more precise, I am suggesting a new protocol that is
>> independent of the underlying transport technology and the QoS
>> implemented and is also independent of the session control
>> protocol. Such a new protocol would be generic, optionally
>> implemented by applications that would benefit from
>> end-to-end QoS, and would be complimentary to the QoS
>> mechanisms deployed (and of course other mechanisms,
>> such as the routing).
>>
>> I think that this implies a more abstract definition of the
>> QoS mechanism and may lend itself to the signalling of
>> pre-defined QoS classes rather than parameters.
>>
>> Dick Knight
>
>
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis
>



--------------------------------------
Dr. Marcus Brunner
Network Laboratories
NEC Europe Ltd.

E-Mail: brunner@ccrle.nec.de
WWW:    http://www.ccrle.nec.de/
personal home page: http://www.brubers.org/marcus



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



From daemon@optimus.ietf.org  Wed Jan 16 11: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 LAA12338
	for <nsis-archive@odin.ietf.org>; Wed, 16 Jan 2002 11:02:38 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id LAA06975
	for nsis-archive@odin.ietf.org; Wed, 16 Jan 2002 11:02:41 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA06154;
	Wed, 16 Jan 2002 10:46: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 KAA06090
	for <nsis@optimus.ietf.org>; Wed, 16 Jan 2002 10:46:37 -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 KAA11810
	for <nsis@ietf.org>; Wed, 16 Jan 2002 10:46:33 -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 g0GFmbT09967;
	Wed, 16 Jan 2002 09:48:37 -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 g0GFjJZ22982;
	Wed, 16 Jan 2002 09:45:29 -0600 (CST)
Received: by TRIMAIL2.ad.tri.sbc.com with Internet Mail Service (5.5.2653.19)
	id <ZND32AF0>; Wed, 16 Jan 2002 09:45:46 -0600
Message-ID: <905A1C4ABF353F4C8CC16FA9F53DD0D6322416@TRIMAIL2.ad.tri.sbc.com>
From: "Chen, Weijing" <wchen@tri.sbc.com>
To: "Chen, Weijing" <wchen@tri.sbc.com>,
        "'dick.rr.knight@bt.com'"
	 <dick.rr.knight@bt.com>,
        brian.williams@ericsson.com.au, lieve.bos@alcatel.be
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements
Date: Wed, 16 Jan 2002 09:45:44 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_000_01C19EA4.DBD5C690"
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_000_01C19EA4.DBD5C690
Content-Type: text/plain;
	charset="iso-8859-1"



 -----Original Message-----
From: 	Chen, Weijing  
Sent:	Wednesday, January 16, 2002 9:06 AM
To:	'dick.rr.knight@bt.com'; brian.williams@ericsson.com.au;
lieve.bos@alcatel.be
Cc:	nsis@ietf.org
Subject:	RE: [NSIS] Two kinds of requirements

I am in pretty much agreement of Dick's comment. I guessed that service
operator has similar need. To elaborate more, I have the following diagram:


[Oops, missing a picture here:


 <<muni.doc>> 

]

 












In here MUNI (Multiprotocol UNI) signaling protocol is the ONE we need from
NSIS. It must have the following criteria:

1. Where: MUNI signaling must support destination on demand.
2. How: MUNI signaling must support QoS (bandwidth, delay, delay variance)
on demand.
3. Multiprotocol: MUNI signaling must be multiprotocol.  a) Signaling
message must be delivered over a multiprotocol network. b) MUNI signaling
must support multiple data stream classifier: IP flow (src/dst address,
port, CoS), MPLS label, VLAN label, MAC address, PPPoE session id, ATM
VPI/VCI, FR DLCI, etc....
4. Independence: MUNI signaling must be independent of the "core" network
technology and signaling (NNI and NNI signaling). a) Separation of MUNI from
NNI ensures a simple and widespread MUNI in PC, network appliance, set top,
gateway, router, switch, wireless handset, etc... b) Separation of MUNI from
NNI also ensures a portable access device market. 

Therefore the scope and requirement of NSIS should be focused on the above.
An extension and modification of RSVP is most likely solution. However we
are flexible to listen to other suggestions.

How the MUNI QoS request and MUNI session mapping onto network NNI QoS and
NNI session may not be the scope of NSIS. Regardless, the following are
several potential mapping schemes:
1. Dedicated trunk connection: One subscriber session per trunk connection.
Ex. ATM SVC (Layer 2) and IP RSVP (Layer 3), MPLS (Layer 2 and 3)
2. Shared trunk connection: Multiple subscriber sessions per trunk
connection. Subscriber session QoS is managed by CAC function of trunk
connection. Ex. a) Best effort: Extreme case of shared trunk connection -
one trunk connection per network with no CAC but best effort.  b) Priority
QoS: Elastic shared trunk connection with CAC by priority only. c) Trunk
reservation: Shared trunk connection with proper CAC. Shared trunk
connections are dynamically pre-reserved between network access nodes with
guaranteed aggregated bandwidth. Individual sessions are admitted into these
trunks provided that the total requested bandwidth of the sessions does not
exceed capacity limit of trunk bandwidth. When the known aggregate bandwidth
approaches the capacity limit, a new trunk is setup through signaling
mechanisms, ex. MPLS (Layer 2 and 3),  ATM PNNI (Layer 2).

--
Weijing Chen
SBC Technology Resources
9505 Arboretum Blvd.
Austin, TX 78759
512 372 5710
wchen@tri.sbc.com

This e-mail and any files transmitted with it are the property of SBC, are
confidential, and are intended solely for the use of the individual or
entity to whom this e-mail is addressed.  If you are not one of the named
recipient(s) or otherwise have reason to believe that you have received this
message in error, please notify the sender at 512 372-5710 and delete this
message immediately from your computer.  Any other use, retention,
dissemination, forwarding, printing, or copying of this e-mail is strictly
prohibited.


 -----Original Message-----
From: 	dick.rr.knight@bt.com [mailto:dick.rr.knight@bt.com] 
Sent:	Wednesday, January 16, 2002 6:00 AM
To:	brian.williams@ericsson.com.au; lieve.bos@alcatel.be
Cc:	nsis@ietf.org
Subject:	RE: [NSIS] Two kinds of requirements

I was waiting for some reaction to Brian's comments, but as there aren't
any, here are my thoughts on the requirements:

I agree with the analysis that discussion has been based around
application-related signalling for QoS (at session level) and QoS signalling
protocols used to actually provision the QoS at the transport level.
Brian is right that there will never be an enhancement to a single session
protocol that will satisfy all applications.
However, for similar reasons, it is never going to be possible to prescribe
a single QoS mechanism to be used in all networks. Existing networks (or
domains) will not be changed overnight and new networks already face several
workable mechanisms to deploy QoS.

I think that what is needed is a new protocol that can signal the
requirements of any session and can be satisfied by any QoS mechanism,
existing or new.
To be more precise, I am suggesting a new protocol that is independent of
the underlying transport technology and the QoS implemented and is also
independent of the session control protocol. Such a new protocol would be
generic, optionally implemented by applications that would benefit from
end-to-end QoS, and would be complimentary to the QoS mechanisms deployed
(and of course other mechanisms, such as the routing).

I think that this implies a more abstract definition of the QoS mechanism
and may lend itself to the signalling of pre-defined QoS classes rather than
parameters.

Dick Knight

-----Original Message-----
From: Brian Williams [mailto:brian.williams@ericsson.com.au]
Sent: 22 December 2001 23:57
To: lieve.bos@alcatel.be
Cc: nsis@ietf.org
Subject: Re: [NSIS] Two kinds of requirements


Hi.
While the two types of signalling may be related, I think there is a
need to develop a QoS bearer mechanism which is independent of any
specific session signalling, and thus can be used for any application. I
believe many of the applications which have identified requirements to
the working group have their own specific session layer signalling (ie
it is not end-to-end SIP).  

Having the session and transport protocols developed separately of
course does not prohibit the two being used in conjunction for a
specific application.
/brian
 
On Fri, 2001-12-21 at 22:24, lieve.bos@alcatel.be wrote:
> Hello all,
> 
> >From the discussion in Salt Lake city and the drafts submitted, one can
> easily see that people are suggesting improvements to QoS signalling at
> two totally different levels (some at session level and some at
> transport level).
> 
> First of all, there are drafts suggesting some improvements in the
> session setup procedures (i.e. the ability to negotiate the preferred
> QoS level between end users during SDP negotiation in SIP, so before the
> actual resources are being setup). The QoS information negotiated at the
> session layer determines the QoS level both endusers have to use for 
> their local access connection. This first kind of 'session level QoS
> negotiation' happens end-to-end between the two end-users.
> 
> Secondly, there are drafts suggesting that we need
> improvements/alternatives for the QoS signalling protocols (e.g. RSVP)
> used to actually provision the QoS at the transport level between two
> endusers. This second kind of 'transport level QoS signalling' can
> consist of several phases: end-to-edge and edge-to-edge. 
> 
> It's important that everybody realises that, in order to give endusers
> true end-to-end Quality of Service, we need improvements for QoS both at
> session and transport level. Also its important to understand that they
> are not uncorrelated. Providers want to be able to control (e.g. via
> policy control mechanisms) that the QoS requested at the transport level
> is not exceeding the QoS negotiated/authorised previously at session
> level. So, what about developing in NSIS a modular framework
> incorporating both session and transport level QoS signalling with
> possible hooks between the two layers (e.g. for policy enforcement).
> 
> Lieve
> 
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis



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

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

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

------_=_NextPart_000_01C19EA4.DBD5C690
Content-Type: application/msword;
	name="muni.doc"
Content-Disposition: attachment;
	filename="muni.doc"
Content-Transfer-Encoding: base64

0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAKAAAAAAAAAAA
EAAAKgAAAAEAAAD+////AAAAACcAAAD/////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
///////////////////////////////////////////////////////////////////////////s
pcEAcQAJBAAAABK/AAAAAAAAEAAAAAAABAAAAgQAAA4AYmpianQrdCsAAAAAAAAAAAAAAAAAAAAA
AAAJBBYAZR0AABZBAQAWQQEAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//w8AAAAA
AAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAAF0AAAAAAJIAAAAAAAAAkgAAAJIA
AAAAAAAAkgAAAAAAAACSAAAAAAAAAJIAAAAAAAAAkgAAABQAAAAAAAAAAAAAAKYAAAAAAAAApgAA
AAAAAACmAAAAAAAAAKYAAAAAAAAApgAAAAwAAACyAAAADAAAAKYAAAAAAAAAhgMAAOoAAADKAAAA
AAAAAMoAAAAAAAAAygAAAAAAAADKAAAAAAAAAMoAAAAAAAAAewIAAAAAAAB7AgAAAAAAAHsCAAAA
AAAASwMAAAIAAABNAwAAAAAAAE0DAAAAAAAATQMAAAAAAABNAwAAAAAAAE0DAAAAAAAATQMAACQA
AABwBAAA9AEAAGQGAABeAAAAcQMAABUAAAAAAAAAAAAAAAAAAAAAAAAAkgAAAAAAAAB7AgAAAAAA
AAAAAAAAAAAAAAAAAAAAAABZAgAAIgAAAHsCAAAAAAAAewIAAAAAAAB7AgAAAAAAAHEDAAAAAAAA
jwIAAAAAAACSAAAAAAAAAJIAAAAAAAAAygAAAAAAAAAAAAAAAAAAAMoAAACPAQAAygAAAAAAAACP
AgAAAAAAAI8CAAAAAAAAjwIAAAAAAAB7AgAACgAAAJIAAAAAAAAAygAAAAAAAACSAAAAAAAAAMoA
AAAAAAAASwMAAAAAAAAAAAAAAAAAAAAAAAAAAAAApgAAAAAAAACmAAAAAAAAAJIAAAAAAAAAkgAA
AAAAAACSAAAAAAAAAJIAAAAAAAAAewIAAAAAAABLAwAAAAAAAI8CAAC8AAAAjwIAAAAAAAAAAAAA
AAAAAEsDAAAAAAAAkgAAAAAAAACSAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASwMAAAAAAADKAAAAAAAAAL4AAAAMAAAA4OPzqqSe
wQGmAAAAAAAAAKYAAAAAAAAAhQIAAAoAAABLAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACA0A
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAA
AQQAAAIEAAD4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADQNqAAAAAFUIAW1IAAQAAgAEAAAC
BAAA/QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAABAAQAAAIE
AAD+AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIBAQEcAB+w0C8g
sOA9IbAIByKwCAcjkKAFJJCgBSWwAABAPRrwPxEAAAVRcvys2v/ZZTvTn8OCIXEUVwAAAAAAAAAA
AACBAwAAQgEAABI9ggAdrS4ADREAAAD+eJztXAl4lMUZnpk/5yYRCIQkxGrkvhGtt1aiHIkIBgii
QCBgjImGABJYVCp5ihQV1FhbrRQslVaRgkVqpa2KeUrBgBxRQLlBBQylcoVAQGj6fv/Mn539s8ku
YTfdPE83z5u55ztmvrl3OWMsHxBAKDDZYOxmzmo+4ycwdn0nxpL7DerPGGetRjA2HHkMZvuEMDOy
D8qesKd9E8KK3jGYA97mQDvgCBCpwj9V5VrBHw3EACDGOgNXAgP6pt1N/L2KPKOBsQhUKR7HAjcz
4ky6THMpVhPF7dNB0eKaH/IX3Q93ESIfJ8B/O2g1g38c/O/zLXwV/4p/yPfxT/gh/k9+lK/nxxFb
wbfxSr6Ln+H7gUPwH0XcCaSR7zxiquGGiOM8UlTwZqKSx4kzPAlIhr8j4roh7VpxlN8gDvFbxD5+
h/iK9xFbeF9RxlOBQWIzHyI28gxRykeINXykWM1HiVU8U6wAlgKLEV6A+FeRXox8c5F/DsrNRvlZ
qGcW6puNemeg/qmgUwB6eaCbDfrjwMdY8JMJvjLB3xjwmQV+s8F3LvifADlyIU82pMiCNGMgZybk
zYTcYyH/OOghG/rIg14KoJ+p0NMM/j6fzVfwWXwZsAT+xXwOX8Tn8oW8mM/nr/LX+QL+GmJf40uB
FQivQvxqpK9BvlKkbES5zShfhtQyTvq32iocbdXZQxviU0R9h/pShOo7hq2NLT/Si7rBTQD+jUrW
A0PR3t9y9/p0mkPhTuKszn4ViA+3QSjY4xmz88U9+8lbpKA+1dXVZoLl4pPsJ/ZrfZS5u/FtfU7P
Ohd+YE0sy55mNp+bnSawmjYRicoPfkUSk+OI9bHaiHRUIQWq+XwkarxtU2DhebDs/AZLcsGZGt6S
sa/j2UKHYyu5hO7LY1mYme5gC4ZVOh2m/1ozTHIQ71XFqRE0aLZH3k1plU4KX1ejD5mXxr4fTH5b
msMri8ipoDCV5yhHn9Jl0i1G+O2FPziLO1Y5IXL1IoRvzSl3Ulnzo/FINNamVzlJbcmrYs2wxUOI
4mEpaG0sja3Jl6ryUXwrIXVrbyOK023S1/ZqrdIof6xWPoPkArYicAhuexA4XaOj8ymEMwjsBqIQ
c6+tdarVJxv+wWwYS0eXLmAPs0LmZBPR9o+xanNOonmIBAlRruW30mheDNf4ZBqfwub3NG/1M+TY
8grcENX/AjVvXQMa++GfBDdJzVtDjNN8qHGWZxjn+HDjAh9h/Ic/aDAxyuAi0xAiCxgPZAM5iMtF
2qPIk4+8E+BORHgy4guRPg2YDjwJzEDc00grQp6fIe8zqH826Pwc9J4FngPmAvOMCv6icZK/ZJzg
xcYx4Ch/2TgCHAYOIvw1sB/pe5FvN/LvRLmdKL8D9exAfTtR73bUvxV0yniRsZk/bWzkM4zP+JPG
Bj4dmAYUApMRNxFpE5AnH3kfhZuLcA7is5E+HsgCMoFRiHsQaSOQZzjyZqD+oaAzBPTSQXcwMAj+
gcA94CsN/A0AnwPAb3/w3R/894ccAyDPAMiVBvnugZwDIe8gyD0YSAdI/4Gat0Yi03eo6A1DdsC6
5i1fbdEfNjsDSKE1IpfryVjubrPZiDvHpZx12exo+NNgrYWw18eV1Vr2abmhyg1Xfl/sU9dnRybt
1MPcKXQ7s3SNZTDWgIzlwN1XzxqhIWOgP/RO41wcUAbQXLKfueudxpd1XOqvLr1TPcPZFFPrDqVb
Qlg9+vUH75OAK4ADTI6Dx22894bvSy75qIv3B+DvC86nYVZ/CK7Of4hyI+qRw1/9ZC4wHxHbmewv
wdZPpjO5t/kAWAKsten6V/At41Jf9dnnAMwuZJ9OuE8wOV/q9mnpvzF0/gEqeJDGGYwtU4JU5wvB
41S4W+E+Y9N5CeIea2I6vwq6TkVEZpDqnMbDaEO6XYhHm857IW5kEI+HoeCvEC7xOcvGe2fEPdpE
xsN48PomIsbA/TgI+wnZZjWE/ARub/C42abrtoj7iw+2eTd2FXLFUmC2m2Wb1lolXPMHWucO8Pw0
IrLg/joIdf4scBJCzod7HXh8x6bzVogr5lKHdek8C/5+NWvESeZunizV2s9ZOg/Vwo3Z7zsi8Asg
F/goCNuAxpgYBN6Feyvcj21tcC0Cv/dhjEnB6ELjyxT86WNMhOYP5FiZBcQjsBpub7ibbHKQbLQO
M+qRg+oZhNmZxoIo5rLbQPeROaqPbAjSPkL6KFB9ZIGHPvKy6iPexsZhpo1aM5E8V9Ft02Cu/hLo
eXWS6ivzPfSVV1Rf8dbnh2EFloeR5yGWa8pC/T6EuZ8hNfS86BHQfwt4DnhHdSB/nxeNgNseuJv6
HdwcuCWKp1z+Np8D+OPM4lLtYTYYoD5VKoLTHqj/5AtpD6+L2vbwkmg6Y+Y0Ie2gWNS2A5ItWMdM
inNyua5/Mwj7CPFFNvEKQOcWb9p0exOTth2s+w66f10MEJ8rbbzTzcTrjbjv8DQ+TsC/P4CHOXCX
BHh8TAOND+Fmq/0B0S8Qb/HZQEPHR08yfSrknfPeRpBpsZDr779rMpVCnt1iit9leh6FaQ/eGDIt
gnvEJpPDmOt3majvJSLDykaQifreGbjrNZnijRUBkeknyLCrkWRKAq2Tmky3Gzv8KhNNXPRWJNmQ
+69AyrRHyPPUi3BnKpm4kcOvMjL9KtM2JteFnRphXbiCyXVhiLYu7IA14XbW8HWhJ5keAuai8DwW
eJnuBH4H5DGXTM9Dnmw2z68y0f7mLSXTZwGWCZOy2U4k0zeaTDlsfcDuHMeT/ri8OzhRz/rrUt9r
EG+V1e7vNYpdiml7+e81Eljn8QnMH28e3N9rqPcZzPVew4xHub+q9xlF5nsN1/uMYtv7DOIrM8ax
zeSv6KzT/l5jtHrvMfq9WDZqXLmzKrfcrIfS1k2qdFI5Yqz5pkS2EXkpfNe5084kFXdiuec3NVa/
8Nf6ke5+04DdwGSgvEZHcv1IbbeFe7/77Ye9da5290trRuqbYQohmt9ggV0T03o+VcnyCFDpQaY9
PqznRyA1hQ0218PEt7d1sL/Ob9IUz09RRbw270e49/ObVDaRTUBLpIP/FMU3yRCpydLQc1VPY8xe
YDn4ugr4lx/GGH/pcg1QyuQb1+3MXZeHmTyz8KbLFNQ2iPXCHmmYmc/SHenSYI2315uh5CE5jjI5
f9jlWd/EbDVLyUSy7GS13xGQTF/6cK6Rzu5DT3e1S6DPY/IV38TvAeCCB77pXWpoPXzTvrs/ZtNe
qLE3c/Ujq0/V158uxTbHgY8/AQuB/UFim1lM3kVvgDsG7lc2/dHd+mof2l3aprtNBtoGUxW/tAY6
6IHvz5qgDaYqWagtTnqQaYePNjiM+WaD3s6M7gIucnmPm2h7gymYhzU5JspQF1duPFp93G4r1pqc
bO9HoDNT7dUo3wMsWrzBHUK3J33t1Unp0vU8uboWrfuVXG0pL5fncz2UHkcyLvqBxkjWWlj5nuDy
XuxFoLvKt4DHiffAxwLuOlsN1+yW2fhqyP6gJ3HPqU9KXftrfxD499zxLGFzvF/W2JeyPziwLs7r
/oD4ahHluIvcuvcHcXXyTuWaa7xT2Nv+IBDvuTOYfKNIb5MpvattPUr210LIuLrGhnQm+1gI8898
9h6XY0Mp2UuQvKEl0LuNROA3QGebnj5EoFkj6+lvQCQy9gTRdkGip0XAb4l3LiN/bNPTP+BLEvJt
aV16ymV0jzUc6700lowZJw+7vAJzHMmD+4h5t+VQMJQ+rbW69dbEutvQ4/yh8+uEHEvpHiIhSHRO
oHG9DSKuhNvFpnP6zlzzRu6btxnShocawWXD9H0MsuH2Rm0b7ms0vg2v4fI8/Hp1z+7Pszv73ByI
szt/zG+BOLs753C829TP7ug8dymXb5PDhLy/1vvrJgSepHmH1d1fqX3p7jfbvPuVb5WzMaoWov2n
YjR9jDG3+2D9vEO/G7bG2VAtPdB78F8q+cmt5PIO3C6/eZ9Zj/x0VjgMO7FxkNcuubWHsd5rN1RW
b+8orCWxy/xca31Ks8aCKw25DxsNt6KesaAh/ez/a/aaNXvfpr5mpzchIYY8Q+5pyDtB3S46Ie4o
9/4mZCibCEsorHnTYn8bHcoa3uetvu6pz1Oc1ee7qnmvQATn+zI6Y44Fb8vh9hHybk/X9Q2IW8yb
1ntLujujd3I/gbvRJs9NiPuzD30nkO8t+wu5dqT3D/azIc4adjbEmeezIWo/OhuKMOT7cCI3WkSJ
TobnsyGqxzobcvXt6lq0rDOfjkKe+dwmXGc+YwQTaaAxRsTVnA0JQ+aj72ZY+ToYceJW4sPwfjbE
meezIU/6XUv9FZ4bhVzv6ryTrL7I11JrQ5KB5lmyg6uBt2l9zWU7r+cRohT4FFjHIwGHQhTiopEW
oxAt1gMbEL8B6RKRgsoTLBrLFI2VGo0vkP45UGYiUmxB2S2opwz1ET5H/V8AW4FtCBO2I3078m1D
/m0ot1Wj8YGi8ZFGYw/SdwO7TESKnSi7E3XsQl2E3ah7D7AX2IcwYT/S9yPfPuTfh3J7NRolisY6
jcZhpB8CDpqIFN+i7Leo4yDqIhxC3YeB74ByhAlHkH4E+cqRvxzlvtNobFA0yjQaJ5B+HDhmIlJ8
j7Lfo45jqItwHHWfAE4CpxAmVCC9AvlOIf8plDup0dimaOzSaJxH+jmgykSkOIuyZ1FHFeoinEPd
54EfgAsIEy4i/SLyXUD+Cyj3g0Zjn6JxUKMRIiKEAQgRaYILBxAFfzQQg7QYEQKEAmEmokU40sOR
Lwz5CaHCRaNc0Tim0bgC6TFANPISolA2Cn/R5l+M+XcF0AxobiJatEB6C+RrjvyEZhqNU4pGlUYj
AenxQGvkJcShbBzqaI26WqPOeCABSATamIgWSUhPQr42yE9I1GhcUDSEcNFoi/RrgGTkJVyNslej
jmTUlYw6rwHaAu2A9iaiRQekd0C+9shPaKfRoL0I0YjWaHRHejegK/ISuqBsF9TRFXV1RZ3dgO5A
D6CniWjRC+m9kK8n8hN6oLw1rujj9aWOed723C/Q+ZOQY26nIDmbWAQUqrOb7UL+5pM+L79GOm8i
52Z1rQFLSko8rgHpreMxJs8FEwO0Bly5cuVl7cNf4PJNPf0uURvm3jYrqK182Ie7rwGT8V9+P/Fx
uPms/jWhvj+11uhWvvrOovwl/zwEqMz3cLva5Ke75xY+yJ8POeUZRJ4pebIZMxE78alyT6PJa8ll
/w0Ye1+93LVmXybv7r7h8n5OL0/B+tadQnsniL7tJre3dWcyk+eIn3D5mzrEywGeyPsxp1/fPtJ7
AJLvTmS4pxHlo/sQko/ONMZp8t1hpAbsHSR9P5Lud+l+9Y56xhHdJv7Xbx/rOmugFbZ11sBJCeqs
gSfUfU5SdnJQxJIlgyNWAKwPdFOCNewf0doHLs6ksxHJfkvzt6lQypk6sMoZEdbSrO/wC+VuNAk1
x0K2c5IMs3xiDe/sRck78bQWPJr0S6QOqZ5WFaedFG7I+amnNvI2VtE+it4X0LuY+5j7WEXfPb3R
p7E6jaWz7rDTVNSbofwPmzte6tf6WanB3MfqMFt8mM31x73BQLVWWAL3Th/7emPMk72FHFOfgjvE
pvsMta5p6rqnOzZ6nzdTyHvzYND9MpJPSDmHCLk/13VP5xDnVX3edZ9sfnt/IpvOnoB/ilq30H+7
7vW3TKGannX/pbxzuhwdPMvkvodkv0XIOdaug3Du/TcMRkDS8Ta5rTfCdvlCbP5Aykf3QIaSi86T
eniQrxWX66P65Otr/voe2dS98KcwutPU11O67VzqO+Jomzy6/XiyqxjbGoD2N61U2ebK/1/SVD++
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASAA8ACgABAFsADwACAAAA
AAAAACQAAEDx/wIAJAAAAAYATgBvAHIAbQBhAGwAAAACAAAABABtSAkEAAAAAAAAAAAAAAAAAAAA
AAAAPABBQPL/oQA8AAAAFgBEAGUAZgBhAHUAbAB0ACAAUABhAHIAYQBnAHIAYQBwAGgAIABGAG8A
bgB0AAAAAAAAAAAAAAAAAAAAAAACAAAABwAADAAAAAD/////AAQAAAIEAAADAAAAAAQAAAIEAAAE
AAAAAAQAAAIEAAAFAAAADwAA8GwAAAAAAAbwGAAAAAIIAAACAAAAAgAAAAEAAAABAAAAAwAAAB8A
AfAsAAAAIgAH8CQAAAACBAVRcvys2v/ZZTvTn8OCIXH/AEcRAAABAAAAHgwAAAAAAABAAB7xEAAA
AP//AAAAAP8AgICAAPcAABAADwAC8BIBAAAQAAjwCAAAAAIAAAACBAAADwAD8LAAAAAPAATwKAAA
AAEACfAQAAAAAAAAAAAAAAAAAAAAAAAAAAIACvAIAAAAAAQAAAUAAAAPAATweAAAALIECvAIAAAA
AgQAAAAKAADDAAvwSAAAAIUAAgAAAIcAAQAAAL8AAAAPAARBAQAAAIEBBAAACIMBAAAACL8BAAAQ
AMABAQAACP8BBgAOAAECAgAACD8CAAADAH8DAAAPAAAAEPAEAAAAAAAAAAAAEfAEAAAAAwAAAA8A
BPBCAAAAEgAK8AgAAAABBAAAAA4AAFMAC/AeAAAAvwEAABAAywEAAAAA/wEAAAgABAMJAAAAPwMB
AAEAAAAR8AQAAAABAAAAAAAAAAIAAAACBAAAOPv//0ACAACZJQAAcBEAAHQAAAAAAAAAAAAEAAAA
BwAAAAAABAAAAAcA//8CAAAADQBDAGgAZQBuACwAIABXAGUAaQBqAGkAbgBnAEwAQwA6AFwARABv
AGMAdQBtAGUAbgB0AHMAIABhAG4AZAAgAFMAZQB0AHQAaQBuAGcAcwBcAHcAYwBoAGUAbgBcAE0A
eQAgAEQAbwBjAHUAbQBlAG4AdABzAFwAYgByAGkAZQBmAGMAYQBzAGUAXABwAHIAbwBqAGUAYwB0
AHMAXAB1AG4AaQBcAG0AdQBuAGkALgBkAG8AYwD/QAEBAQAAAAAAAQAAALAXfgEBAAEAAAAAAAEA
AAAAAAAAAAAAAAIQAAAAAAAAAAIAAABwAAAIAEAAAAMAAABnFpABABACAgYDBQQFAgMEh3oAAAAA
AIAIAAAAAAAAAP8AAAAAAAAAVABpAG0AZQBzACAATgBlAHcAIABSAG8AbQBhAG4AAABUAGkAbQBl
AHMAIABOAGUAdwAgAFIAbwBtAGEAbgAAADUWkAECAAUFAQIBBwYCBQcAAAAAAAAAEAAAAAAAAAAA
AAAAgAAAAABTAHkAbQBiAG8AbAAAAEcmkAEABgILBgQCAgICAgSHegAAAAAAgAgAAAAAAAAA/wAA
AAAAAABBAHIAaQBhAGwAAABIAGUAbAB2AGUAdABpAGMAYQAAACIABADwCIgYAADQAgAAaAEAAAAA
HHphRmyCYWYAAAAAAQDdBAAAAAAAAAEAAAABAAEAAAAEAAMQAQAAAAAAAAAAAAAAAQABAAAAAQAA
AAAAAAAhAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAClBsAHtAC0AIAAcjAAABAAGQBk
AAAAGQAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAgAAAAAA//8SAAAAAAAAAAAAAAAAAAAADQBDAGgAZQBuACwAIABX
AGUAaQBqAGkAbgBnAA0AQwBoAGUAbgAsACAAVwBlAGkAagBpAG4AZwAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/v8AAAUAAgAAAAAAAAAAAAAAAAAAAAAA
AQAAAOCFn/L5T2gQq5EIACsns9kwAAAAeAEAABEAAAABAAAAkAAAAAIAAACYAAAAAwAAAKQAAAAE
AAAAsAAAAAUAAADIAAAABgAAANQAAAAHAAAA4AAAAAgAAAD0AAAACQAAAAwBAAASAAAAGAEAAAoA
AAA0AQAADAAAAEABAAANAAAATAEAAA4AAABYAQAADwAAAGABAAAQAAAAaAEAABMAAABwAQAAAgAA
AOQEAAAeAAAAAQAAAAAAcwAeAAAAAQAAAAAAcwAeAAAADgAAAENoZW4sIFdlaWppbmcAbwAeAAAA
AQAAAABoZW4eAAAAAQAAAABoZW4eAAAACwAAAE5vcm1hbC5kb3QAbh4AAAAOAAAAQ2hlbiwgV2Vp
amluZwBvAB4AAAACAAAAMQBlbh4AAAATAAAATWljcm9zb2Z0IFdvcmQgOC4wAABAAAAAAG6r7K0A
AABAAAAAAFhG1dCdwQFAAAAAAOConaSewQEDAAAAAQAAAAMAAAAAAAAAAwAAAAEAAAADAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP7/AAAFAAIAAAAAAAAAAAAAAAAAAAAAAAIAAAAC1c3V
nC4bEJOXCAArLPmuRAAAAAXVzdWcLhsQk5cIACss+a5QAQAADAEAAAwAAAABAAAAaAAAAA8AAABw
AAAABQAAAKAAAAAGAAAAqAAAABEAAACwAAAAFwAAALgAAAALAAAAwAAAABAAAADIAAAAEwAAANAA
AAAWAAAA2AAAAA0AAADgAAAADAAAAO0AAAACAAAA5AQAAB4AAAAnAAAAU291dGh3ZXN0ZXJuIEJl
bGwgVGVjaG5vbG9neSBSZXNvdXJjZXMAAAMAAAABAAAAAwAAAAEAAAADAAAAAQAAAAMAAAAxFQgA
CwAAAAAAAAALAAAAAAAAAAsAAAAAAAAACwAAAAAAAAAeEAAAAQAAAAEAAAAADBAAAAIAAAAeAAAA
BgAAAFRpdGxlAAMAAAABAAAAAJgAAAADAAAAAAAAACAAAAABAAAANgAAAAIAAAA+AAAAAQAAAAIA
AAAKAAAAX1BJRF9HVUlEAAIAAADkBAAAQQAAAE4AAAB7ADAANwBGAEUANAAwADcANAAtAEEANQBD
AEUALQA0ADgAMgBFAC0AOQA3ADgARAAtADcANgAxAEEAOQA1ADgAQwBCAEMAMwA3AH0AAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAABAAAAAgAAAAMAAAAEAAAABQAAAAYAAAAHAAAACAAAAAkAAAAKAAAA
CwAAAAwAAAANAAAADgAAAP7///8QAAAAEQAAABIAAAATAAAAFAAAABUAAAAWAAAA/v///xgAAAAZ
AAAAGgAAABsAAAAcAAAAHQAAAB4AAAD+////IAAAACEAAAAiAAAAIwAAACQAAAAlAAAAJgAAAP7/
///9////KQAAAP7////+/////v//////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
/////////////////////1IAbwBvAHQAIABFAG4AdAByAHkAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAWAAUB//////////8DAAAABgkCAAAAAADAAAAAAAAARgAA
AADwgb6qpJ7BASBbD6uknsEBKwAAAIAAAAAAAAAAMQBUAGEAYgBsAGUAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA4AAgD///////////////8AAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPAAAAABAAAAAAAABXAG8AcgBkAEQAbwBj
AHUAbQBlAG4AdAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGgACAQUA
AAD//////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABlHQAAAAAA
AAUAUwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAoAAIBAgAAAAQAAAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAFwAAAAAQAAAAAAAABQBEAG8AYwB1AG0AZQBuAHQAUwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIA
bQBhAHQAaQBvAG4AAAAAAAAAAAAAADgAAgH///////////////8AAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAfAAAAABAAAAAAAAABAEMAbwBtAHAATwBiAGoAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEgACAQEAAAAGAAAA/////wAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABqAAAAAAAAAE8AYgBqAGUAYwB0AFAA
bwBvAGwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAWAAEA////
////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAgWw+rpJ7BASBbD6uknsEBAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAD///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAABAAAA/v//////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
/////////////////wEA/v8DCgAA/////wYJAgAAAAAAwAAAAAAAAEYYAAAATWljcm9zb2Z0IFdv
cmQgRG9jdW1lbnQACgAAAE1TV29yZERvYwAQAAAAV29yZC5Eb2N1bWVudC44APQ5snEAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAA

------_=_NextPart_000_01C19EA4.DBD5C690--

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



From daemon@optimus.ietf.org  Wed Jan 16 11:36: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 LAA13384
	for <nsis-archive@odin.ietf.org>; Wed, 16 Jan 2002 11:36:40 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id LAA08595
	for nsis-archive@odin.ietf.org; Wed, 16 Jan 2002 11:36: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 LAA08481;
	Wed, 16 Jan 2002 11:32: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 LAA08447
	for <nsis@optimus.ietf.org>; Wed, 16 Jan 2002 11:32:13 -0500 (EST)
Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13260
	for <nsis@ietf.org>; Wed, 16 Jan 2002 11:32:09 -0500 (EST)
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id g0GGV4k24523;
	Wed, 16 Jan 2002 08:31:05 -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 AAR53098;
	Wed, 16 Jan 2002 08:30:49 -0800 (PST)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA16519; Wed, 16 Jan 2002 08:31:21 -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: <15429.43737.12408.818914@thomasm-u1.cisco.com>
Date: Wed, 16 Jan 2002 08:31:21 -0800 (PST)
To: dick.rr.knight@bt.com
Cc: brian.williams@ericsson.com.au, lieve.bos@alcatel.be, nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements
In-Reply-To: <451D45016C2CD2119DA50000F8FE7F07080E5A2E@mlngcbnt01.hc.bt.com>
References: <451D45016C2CD2119DA50000F8FE7F07080E5A2E@mlngcbnt01.hc.bt.com>
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


So, I'm really dumb here. Can somebody enumerate
the *specific* things that are broken with RSVP?
Before we run off designing new protocols, it
would be nice to know a) what things the current
protocols have problems with and b) whether the
current protocols are fatally flawed in the face
of those problems.

I know some in (a). I don't think they meet (b).

	Mike

dick.rr.knight@bt.com writes:
 > I was waiting for some reaction to Brian's comments, but as there aren't
 > any, here are my thoughts on the requirements:
 > 
 > I agree with the analysis that discussion has been based around
 > application-related signalling for QoS (at session level) and QoS signalling
 > protocols used to actually provision the QoS at the transport level.
 > Brian is right that there will never be an enhancement to a single session
 > protocol that will satisfy all applications.
 > However, for similar reasons, it is never going to be possible to prescribe
 > a single QoS mechanism to be used in all networks. Existing networks (or
 > domains) will not be changed overnight and new networks already face several
 > workable mechanisms to deploy QoS.
 > 
 > I think that what is needed is a new protocol that can signal the
 > requirements of any session and can be satisfied by any QoS mechanism,
 > existing or new.
 > To be more precise, I am suggesting a new protocol that is independent of
 > the underlying transport technology and the QoS implemented and is also
 > independent of the session control protocol. Such a new protocol would be
 > generic, optionally implemented by applications that would benefit from
 > end-to-end QoS, and would be complimentary to the QoS mechanisms deployed
 > (and of course other mechanisms, such as the routing).
 > 
 > I think that this implies a more abstract definition of the QoS mechanism
 > and may lend itself to the signalling of pre-defined QoS classes rather than
 > parameters.
 > 
 > Dick Knight
 > 
 > -----Original Message-----
 > From: Brian Williams [mailto:brian.williams@ericsson.com.au]
 > Sent: 22 December 2001 23:57
 > To: lieve.bos@alcatel.be
 > Cc: nsis@ietf.org
 > Subject: Re: [NSIS] Two kinds of requirements
 > 
 > 
 > Hi.
 > While the two types of signalling may be related, I think there is a
 > need to develop a QoS bearer mechanism which is independent of any
 > specific session signalling, and thus can be used for any application. I
 > believe many of the applications which have identified requirements to
 > the working group have their own specific session layer signalling (ie
 > it is not end-to-end SIP).  
 > 
 > Having the session and transport protocols developed separately of
 > course does not prohibit the two being used in conjunction for a
 > specific application.
 > /brian
 >  
 > On Fri, 2001-12-21 at 22:24, lieve.bos@alcatel.be wrote:
 > > Hello all,
 > > 
 > > >From the discussion in Salt Lake city and the drafts submitted, one can
 > > easily see that people are suggesting improvements to QoS signalling at
 > > two totally different levels (some at session level and some at
 > > transport level).
 > > 
 > > First of all, there are drafts suggesting some improvements in the
 > > session setup procedures (i.e. the ability to negotiate the preferred
 > > QoS level between end users during SDP negotiation in SIP, so before the
 > > actual resources are being setup). The QoS information negotiated at the
 > > session layer determines the QoS level both endusers have to use for 
 > > their local access connection. This first kind of 'session level QoS
 > > negotiation' happens end-to-end between the two end-users.
 > > 
 > > Secondly, there are drafts suggesting that we need
 > > improvements/alternatives for the QoS signalling protocols (e.g. RSVP)
 > > used to actually provision the QoS at the transport level between two
 > > endusers. This second kind of 'transport level QoS signalling' can
 > > consist of several phases: end-to-edge and edge-to-edge. 
 > > 
 > > It's important that everybody realises that, in order to give endusers
 > > true end-to-end Quality of Service, we need improvements for QoS both at
 > > session and transport level. Also its important to understand that they
 > > are not uncorrelated. Providers want to be able to control (e.g. via
 > > policy control mechanisms) that the QoS requested at the transport level
 > > is not exceeding the QoS negotiated/authorised previously at session
 > > level. So, what about developing in NSIS a modular framework
 > > incorporating both session and transport level QoS signalling with
 > > possible hooks between the two layers (e.g. for policy enforcement).
 > > 
 > > Lieve
 > > 
 > > _______________________________________________
 > > nsis mailing list
 > > nsis@ietf.org
 > > https://www1.ietf.org/mailman/listinfo/nsis
 > 
 > 
 > 
 > _______________________________________________
 > nsis mailing list
 > nsis@ietf.org
 > https://www1.ietf.org/mailman/listinfo/nsis
 > 
 > _______________________________________________
 > nsis mailing list
 > nsis@ietf.org
 > https://www1.ietf.org/mailman/listinfo/nsis

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



From daemon@optimus.ietf.org  Wed Jan 16 11:58: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 LAA13975
	for <nsis-archive@odin.ietf.org>; Wed, 16 Jan 2002 11:58:23 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id LAA09062
	for nsis-archive@odin.ietf.org; Wed, 16 Jan 2002 11:58:26 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08791;
	Wed, 16 Jan 2002 11:45: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 LAA08763
	for <nsis@optimus.ietf.org>; Wed, 16 Jan 2002 11:45:28 -0500 (EST)
Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13668
	for <nsis@ietf.org>; Wed, 16 Jan 2002 11:45:12 -0500 (EST)
Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85])
	by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g0GGklQ13357
	for <nsis@ietf.org>; Wed, 16 Jan 2002 10:46:47 -0600 (CST)
Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T587b4f46aaac12f2550ef@davir02nok.americas.nokia.com>;
 Wed, 16 Jan 2002 10:45:15 -0600
Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Wed, 16 Jan 2002 10:45:07 -0600
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [NSIS] Two kinds of requirements
Date: Wed, 16 Jan 2002 11:45:06 -0500
Message-ID: <E320A8529CF07E4C967ECC2F380B0CF9064BBD@bsebe001.NOE.Nokia.com>
Thread-Topic: [NSIS] Two kinds of requirements
Thread-Index: AcGeoWH8W3zNaAqUEdaJYgAIx6TWpQAC1LsA
From: "Chaskar Hemant (NRC/Boston)" <Hemant.Chaskar@nokia.com>
To: "'ext Roy, Radhika R, ALASO'" <rrroy@att.com>
Cc: <nsis@ietf.org>
X-OriginalArrivalTime: 16 Jan 2002 16:45:07.0172 (UTC) FILETIME=[2776EA40:01C19EAD]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA08764
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 Radhika:

Just one comment below [HC].

--------------------------------------snip------------------------------
-----------------
[RRR] The thing that we need to do is to develop the end-to-end
application layer QOS signaling protocol. This will only deal with the
universal QOS characteristics of the application.

[HC] The easiest way to do this is to look at SDPng which is XML based,
and hence, will easily provide containers for the application QoS
parameters.

Hemant

_______________________________________________
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 Jan 16 12:34: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 MAA15169
	for <nsis-archive@odin.ietf.org>; Wed, 16 Jan 2002 12:34:25 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id MAA11745
	for nsis-archive@odin.ietf.org; Wed, 16 Jan 2002 12:34: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 MAA10813;
	Wed, 16 Jan 2002 12:21: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 MAA10773
	for <nsis@optimus.ietf.org>; Wed, 16 Jan 2002 12:21:00 -0500 (EST)
Received: from kcmso1.proxy.att.com (kcmso1.att.com [192.128.133.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14658
	for <nsis@ietf.org>; Wed, 16 Jan 2002 12:20:55 -0500 (EST)
Received: from attrh1i.attrh.att.com ([135.71.62.10])
	by kcmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id g0GHK1n01842
	for <nsis@ietf.org>; Wed, 16 Jan 2002 12:20:11 -0500 (EST)
Received: from occlust04evs1.ugd.att.com (135.71.164.12) by attrh1i.attrh.att.com (5.5.029)
        id 3C0BA3A500208CBB; Wed, 16 Jan 2002 12:19:38 -0500
content-class: urn:content-classes:message
Subject: RE: [NSIS] Two kinds of requirements
Date: Wed, 16 Jan 2002 12:19:39 -0500
Message-ID: <62DA45D4963FA747BA1B253E266760F90116C0F2@OCCLUST04EVS1.ugd.att.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Thread-Topic: [NSIS] Two kinds of requirements
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
Thread-Index: AcGerS9WtzbWkAqeEdajbgCQJ60IGQAA7Kmg
From: "Roy, Radhika R, ALASO" <rrroy@att.com>
To: "Chaskar Hemant (NRC/Boston)" <Hemant.Chaskar@nokia.com>
Cc: <nsis@ietf.org>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id MAA10774
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, Hemant:

Yes you are right. Definitely, SDPng is one of the places to look into. We can look into those QOS parameters and can use for our purpose to develop the end-to-end QOS protocol.

Radhika

-----Original Message-----
From: Chaskar Hemant (NRC/Boston) [mailto:Hemant.Chaskar@nokia.com]
Sent: Wednesday, January 16, 2002 11:45 AM
To: Roy, Radhika R, ALASO
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


Hi Radhika:

Just one comment below [HC].

--------------------------------------snip------------------------------
-----------------
[RRR] The thing that we need to do is to develop the end-to-end
application layer QOS signaling protocol. This will only deal with the
universal QOS characteristics of the application.

[HC] The easiest way to do this is to look at SDPng which is XML based,
and hence, will easily provide containers for the application QoS
parameters.

Hemant

_______________________________________________
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 Jan 16 12:45: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 MAA15486
	for <nsis-archive@odin.ietf.org>; Wed, 16 Jan 2002 12:45:19 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id MAA12021
	for nsis-archive@odin.ietf.org; Wed, 16 Jan 2002 12:45: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 MAA11915;
	Wed, 16 Jan 2002 12:40: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 MAA11880
	for <nsis@optimus.ietf.org>; Wed, 16 Jan 2002 12:40:31 -0500 (EST)
Received: from almso1.proxy.att.com (almso1.att.com [192.128.167.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15297
	for <nsis@ietf.org>; Wed, 16 Jan 2002 12:40:06 -0500 (EST)
Received: from attrh1i.attrh.att.com ([135.71.62.10])
	by almso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id g0GHdPW04179
	for <nsis@ietf.org>; Wed, 16 Jan 2002 12:39:33 -0500 (EST)
Received: from occlust04evs1.ugd.att.com (135.71.164.12) by attrh1i.attrh.att.com (5.5.029)
        id 3C0BA3A500209455; Wed, 16 Jan 2002 12:38:37 -0500
content-class: urn:content-classes:message
Subject: RE: [NSIS] Two kinds of requirements
Date: Wed, 16 Jan 2002 12:38:37 -0500
Message-ID: <62DA45D4963FA747BA1B253E266760F90116C11C@OCCLUST04EVS1.ugd.att.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Thread-Topic: [NSIS] Two kinds of requirements
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
Thread-Index: AcGerAF3tzbFvwqeEdajbgCQJ60IGQABcqSg
From: "Roy, Radhika R, ALASO" <rrroy@att.com>
To: "Michael Thomas" <mat@cisco.com>, <dick.rr.knight@bt.com>
Cc: <brian.williams@ericsson.com.au>, <lieve.bos@alcatel.be>, <nsis@ietf.org>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id MAA11881
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:

Let me try.

For (a), RSVP has definitely some characteristics that can be used at the application layer on end-to-end basis. In fact, we have to look into RSVP, like SDPng, to examine all its features how we can exploit it for using in the application layer. We can then determine what we do when think that we need to develop a new QOS protocol.

However, it requires that RSVP needs to be used on end-to-end basis. If RSVP is used on end-to-end basis and if we all agree we do not need additional features (e.g., SDPng and/or others provide), it is definitely a good candidate to examine whether it meets all requirements.

What do we do when RSVP is not end-to-end? For example domain 1 = RSVP, domain 2 = DiffServ, and domain 3= RSVP. I guess that here it breaks down. One solution may be translation between RSVP and DiffServ. Then we loose the end-to-end picture.

Hope this may help to answer your questions.

Radhika

-----Original Message-----
From: Michael Thomas [mailto:mat@cisco.com]
Sent: Wednesday, January 16, 2002 11:31 AM
To: dick.rr.knight@bt.com
Cc: brian.williams@ericsson.com.au; lieve.bos@alcatel.be; nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements



So, I'm really dumb here. Can somebody enumerate
the *specific* things that are broken with RSVP?
Before we run off designing new protocols, it
would be nice to know a) what things the current
protocols have problems with and b) whether the
current protocols are fatally flawed in the face
of those problems.

I know some in (a). I don't think they meet (b).

	Mike


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



From daemon@optimus.ietf.org  Wed Jan 16 14:20: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 OAA18200
	for <nsis-archive@odin.ietf.org>; Wed, 16 Jan 2002 14:20:43 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id OAA16216
	for nsis-archive@odin.ietf.org; Wed, 16 Jan 2002 14:20: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 OAA15562;
	Wed, 16 Jan 2002 14:01: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 OAA15523
	for <nsis@optimus.ietf.org>; Wed, 16 Jan 2002 14:01:09 -0500 (EST)
Received: from arb-exchange1.cetaceannetworks.com ([63.127.199.194])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17705
	for <nsis@ietf.org>; Wed, 16 Jan 2002 14:00:53 -0500 (EST)
Received: by mail.cetaceannetworks.com with Internet Mail Service (5.5.2653.19)
	id <CYP6W49C>; Wed, 16 Jan 2002 13:58:01 -0500
Message-ID: <6D8664171C38D511B5AD0002B325CE6633EC57@mail.cetaceannetworks.com>
From: "Freytsis, Ilya" <ifreytsis@cetacean.com>
To: "'nsis@ietf.org'" <nsis@ietf.org>
Cc: "'dick.rr.knight@bt.com'" <dick.rr.knight@bt.com>
Subject: RE: [NSIS] Two kinds of requirements
Date: Wed, 16 Jan 2002 13:58:01 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: nsis-admin@ietf.org
Errors-To: nsis-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Next Steps in Signaling <nsis.ietf.org>
X-BeenThere: nsis@ietf.org

I fully agree with Dick's comments (and need) on independence of the new
signaling protocol from the end-to-end QoS negotiation (that belongs to the
application space) on one hand and from the QoS mechanism of choice deployed
by a domain on the other hand. Essentially I envision this protocol being
suitable for QoS negotiation between endpoint and the network (end-to-edge)
and between edges of the different domains (networks) that possibly deployed
different QoS technology. 

At the same time I am not sure that pre-defined classes can provide fine
enough level of control for various scenarios that need to be satisfied by
the new protocol.

Ilya Freytsis

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



From daemon@optimus.ietf.org  Wed Jan 16 14:20:46 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18215
	for <nsis-archive@odin.ietf.org>; Wed, 16 Jan 2002 14:20:46 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id OAA16230
	for nsis-archive@odin.ietf.org; Wed, 16 Jan 2002 14:20: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 OAA15902;
	Wed, 16 Jan 2002 14:11: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 OAA15869
	for <nsis@optimus.ietf.org>; Wed, 16 Jan 2002 14:11:07 -0500 (EST)
Received: from pea.isi.edu (pea.isi.edu [128.9.160.209])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17926
	for <nsis@ietf.org>; Wed, 16 Jan 2002 14:11:03 -0500 (EST)
Received: from localhost (berson@localhost)
	by pea.isi.edu (8.11.6/8.11.6) with ESMTP id g0GJ8TE03034;
	Wed, 16 Jan 2002 11:08:29 -0800
X-Authentication-Warning: pea.isi.edu: berson owned process doing -bs
Date: Wed, 16 Jan 2002 11:08:29 -0800 (PST)
From: Steven Berson <berson@isi.edu>
To: "Roy, Radhika R, ALASO" <rrroy@att.com>
cc: Michael Thomas <mat@cisco.com>, <dick.rr.knight@bt.com>,
        <brian.williams@ericsson.com.au>, <lieve.bos@alcatel.be>,
        <nsis@ietf.org>
Subject: RE: [NSIS] Two kinds of requirements
In-Reply-To: <62DA45D4963FA747BA1B253E266760F90116C11C@OCCLUST04EVS1.ugd.att.com>
Message-ID: <Pine.LNX.4.33.0201161054570.2979-100000@pea.isi.edu>
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 Wed, 16 Jan 2002, Roy, Radhika R, ALASO wrote:

> Hi, Mike:
> 
> Let me try.
> 
> For (a), RSVP has definitely some characteristics that can be used
> at the application layer on end-to-end basis. In fact, we have to
> look into RSVP, like SDPng, to examine all its features how we can
> exploit it for using in the application layer. We can then
> determine what we do when think that we need to develop a new QOS
> protocol.
> 
> However, it requires that RSVP needs to be used on end-to-end
> basis. If RSVP is used on end-to-end basis and if we all agree we
> do not need additional features (e.g., SDPng and/or others
> provide), it is definitely a good candidate to examine whether it
> meets all requirements.
> 
> What do we do when RSVP is not end-to-end? For example domain 1 =
> RSVP, domain 2 = DiffServ, and domain 3= RSVP. I guess that here
> it breaks down. One solution may be translation between RSVP and
> DiffServ. Then we loose the end-to-end picture.

I think this was adequately addressed in RFC 2998, ``A Framework for 
Integrated Services Operation over Diffserv Networks'' by Bernet, et 
al.

Regards,
Steve


 
> Hope this may help to answer your questions.
> 
> Radhika
> 
> -----Original Message-----
> From: Michael Thomas [mailto:mat@cisco.com]
> Sent: Wednesday, January 16, 2002 11:31 AM
> To: dick.rr.knight@bt.com
> Cc: brian.williams@ericsson.com.au; lieve.bos@alcatel.be; nsis@ietf.org
> Subject: RE: [NSIS] Two kinds of requirements
> 
> 
> 
> So, I'm really dumb here. Can somebody enumerate
> the *specific* things that are broken with RSVP?
> Before we run off designing new protocols, it
> would be nice to know a) what things the current
> protocols have problems with and b) whether the
> current protocols are fatally flawed in the face
> of those problems.
> 
> I know some in (a). I don't think they meet (b).
> 
> 	Mike
> 
> 
> _______________________________________________
> 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 Jan 16 14:37: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 OAA18705
	for <nsis-archive@odin.ietf.org>; Wed, 16 Jan 2002 14:37:42 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id OAA16995
	for nsis-archive@odin.ietf.org; Wed, 16 Jan 2002 14:37: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 OAA16193;
	Wed, 16 Jan 2002 14:20:05 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA16124
	for <nsis@optimus.ietf.org>; Wed, 16 Jan 2002 14:20:02 -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 OAA18177
	for <nsis@ietf.org>; Wed, 16 Jan 2002 14:19:58 -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 g0GJLxT15206;
	Wed, 16 Jan 2002 13:21:59 -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 g0GJJ4g01269;
	Wed, 16 Jan 2002 13:19:09 -0600 (CST)
Received: by TRIMAIL2.ad.tri.sbc.com with Internet Mail Service (5.5.2653.19)
	id <ZND32B42>; Wed, 16 Jan 2002 13:19:32 -0600
Message-ID: <905A1C4ABF353F4C8CC16FA9F53DD0D632241A@TRIMAIL2.ad.tri.sbc.com>
From: "Chen, Weijing" <wchen@tri.sbc.com>
To: "'nsis@ietf.org'" <nsis@ietf.org>
Cc: "'dick.rr.knight@bt.com'" <dick.rr.knight@bt.com>,
        "'Freytsis, Ilya'"
	 <ifreytsis@cetacean.com>
Subject: RE: [NSIS] Two kinds of requirements
Date: Wed, 16 Jan 2002 13:19:30 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_000_01C19EC2.B8E9D220"
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_000_01C19EC2.B8E9D220
Content-Type: text/plain;
	charset="iso-8859-1"

My comment starts in [WW]
--
Weijing Chen
SBC Technology Resources
9505 Arboretum Blvd.
Austin, TX 78759
512 372 5710
wchen@tri.sbc.com

This e-mail and any files transmitted with it are the property of SBC, are
confidential, and are intended solely for the use of the individual or
entity to whom this e-mail is addressed.  If you are not one of the named
recipient(s) or otherwise have reason to believe that you have received this
message in error, please notify the sender at 512 372-5710 and delete this
message immediately from your computer.  Any other use, retention,
dissemination, forwarding, printing, or copying of this e-mail is strictly
prohibited.


 -----Original Message-----
From: 	Freytsis, Ilya [mailto:ifreytsis@Cetacean.com] 
Sent:	Wednesday, January 16, 2002 12:58 PM
To:	'nsis@ietf.org'
Cc:	'dick.rr.knight@bt.com'
Subject:	RE: [NSIS] Two kinds of requirements

I fully agree with Dick's comments (and need) on independence of the new
signaling protocol from the end-to-end QoS negotiation (that belongs to the
application space) on one hand and from the QoS mechanism of choice deployed
by a domain on the other hand. Essentially I envision this protocol being
suitable for QoS negotiation between endpoint and the network (end-to-edge)
and between edges of the different domains (networks) that possibly deployed
different QoS technology. 

[WW] See if you agree that this signaling protocol is the MUNI
(Multiprotocol UNI) signaling in the attached diagram.  
 <<muni.doc>> 


At the same time I am not sure that pre-defined classes can provide fine
enough level of control for various scenarios that need to be satisfied by
the new protocol.

Ilya Freytsis

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

------_=_NextPart_000_01C19EC2.B8E9D220
Content-Type: application/msword;
	name="muni.doc"
Content-Disposition: attachment;
	filename="muni.doc"
Content-Transfer-Encoding: base64

0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAKAAAAAAAAAAA
EAAAKgAAAAEAAAD+////AAAAACcAAAD/////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
///////////////////////////////////////////////////////////////////////////s
pcEAcQAJBAAAABK/AAAAAAAAEAAAAAAABAAAAgQAAA4AYmpianQrdCsAAAAAAAAAAAAAAAAAAAAA
AAAJBBYAZR0AABZBAQAWQQEAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//w8AAAAA
AAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAAF0AAAAAAJIAAAAAAAAAkgAAAJIA
AAAAAAAAkgAAAAAAAACSAAAAAAAAAJIAAAAAAAAAkgAAABQAAAAAAAAAAAAAAKYAAAAAAAAApgAA
AAAAAACmAAAAAAAAAKYAAAAAAAAApgAAAAwAAACyAAAADAAAAKYAAAAAAAAAhgMAAOoAAADKAAAA
AAAAAMoAAAAAAAAAygAAAAAAAADKAAAAAAAAAMoAAAAAAAAAewIAAAAAAAB7AgAAAAAAAHsCAAAA
AAAASwMAAAIAAABNAwAAAAAAAE0DAAAAAAAATQMAAAAAAABNAwAAAAAAAE0DAAAAAAAATQMAACQA
AABwBAAA9AEAAGQGAABeAAAAcQMAABUAAAAAAAAAAAAAAAAAAAAAAAAAkgAAAAAAAAB7AgAAAAAA
AAAAAAAAAAAAAAAAAAAAAABZAgAAIgAAAHsCAAAAAAAAewIAAAAAAAB7AgAAAAAAAHEDAAAAAAAA
jwIAAAAAAACSAAAAAAAAAJIAAAAAAAAAygAAAAAAAAAAAAAAAAAAAMoAAACPAQAAygAAAAAAAACP
AgAAAAAAAI8CAAAAAAAAjwIAAAAAAAB7AgAACgAAAJIAAAAAAAAAygAAAAAAAACSAAAAAAAAAMoA
AAAAAAAASwMAAAAAAAAAAAAAAAAAAAAAAAAAAAAApgAAAAAAAACmAAAAAAAAAJIAAAAAAAAAkgAA
AAAAAACSAAAAAAAAAJIAAAAAAAAAewIAAAAAAABLAwAAAAAAAI8CAAC8AAAAjwIAAAAAAAAAAAAA
AAAAAEsDAAAAAAAAkgAAAAAAAACSAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASwMAAAAAAADKAAAAAAAAAL4AAAAMAAAA4OPzqqSe
wQGmAAAAAAAAAKYAAAAAAAAAhQIAAAoAAABLAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACA0A
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAA
AQQAAAIEAAD4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADQNqAAAAAFUIAW1IAAQAAgAEAAAC
BAAA/QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAABAAQAAAIE
AAD+AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIBAQEcAB+w0C8g
sOA9IbAIByKwCAcjkKAFJJCgBSWwAABAPRrwPxEAAAVRcvys2v/ZZTvTn8OCIXEUVwAAAAAAAAAA
AACBAwAAQgEAABI9ggAdrS4ADREAAAD+eJztXAl4lMUZnpk/5yYRCIQkxGrkvhGtt1aiHIkIBgii
QCBgjImGABJYVCp5ihQV1FhbrRQslVaRgkVqpa2KeUrBgBxRQLlBBQylcoVAQGj6fv/Mn539s8ku
YTfdPE83z5u55ztmvrl3OWMsHxBAKDDZYOxmzmo+4ycwdn0nxpL7DerPGGetRjA2HHkMZvuEMDOy
D8qesKd9E8KK3jGYA97mQDvgCBCpwj9V5VrBHw3EACDGOgNXAgP6pt1N/L2KPKOBsQhUKR7HAjcz
4ky6THMpVhPF7dNB0eKaH/IX3Q93ESIfJ8B/O2g1g38c/O/zLXwV/4p/yPfxT/gh/k9+lK/nxxFb
wbfxSr6Ln+H7gUPwH0XcCaSR7zxiquGGiOM8UlTwZqKSx4kzPAlIhr8j4roh7VpxlN8gDvFbxD5+
h/iK9xFbeF9RxlOBQWIzHyI28gxRykeINXykWM1HiVU8U6wAlgKLEV6A+FeRXox8c5F/DsrNRvlZ
qGcW6puNemeg/qmgUwB6eaCbDfrjwMdY8JMJvjLB3xjwmQV+s8F3LvifADlyIU82pMiCNGMgZybk
zYTcYyH/OOghG/rIg14KoJ+p0NMM/j6fzVfwWXwZsAT+xXwOX8Tn8oW8mM/nr/LX+QL+GmJf40uB
FQivQvxqpK9BvlKkbES5zShfhtQyTvq32iocbdXZQxviU0R9h/pShOo7hq2NLT/Si7rBTQD+jUrW
A0PR3t9y9/p0mkPhTuKszn4ViA+3QSjY4xmz88U9+8lbpKA+1dXVZoLl4pPsJ/ZrfZS5u/FtfU7P
Ohd+YE0sy55mNp+bnSawmjYRicoPfkUSk+OI9bHaiHRUIQWq+XwkarxtU2DhebDs/AZLcsGZGt6S
sa/j2UKHYyu5hO7LY1mYme5gC4ZVOh2m/1ozTHIQ71XFqRE0aLZH3k1plU4KX1ejD5mXxr4fTH5b
msMri8ipoDCV5yhHn9Jl0i1G+O2FPziLO1Y5IXL1IoRvzSl3Ulnzo/FINNamVzlJbcmrYs2wxUOI
4mEpaG0sja3Jl6ryUXwrIXVrbyOK023S1/ZqrdIof6xWPoPkArYicAhuexA4XaOj8ymEMwjsBqIQ
c6+tdarVJxv+wWwYS0eXLmAPs0LmZBPR9o+xanNOonmIBAlRruW30mheDNf4ZBqfwub3NG/1M+TY
8grcENX/AjVvXQMa++GfBDdJzVtDjNN8qHGWZxjn+HDjAh9h/Ic/aDAxyuAi0xAiCxgPZAM5iMtF
2qPIk4+8E+BORHgy4guRPg2YDjwJzEDc00grQp6fIe8zqH826Pwc9J4FngPmAvOMCv6icZK/ZJzg
xcYx4Ch/2TgCHAYOIvw1sB/pe5FvN/LvRLmdKL8D9exAfTtR73bUvxV0yniRsZk/bWzkM4zP+JPG
Bj4dmAYUApMRNxFpE5AnH3kfhZuLcA7is5E+HsgCMoFRiHsQaSOQZzjyZqD+oaAzBPTSQXcwMAj+
gcA94CsN/A0AnwPAb3/w3R/894ccAyDPAMiVBvnugZwDIe8gyD0YSAdI/4Gat0Yi03eo6A1DdsC6
5i1fbdEfNjsDSKE1IpfryVjubrPZiDvHpZx12exo+NNgrYWw18eV1Vr2abmhyg1Xfl/sU9dnRybt
1MPcKXQ7s3SNZTDWgIzlwN1XzxqhIWOgP/RO41wcUAbQXLKfueudxpd1XOqvLr1TPcPZFFPrDqVb
Qlg9+vUH75OAK4ADTI6Dx22894bvSy75qIv3B+DvC86nYVZ/CK7Of4hyI+qRw1/9ZC4wHxHbmewv
wdZPpjO5t/kAWAKsten6V/At41Jf9dnnAMwuZJ9OuE8wOV/q9mnpvzF0/gEqeJDGGYwtU4JU5wvB
41S4W+E+Y9N5CeIea2I6vwq6TkVEZpDqnMbDaEO6XYhHm857IW5kEI+HoeCvEC7xOcvGe2fEPdpE
xsN48PomIsbA/TgI+wnZZjWE/ARub/C42abrtoj7iw+2eTd2FXLFUmC2m2Wb1lolXPMHWucO8Pw0
IrLg/joIdf4scBJCzod7HXh8x6bzVogr5lKHdek8C/5+NWvESeZunizV2s9ZOg/Vwo3Z7zsi8Asg
F/goCNuAxpgYBN6Feyvcj21tcC0Cv/dhjEnB6ELjyxT86WNMhOYP5FiZBcQjsBpub7ibbHKQbLQO
M+qRg+oZhNmZxoIo5rLbQPeROaqPbAjSPkL6KFB9ZIGHPvKy6iPexsZhpo1aM5E8V9Ft02Cu/hLo
eXWS6ivzPfSVV1Rf8dbnh2EFloeR5yGWa8pC/T6EuZ8hNfS86BHQfwt4DnhHdSB/nxeNgNseuJv6
HdwcuCWKp1z+Np8D+OPM4lLtYTYYoD5VKoLTHqj/5AtpD6+L2vbwkmg6Y+Y0Ie2gWNS2A5ItWMdM
inNyua5/Mwj7CPFFNvEKQOcWb9p0exOTth2s+w66f10MEJ8rbbzTzcTrjbjv8DQ+TsC/P4CHOXCX
BHh8TAOND+Fmq/0B0S8Qb/HZQEPHR08yfSrknfPeRpBpsZDr779rMpVCnt1iit9leh6FaQ/eGDIt
gnvEJpPDmOt3majvJSLDykaQifreGbjrNZnijRUBkeknyLCrkWRKAq2Tmky3Gzv8KhNNXPRWJNmQ
+69AyrRHyPPUi3BnKpm4kcOvMjL9KtM2JteFnRphXbiCyXVhiLYu7IA14XbW8HWhJ5keAuai8DwW
eJnuBH4H5DGXTM9Dnmw2z68y0f7mLSXTZwGWCZOy2U4k0zeaTDlsfcDuHMeT/ri8OzhRz/rrUt9r
EG+V1e7vNYpdiml7+e81Eljn8QnMH28e3N9rqPcZzPVew4xHub+q9xlF5nsN1/uMYtv7DOIrM8ax
zeSv6KzT/l5jtHrvMfq9WDZqXLmzKrfcrIfS1k2qdFI5Yqz5pkS2EXkpfNe5084kFXdiuec3NVa/
8Nf6ke5+04DdwGSgvEZHcv1IbbeFe7/77Ye9da5290trRuqbYQohmt9ggV0T03o+VcnyCFDpQaY9
PqznRyA1hQ0218PEt7d1sL/Ob9IUz09RRbw270e49/ObVDaRTUBLpIP/FMU3yRCpydLQc1VPY8xe
YDn4ugr4lx/GGH/pcg1QyuQb1+3MXZeHmTyz8KbLFNQ2iPXCHmmYmc/SHenSYI2315uh5CE5jjI5
f9jlWd/EbDVLyUSy7GS13xGQTF/6cK6Rzu5DT3e1S6DPY/IV38TvAeCCB77pXWpoPXzTvrs/ZtNe
qLE3c/Ujq0/V158uxTbHgY8/AQuB/UFim1lM3kVvgDsG7lc2/dHd+mof2l3aprtNBtoGUxW/tAY6
6IHvz5qgDaYqWagtTnqQaYePNjiM+WaD3s6M7gIucnmPm2h7gymYhzU5JspQF1duPFp93G4r1pqc
bO9HoDNT7dUo3wMsWrzBHUK3J33t1Unp0vU8uboWrfuVXG0pL5fncz2UHkcyLvqBxkjWWlj5nuDy
XuxFoLvKt4DHiffAxwLuOlsN1+yW2fhqyP6gJ3HPqU9KXftrfxD499zxLGFzvF/W2JeyPziwLs7r
/oD4ahHluIvcuvcHcXXyTuWaa7xT2Nv+IBDvuTOYfKNIb5MpvattPUr210LIuLrGhnQm+1gI8898
9h6XY0Mp2UuQvKEl0LuNROA3QGebnj5EoFkj6+lvQCQy9gTRdkGip0XAb4l3LiN/bNPTP+BLEvJt
aV16ymV0jzUc6700lowZJw+7vAJzHMmD+4h5t+VQMJQ+rbW69dbEutvQ4/yh8+uEHEvpHiIhSHRO
oHG9DSKuhNvFpnP6zlzzRu6btxnShocawWXD9H0MsuH2Rm0b7ms0vg2v4fI8/Hp1z+7Pszv73ByI
szt/zG+BOLs753C829TP7ug8dymXb5PDhLy/1vvrJgSepHmH1d1fqX3p7jfbvPuVb5WzMaoWov2n
YjR9jDG3+2D9vEO/G7bG2VAtPdB78F8q+cmt5PIO3C6/eZ9Zj/x0VjgMO7FxkNcuubWHsd5rN1RW
b+8orCWxy/xca31Ks8aCKw25DxsNt6KesaAh/ez/a/aaNXvfpr5mpzchIYY8Q+5pyDtB3S46Ie4o
9/4mZCibCEsorHnTYn8bHcoa3uetvu6pz1Oc1ee7qnmvQATn+zI6Y44Fb8vh9hHybk/X9Q2IW8yb
1ntLujujd3I/gbvRJs9NiPuzD30nkO8t+wu5dqT3D/azIc4adjbEmeezIWo/OhuKMOT7cCI3WkSJ
TobnsyGqxzobcvXt6lq0rDOfjkKe+dwmXGc+YwQTaaAxRsTVnA0JQ+aj72ZY+ToYceJW4sPwfjbE
meezIU/6XUv9FZ4bhVzv6ryTrL7I11JrQ5KB5lmyg6uBt2l9zWU7r+cRohT4FFjHIwGHQhTiopEW
oxAt1gMbEL8B6RKRgsoTLBrLFI2VGo0vkP45UGYiUmxB2S2opwz1ET5H/V8AW4FtCBO2I3078m1D
/m0ot1Wj8YGi8ZFGYw/SdwO7TESKnSi7E3XsQl2E3ah7D7AX2IcwYT/S9yPfPuTfh3J7NRolisY6
jcZhpB8CDpqIFN+i7Leo4yDqIhxC3YeB74ByhAlHkH4E+cqRvxzlvtNobFA0yjQaJ5B+HDhmIlJ8
j7Lfo45jqItwHHWfAE4CpxAmVCC9AvlOIf8plDup0dimaOzSaJxH+jmgykSkOIuyZ1FHFeoinEPd
54EfgAsIEy4i/SLyXUD+Cyj3g0Zjn6JxUKMRIiKEAQgRaYILBxAFfzQQg7QYEQKEAmEmokU40sOR
Lwz5CaHCRaNc0Tim0bgC6TFANPISolA2Cn/R5l+M+XcF0AxobiJatEB6C+RrjvyEZhqNU4pGlUYj
AenxQGvkJcShbBzqaI26WqPOeCABSATamIgWSUhPQr42yE9I1GhcUDSEcNFoi/RrgGTkJVyNslej
jmTUlYw6rwHaAu2A9iaiRQekd0C+9shPaKfRoL0I0YjWaHRHejegK/ISuqBsF9TRFXV1RZ3dgO5A
D6CniWjRC+m9kK8n8hN6oLw1rujj9aWOed723C/Q+ZOQY26nIDmbWAQUqrOb7UL+5pM+L79GOm8i
52Z1rQFLSko8rgHpreMxJs8FEwO0Bly5cuVl7cNf4PJNPf0uURvm3jYrqK182Ie7rwGT8V9+P/Fx
uPms/jWhvj+11uhWvvrOovwl/zwEqMz3cLva5Ke75xY+yJ8POeUZRJ4pebIZMxE78alyT6PJa8ll
/w0Ye1+93LVmXybv7r7h8n5OL0/B+tadQnsniL7tJre3dWcyk+eIn3D5mzrEywGeyPsxp1/fPtJ7
AJLvTmS4pxHlo/sQko/ONMZp8t1hpAbsHSR9P5Lud+l+9Y56xhHdJv7Xbx/rOmugFbZ11sBJCeqs
gSfUfU5SdnJQxJIlgyNWAKwPdFOCNewf0doHLs6ksxHJfkvzt6lQypk6sMoZEdbSrO/wC+VuNAk1
x0K2c5IMs3xiDe/sRck78bQWPJr0S6QOqZ5WFaedFG7I+amnNvI2VtE+it4X0LuY+5j7WEXfPb3R
p7E6jaWz7rDTVNSbofwPmzte6tf6WanB3MfqMFt8mM31x73BQLVWWAL3Th/7emPMk72FHFOfgjvE
pvsMta5p6rqnOzZ6nzdTyHvzYND9MpJPSDmHCLk/13VP5xDnVX3edZ9sfnt/IpvOnoB/ilq30H+7
7vW3TKGannX/pbxzuhwdPMvkvodkv0XIOdaug3Du/TcMRkDS8Ta5rTfCdvlCbP5Aykf3QIaSi86T
eniQrxWX66P65Otr/voe2dS98KcwutPU11O67VzqO+Jomzy6/XiyqxjbGoD2N61U2ebK/1/SVD++
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASAA8ACgABAFsADwACAAAA
AAAAACQAAEDx/wIAJAAAAAYATgBvAHIAbQBhAGwAAAACAAAABABtSAkEAAAAAAAAAAAAAAAAAAAA
AAAAPABBQPL/oQA8AAAAFgBEAGUAZgBhAHUAbAB0ACAAUABhAHIAYQBnAHIAYQBwAGgAIABGAG8A
bgB0AAAAAAAAAAAAAAAAAAAAAAACAAAABwAADAAAAAD/////AAQAAAIEAAADAAAAAAQAAAIEAAAE
AAAAAAQAAAIEAAAFAAAADwAA8GwAAAAAAAbwGAAAAAIIAAACAAAAAgAAAAEAAAABAAAAAwAAAB8A
AfAsAAAAIgAH8CQAAAACBAVRcvys2v/ZZTvTn8OCIXH/AEcRAAABAAAAHgwAAAAAAABAAB7xEAAA
AP//AAAAAP8AgICAAPcAABAADwAC8BIBAAAQAAjwCAAAAAIAAAACBAAADwAD8LAAAAAPAATwKAAA
AAEACfAQAAAAAAAAAAAAAAAAAAAAAAAAAAIACvAIAAAAAAQAAAUAAAAPAATweAAAALIECvAIAAAA
AgQAAAAKAADDAAvwSAAAAIUAAgAAAIcAAQAAAL8AAAAPAARBAQAAAIEBBAAACIMBAAAACL8BAAAQ
AMABAQAACP8BBgAOAAECAgAACD8CAAADAH8DAAAPAAAAEPAEAAAAAAAAAAAAEfAEAAAAAwAAAA8A
BPBCAAAAEgAK8AgAAAABBAAAAA4AAFMAC/AeAAAAvwEAABAAywEAAAAA/wEAAAgABAMJAAAAPwMB
AAEAAAAR8AQAAAABAAAAAAAAAAIAAAACBAAAOPv//0ACAACZJQAAcBEAAHQAAAAAAAAAAAAEAAAA
BwAAAAAABAAAAAcA//8CAAAADQBDAGgAZQBuACwAIABXAGUAaQBqAGkAbgBnAEwAQwA6AFwARABv
AGMAdQBtAGUAbgB0AHMAIABhAG4AZAAgAFMAZQB0AHQAaQBuAGcAcwBcAHcAYwBoAGUAbgBcAE0A
eQAgAEQAbwBjAHUAbQBlAG4AdABzAFwAYgByAGkAZQBmAGMAYQBzAGUAXABwAHIAbwBqAGUAYwB0
AHMAXAB1AG4AaQBcAG0AdQBuAGkALgBkAG8AYwD/QAEBAQAAAAAAAQAAALAXfgEBAAEAAAAAAAEA
AAAAAAAAAAAAAAIQAAAAAAAAAAIAAABwAAAIAEAAAAMAAABnFpABABACAgYDBQQFAgMEh3oAAAAA
AIAIAAAAAAAAAP8AAAAAAAAAVABpAG0AZQBzACAATgBlAHcAIABSAG8AbQBhAG4AAABUAGkAbQBl
AHMAIABOAGUAdwAgAFIAbwBtAGEAbgAAADUWkAECAAUFAQIBBwYCBQcAAAAAAAAAEAAAAAAAAAAA
AAAAgAAAAABTAHkAbQBiAG8AbAAAAEcmkAEABgILBgQCAgICAgSHegAAAAAAgAgAAAAAAAAA/wAA
AAAAAABBAHIAaQBhAGwAAABIAGUAbAB2AGUAdABpAGMAYQAAACIABADwCIgYAADQAgAAaAEAAAAA
HHphRmyCYWYAAAAAAQDdBAAAAAAAAAEAAAABAAEAAAAEAAMQAQAAAAAAAAAAAAAAAQABAAAAAQAA
AAAAAAAhAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAClBsAHtAC0AIAAcjAAABAAGQBk
AAAAGQAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAgAAAAAA//8SAAAAAAAAAAAAAAAAAAAADQBDAGgAZQBuACwAIABX
AGUAaQBqAGkAbgBnAA0AQwBoAGUAbgAsACAAVwBlAGkAagBpAG4AZwAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/v8AAAUAAgAAAAAAAAAAAAAAAAAAAAAA
AQAAAOCFn/L5T2gQq5EIACsns9kwAAAAeAEAABEAAAABAAAAkAAAAAIAAACYAAAAAwAAAKQAAAAE
AAAAsAAAAAUAAADIAAAABgAAANQAAAAHAAAA4AAAAAgAAAD0AAAACQAAAAwBAAASAAAAGAEAAAoA
AAA0AQAADAAAAEABAAANAAAATAEAAA4AAABYAQAADwAAAGABAAAQAAAAaAEAABMAAABwAQAAAgAA
AOQEAAAeAAAAAQAAAAAAcwAeAAAAAQAAAAAAcwAeAAAADgAAAENoZW4sIFdlaWppbmcAbwAeAAAA
AQAAAABoZW4eAAAAAQAAAABoZW4eAAAACwAAAE5vcm1hbC5kb3QAbh4AAAAOAAAAQ2hlbiwgV2Vp
amluZwBvAB4AAAACAAAAMQBlbh4AAAATAAAATWljcm9zb2Z0IFdvcmQgOC4wAABAAAAAAG6r7K0A
AABAAAAAAFhG1dCdwQFAAAAAAOConaSewQEDAAAAAQAAAAMAAAAAAAAAAwAAAAEAAAADAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP7/AAAFAAIAAAAAAAAAAAAAAAAAAAAAAAIAAAAC1c3V
nC4bEJOXCAArLPmuRAAAAAXVzdWcLhsQk5cIACss+a5QAQAADAEAAAwAAAABAAAAaAAAAA8AAABw
AAAABQAAAKAAAAAGAAAAqAAAABEAAACwAAAAFwAAALgAAAALAAAAwAAAABAAAADIAAAAEwAAANAA
AAAWAAAA2AAAAA0AAADgAAAADAAAAO0AAAACAAAA5AQAAB4AAAAnAAAAU291dGh3ZXN0ZXJuIEJl
bGwgVGVjaG5vbG9neSBSZXNvdXJjZXMAAAMAAAABAAAAAwAAAAEAAAADAAAAAQAAAAMAAAAxFQgA
CwAAAAAAAAALAAAAAAAAAAsAAAAAAAAACwAAAAAAAAAeEAAAAQAAAAEAAAAADBAAAAIAAAAeAAAA
BgAAAFRpdGxlAAMAAAABAAAAAJgAAAADAAAAAAAAACAAAAABAAAANgAAAAIAAAA+AAAAAQAAAAIA
AAAKAAAAX1BJRF9HVUlEAAIAAADkBAAAQQAAAE4AAAB7ADAANwBGAEUANAAwADcANAAtAEEANQBD
AEUALQA0ADgAMgBFAC0AOQA3ADgARAAtADcANgAxAEEAOQA1ADgAQwBCAEMAMwA3AH0AAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAABAAAAAgAAAAMAAAAEAAAABQAAAAYAAAAHAAAACAAAAAkAAAAKAAAA
CwAAAAwAAAANAAAADgAAAP7///8QAAAAEQAAABIAAAATAAAAFAAAABUAAAAWAAAA/v///xgAAAAZ
AAAAGgAAABsAAAAcAAAAHQAAAB4AAAD+////IAAAACEAAAAiAAAAIwAAACQAAAAlAAAAJgAAAP7/
///9////KQAAAP7////+/////v//////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
/////////////////////1IAbwBvAHQAIABFAG4AdAByAHkAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAWAAUB//////////8DAAAABgkCAAAAAADAAAAAAAAARgAA
AADwgb6qpJ7BASBbD6uknsEBKwAAAIAAAAAAAAAAMQBUAGEAYgBsAGUAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA4AAgD///////////////8AAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPAAAAABAAAAAAAABXAG8AcgBkAEQAbwBj
AHUAbQBlAG4AdAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGgACAQUA
AAD//////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABlHQAAAAAA
AAUAUwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAoAAIBAgAAAAQAAAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAFwAAAAAQAAAAAAAABQBEAG8AYwB1AG0AZQBuAHQAUwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIA
bQBhAHQAaQBvAG4AAAAAAAAAAAAAADgAAgH///////////////8AAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAfAAAAABAAAAAAAAABAEMAbwBtAHAATwBiAGoAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEgACAQEAAAAGAAAA/////wAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABqAAAAAAAAAE8AYgBqAGUAYwB0AFAA
bwBvAGwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAWAAEA////
////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAgWw+rpJ7BASBbD6uknsEBAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAD///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAABAAAA/v//////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
/////////////////wEA/v8DCgAA/////wYJAgAAAAAAwAAAAAAAAEYYAAAATWljcm9zb2Z0IFdv
cmQgRG9jdW1lbnQACgAAAE1TV29yZERvYwAQAAAAV29yZC5Eb2N1bWVudC44APQ5snEAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAA

------_=_NextPart_000_01C19EC2.B8E9D220--

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



From daemon@optimus.ietf.org  Wed Jan 16 15:47: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 PAA20615
	for <nsis-archive@odin.ietf.org>; Wed, 16 Jan 2002 15:47:14 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id PAA18910
	for nsis-archive@odin.ietf.org; Wed, 16 Jan 2002 15:47: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 PAA18656;
	Wed, 16 Jan 2002 15:31: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 PAA18623
	for <nsis@optimus.ietf.org>; Wed, 16 Jan 2002 15:31:32 -0500 (EST)
Received: from kcmso1.proxy.att.com (kcmso1.att.com [192.128.133.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20338
	for <nsis@ietf.org>; Wed, 16 Jan 2002 15:31:11 -0500 (EST)
Received: from attrh1i.attrh.att.com ([135.71.62.10])
	by kcmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id g0GKUBn16690
	for <nsis@ietf.org>; Wed, 16 Jan 2002 15:30:22 -0500 (EST)
Received: from occlust04evs1.ugd.att.com (135.71.164.12) by attrh1i.attrh.att.com (5.5.029)
        id 3C0BA3A50020DDE2; Wed, 16 Jan 2002 15:18:23 -0500
content-class: urn:content-classes:message
Subject: RE: [NSIS] Two kinds of requirements
Date: Wed, 16 Jan 2002 15:18:23 -0500
Message-ID: <62DA45D4963FA747BA1B253E266760F90116C2E3@OCCLUST04EVS1.ugd.att.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Thread-Topic: [NSIS] Two kinds of requirements
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
Thread-Index: AcGewYZzLAgWPwq0EdaSygAAwCUaDwACDTQA
From: "Roy, Radhika R, ALASO" <rrroy@att.com>
To: "Steven Berson" <berson@isi.edu>
Cc: "Michael Thomas" <mat@cisco.com>, <dick.rr.knight@bt.com>,
        <brian.williams@ericsson.com.au>, <lieve.bos@alcatel.be>,
        <nsis@ietf.org>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id PAA18624
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: Steven Berson [mailto:berson@isi.edu]
Sent: Wednesday, January 16, 2002 2:08 PM
To: Roy, Radhika R, ALASO
Cc: Michael Thomas; dick.rr.knight@bt.com;
brian.williams@ericsson.com.au; lieve.bos@alcatel.be; nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


On Wed, 16 Jan 2002, Roy, Radhika R, ALASO wrote:

> Hi, Mike:
> 
> Let me try.
> 
> For (a), RSVP has definitely some characteristics that can be used
> at the application layer on end-to-end basis. In fact, we have to
> look into RSVP, like SDPng, to examine all its features how we can
> exploit it for using in the application layer. We can then
> determine what we do when think that we need to develop a new QOS
> protocol.
> 
> However, it requires that RSVP needs to be used on end-to-end
> basis. If RSVP is used on end-to-end basis and if we all agree we
> do not need additional features (e.g., SDPng and/or others
> provide), it is definitely a good candidate to examine whether it
> meets all requirements.
> 
> What do we do when RSVP is not end-to-end? For example domain 1 =
> RSVP, domain 2 = DiffServ, and domain 3= RSVP. I guess that here
> it breaks down. One solution may be translation between RSVP and
> DiffServ. Then we loose the end-to-end picture.

I think this was adequately addressed in RFC 2998, ``A Framework for 
Integrated Services Operation over Diffserv Networks'' by Bernet, et 
al.

[RRR] It is a good point. If we look into RFC 2998, we will see that it will provide a good insight to develop our end-to-end application layer QOS (generic) signaling protocol. What we need to do to make it evolve in such a way that the end-to-end QOS signaling will be able satisfy any combinations of network layer QOS that has been implemented using RSVP, DiffServ, MPLS, and/or other means while testing RFC 2998's end-to-end scheme as one of the implementation schemes.

Regards,
Steve


 
> Hope this may help to answer your questions.
> 
> Radhika
> 
> -----Original Message-----
> From: Michael Thomas [mailto:mat@cisco.com]
> Sent: Wednesday, January 16, 2002 11:31 AM
> To: dick.rr.knight@bt.com
> Cc: brian.williams@ericsson.com.au; lieve.bos@alcatel.be; nsis@ietf.org
> Subject: RE: [NSIS] Two kinds of requirements
> 
> 
> 
> So, I'm really dumb here. Can somebody enumerate
> the *specific* things that are broken with RSVP?
> Before we run off designing new protocols, it
> would be nice to know a) what things the current
> protocols have problems with and b) whether the
> current protocols are fatally flawed in the face
> of those problems.
> 
> I know some in (a). I don't think they meet (b).
> 
> 	Mike
> 
> 
> _______________________________________________
> 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 Jan 16 16: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 QAA20962
	for <nsis-archive@odin.ietf.org>; Wed, 16 Jan 2002 16:05:43 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id QAA19669
	for nsis-archive@odin.ietf.org; Wed, 16 Jan 2002 16:05: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 QAA19591;
	Wed, 16 Jan 2002 16:01: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 QAA19564
	for <nsis@optimus.ietf.org>; Wed, 16 Jan 2002 16:01:24 -0500 (EST)
Received: from pea.isi.edu (pea.isi.edu [128.9.160.209])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20883
	for <nsis@ietf.org>; Wed, 16 Jan 2002 16:01:20 -0500 (EST)
Received: from localhost (berson@localhost)
	by pea.isi.edu (8.11.6/8.11.6) with ESMTP id g0GKwqc03080;
	Wed, 16 Jan 2002 12:58:52 -0800
X-Authentication-Warning: pea.isi.edu: berson owned process doing -bs
Date: Wed, 16 Jan 2002 12:58:52 -0800 (PST)
From: Steven Berson <berson@isi.edu>
To: "Roy, Radhika R, ALASO" <rrroy@att.com>
cc: Michael Thomas <mat@cisco.com>, <dick.rr.knight@bt.com>,
        <brian.williams@ericsson.com.au>, <lieve.bos@alcatel.be>,
        <nsis@ietf.org>
Subject: RE: [NSIS] Two kinds of requirements
In-Reply-To: <62DA45D4963FA747BA1B253E266760F90116C2E3@OCCLUST04EVS1.ugd.att.com>
Message-ID: <Pine.LNX.4.33.0201161246320.2979-100000@pea.isi.edu>
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 Wed, 16 Jan 2002, Roy, Radhika R, ALASO wrote:

> -----Original Message-----
> From: Steven Berson [mailto:berson@isi.edu]
> Sent: Wednesday, January 16, 2002 2:08 PM
> To: Roy, Radhika R, ALASO
> Cc: Michael Thomas; dick.rr.knight@bt.com;
> brian.williams@ericsson.com.au; lieve.bos@alcatel.be; nsis@ietf.org
> Subject: RE: [NSIS] Two kinds of requirements
> 
> 
> On Wed, 16 Jan 2002, Roy, Radhika R, ALASO wrote:
> 
> > Hi, Mike:
> > 
> > Let me try.
> > 
> > For (a), RSVP has definitely some characteristics that can be used
> > at the application layer on end-to-end basis. In fact, we have to
> > look into RSVP, like SDPng, to examine all its features how we can
> > exploit it for using in the application layer. We can then
> > determine what we do when think that we need to develop a new QOS
> > protocol.
> > 
> > However, it requires that RSVP needs to be used on end-to-end
> > basis. If RSVP is used on end-to-end basis and if we all agree we
> > do not need additional features (e.g., SDPng and/or others
> > provide), it is definitely a good candidate to examine whether it
> > meets all requirements.
> > 
> > What do we do when RSVP is not end-to-end? For example domain 1 =
> > RSVP, domain 2 = DiffServ, and domain 3= RSVP. I guess that here
> > it breaks down. One solution may be translation between RSVP and
> > DiffServ. Then we loose the end-to-end picture.
> 
> [Steve] I think this was adequately addressed in RFC 2998, ``A
> Framework for Integrated Services Operation over Diffserv
> Networks'' by Bernet, et al.
> 
> [RRR] It is a good point. If we look into RFC 2998, we will see
> that it will provide a good insight to develop our end-to-end
> application layer QOS (generic) signaling protocol. What we need
> to do to make it evolve in such a way that the end-to-end QOS
> signaling will be able satisfy any combinations of network layer
> QOS that has been implemented using RSVP, DiffServ, MPLS, and/or
> other means while testing RFC 2998's end-to-end scheme as one of
> the implementation schemes.

[Steve] I think RFC 2998 (Intserv over diffserv) over provides a
specific solution to the problem of end-to-end qos in the presence of
diffserv networks.  I further propose that RFC 2998 is a good start
for dealing with (for example) MPLS or other sub-ip technologies.  I
would be interested in hearing opposing opinions and rationale.

Regards,
Steve

> > Hope this may help to answer your questions.
> > 
> > Radhika
> > 
> > -----Original Message-----
> > From: Michael Thomas [mailto:mat@cisco.com]
> > Sent: Wednesday, January 16, 2002 11:31 AM
> > To: dick.rr.knight@bt.com
> > Cc: brian.williams@ericsson.com.au; lieve.bos@alcatel.be; nsis@ietf.org
> > Subject: RE: [NSIS] Two kinds of requirements
> > 
> > 
> > 
> > So, I'm really dumb here. Can somebody enumerate
> > the *specific* things that are broken with RSVP?
> > Before we run off designing new protocols, it
> > would be nice to know a) what things the current
> > protocols have problems with and b) whether the
> > current protocols are fatally flawed in the face
> > of those problems.
> > 
> > I know some in (a). I don't think they meet (b).
> > 
> > 	Mike
> > 
> > 
> > _______________________________________________
> > 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 Jan 16 16:35: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 QAA21430
	for <nsis-archive@odin.ietf.org>; Wed, 16 Jan 2002 16:35:07 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id QAA20595
	for nsis-archive@odin.ietf.org; Wed, 16 Jan 2002 16:35: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 QAA19842;
	Wed, 16 Jan 2002 16:16: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 QAA19808
	for <nsis@optimus.ietf.org>; Wed, 16 Jan 2002 16:16:08 -0500 (EST)
Received: from mail-server.comgates.co.il ([212.150.198.2])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21134
	for <nsis@ietf.org>; Wed, 16 Jan 2002 16:16:02 -0500 (EST)
Received: by mail-server.comgates.co.il with Internet Mail Service (5.5.2653.19)
	id <DC2CZXV3>; Wed, 16 Jan 2002 23:16:29 +0200
Message-ID: <6FEF757325DBD411B7DA000629A8A61E9AC63B@mail-server.comgates.co.il>
From: Yaron Kahana <ykahana@comgates.co.il>
To: brunner@ccrle.nec.de, "Geib, Ruediger" <Ruediger.Geib@t-systems.com>,
        dick.rr.knight@bt.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements
Date: Wed, 16 Jan 2002 23:16:28 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C19ED3.0FE1F840"
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_01C19ED3.0FE1F840
Content-Type: text/plain;
	charset="windows-1255"

Hello Ruediger, Marcus,

I agree with your comments. One of the crucial elements is the
pre-definition of the provider's policy - admission control decision tree,
QoS budgeting guides, CDR generation and considerations. Those could be done
in a practical manner only if there will be a rather small number of Service
classes (standardized services). I believe that this is by far the most
practical approach in a multi-providers environment. This QoS protocol
should be supported not only by the applications, the call control elements,
and transport routers but by the middleboxes, as well as the SLA/QoS
verification entities along the way and the billing elements.
We should try to keep it simple, even on the expense of full flexibility.

By the way - did anyone considered the problem of a non-cooperative IP
domain "in the middle" ? for example, Suppose I'm making a call from Los
Angeles to Munich through 3 domains - LA-NY, NY-London, London-Munich. What
will happen if the best/cheapest carrier along the NY-London domain won't
support this new protocol? Will he be condemned/ignored? When will he
upgrade his infrastructure, before the chicken or after the egg?

Yaron Kahana
COGITO Project Manager,
COMGATES

 -----Original Message-----
From: 	Marcus Brunner [mailto:brunner@ccrle.nec.de] 
Sent:	Wednesday, January 16, 2002 5:35 PM
To:	Geib, Ruediger; dick.rr.knight@bt.com
Cc:	nsis@ietf.org
Subject:	RE: [NSIS] Two kinds of requirements

Ruediger,

The service needs to be defined anyway. Then there are IMO two 
possibilities
- the provider defines the services and offers them. In this case the 
provider needs to describe the offers in a machine readable form (most 
likely with parameter names and values)
- the consumer requests a particular service (this means the consumer has 
to describe the service he wants in a machine readable form)

So it seams one has to move around service specifications which are 
understandable by the other party anyway, what is now your point? Is it 
that you want to limit/fix as many parameters as possible? Or are you more 
think about standardized services everybody understands?

Marcus

--On Wednesday, January 16, 2002 3:45 PM +0100 "Geib, Ruediger" 
<Ruediger.Geib@t-systems.com> wrote:

> Hello Dick,
>
> your suggestion is quite reasonable. I also favour an architecture where
> a QoS request by and large is predefined in terms of the resources
> required from the available transport mechanism. Service specific
> parameters to be signaled during reservation should be strictly limited.
> The more mapping and evaluation of QoS parameters is required during
> reservation, the more complex the service gets. Complex services are hard
> to sell and hard to provide.
>
> Regards,
>
> R?diger
>
> R?diger Geib
> Senior Project Manager
> T-Systems Nova GmbH
>
>> I think that what is needed is a new protocol that can signal the
>> requirements of any session and can be satisfied by any QoS
>> mechanism, existing or new.
>> To be more precise, I am suggesting a new protocol that is
>> independent of the underlying transport technology and the QoS
>> implemented and is also independent of the session control
>> protocol. Such a new protocol would be generic, optionally
>> implemented by applications that would benefit from
>> end-to-end QoS, and would be complimentary to the QoS
>> mechanisms deployed (and of course other mechanisms,
>> such as the routing).
>>
>> I think that this implies a more abstract definition of the
>> QoS mechanism and may lend itself to the signalling of
>> pre-defined QoS classes rather than parameters.
>>
>> Dick Knight
>
>
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis
>



--------------------------------------
Dr. Marcus Brunner
Network Laboratories
NEC Europe Ltd.

E-Mail: brunner@ccrle.nec.de
WWW:    http://www.ccrle.nec.de/
personal home page: http://www.brubers.org/marcus



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

------_=_NextPart_001_01C19ED3.0FE1F840
Content-Type: text/html;
	charset="windows-1255"
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=3Dwindows-1255">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>RE: [NSIS] Two kinds of requirements</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Hello Ruediger, Marcus,</FONT>
</P>

<P><FONT SIZE=3D2>I agree with your comments. One of the crucial =
elements is the pre-definition of the provider's policy - admission =
control decision tree, QoS budgeting guides, CDR generation and =
considerations. Those could be done in a practical manner only if there =
will be a rather small number of Service classes (standardized =
services). I believe that this is by far the most practical approach in =
a multi-providers environment. This QoS protocol should be supported =
not only by the applications, the call control elements, and transport =
routers but by the middleboxes, as well as the SLA/QoS verification =
entities along the way and the billing elements.</FONT></P>

<P><FONT SIZE=3D2>We should try to keep it simple, even on the expense =
of full flexibility.</FONT>
</P>

<P><FONT SIZE=3D2>By the way - did anyone considered the problem of a =
non-cooperative IP domain &quot;in the middle&quot; ? for example, =
Suppose I'm making a call from Los Angeles to Munich through 3 domains =
- LA-NY, NY-London, London-Munich. What will happen if the =
best/cheapest carrier along the NY-London domain won't support this new =
protocol? Will he be condemned/ignored? When will he upgrade his =
infrastructure, before the chicken or after the egg?</FONT></P>

<P><FONT SIZE=3D2>Yaron Kahana</FONT>
<BR><FONT SIZE=3D2>COGITO Project Manager,</FONT>
<BR><FONT SIZE=3D2>COMGATES</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: &nbsp; Marcus Brunner [<A =
HREF=3D"mailto:brunner@ccrle.nec.de">mailto:brunner@ccrle.nec.de</A>] =
</FONT>
<BR><FONT SIZE=3D2>Sent:&nbsp;&nbsp; Wednesday, January 16, 2002 5:35 =
PM</FONT>
<BR><FONT SIZE=3D2>To:&nbsp;&nbsp;&nbsp;&nbsp; Geib, Ruediger; =
dick.rr.knight@bt.com</FONT>
<BR><FONT SIZE=3D2>Cc:&nbsp;&nbsp;&nbsp;&nbsp; nsis@ietf.org</FONT>
<BR><FONT SIZE=3D2>Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
RE: [NSIS] Two kinds of requirements</FONT>
</P>

<P><FONT SIZE=3D2>Ruediger,</FONT>
</P>

<P><FONT SIZE=3D2>The service needs to be defined anyway. Then there =
are IMO two </FONT>
<BR><FONT SIZE=3D2>possibilities</FONT>
<BR><FONT SIZE=3D2>- the provider defines the services and offers them. =
In this case the </FONT>
<BR><FONT SIZE=3D2>provider needs to describe the offers in a machine =
readable form (most </FONT>
<BR><FONT SIZE=3D2>likely with parameter names and values)</FONT>
<BR><FONT SIZE=3D2>- the consumer requests a particular service (this =
means the consumer has </FONT>
<BR><FONT SIZE=3D2>to describe the service he wants in a machine =
readable form)</FONT>
</P>

<P><FONT SIZE=3D2>So it seams one has to move around service =
specifications which are </FONT>
<BR><FONT SIZE=3D2>understandable by the other party anyway, what is =
now your point? Is it </FONT>
<BR><FONT SIZE=3D2>that you want to limit/fix as many parameters as =
possible? Or are you more </FONT>
<BR><FONT SIZE=3D2>think about standardized services everybody =
understands?</FONT>
</P>

<P><FONT SIZE=3D2>Marcus</FONT>
</P>

<P><FONT SIZE=3D2>--On Wednesday, January 16, 2002 3:45 PM +0100 =
&quot;Geib, Ruediger&quot; </FONT>
<BR><FONT SIZE=3D2>&lt;Ruediger.Geib@t-systems.com&gt; wrote:</FONT>
</P>

<P><FONT SIZE=3D2>&gt; Hello Dick,</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; your suggestion is quite reasonable. I also =
favour an architecture where</FONT>
<BR><FONT SIZE=3D2>&gt; a QoS request by and large is predefined in =
terms of the resources</FONT>
<BR><FONT SIZE=3D2>&gt; required from the available transport =
mechanism. Service specific</FONT>
<BR><FONT SIZE=3D2>&gt; parameters to be signaled during reservation =
should be strictly limited.</FONT>
<BR><FONT SIZE=3D2>&gt; The more mapping and evaluation of QoS =
parameters is required during</FONT>
<BR><FONT SIZE=3D2>&gt; reservation, the more complex the service gets. =
Complex services are hard</FONT>
<BR><FONT SIZE=3D2>&gt; to sell and hard to provide.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; Regards,</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; R&uuml;diger</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; R&uuml;diger Geib</FONT>
<BR><FONT SIZE=3D2>&gt; Senior Project Manager</FONT>
<BR><FONT SIZE=3D2>&gt; T-Systems Nova GmbH</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; I think that what is needed is a new =
protocol that can signal the</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; requirements of any session and can be =
satisfied by any QoS</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; mechanism, existing or new.</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; To be more precise, I am suggesting a new =
protocol that is</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; independent of the underlying transport =
technology and the QoS</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; implemented and is also independent of the =
session control</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; protocol. Such a new protocol would be =
generic, optionally</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; implemented by applications that would =
benefit from</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; end-to-end QoS, and would be complimentary =
to the QoS</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; mechanisms deployed (and of course other =
mechanisms,</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; such as the routing).</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; I think that this implies a more abstract =
definition of the</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; QoS mechanism and may lend itself to the =
signalling of</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; pre-defined QoS classes rather than =
parameters.</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; Dick Knight</FONT>
<BR><FONT SIZE=3D2>&gt;</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>
<BR>
<BR>

<P><FONT SIZE=3D2>--------------------------------------</FONT>
<BR><FONT SIZE=3D2>Dr. Marcus Brunner</FONT>
<BR><FONT SIZE=3D2>Network Laboratories</FONT>
<BR><FONT SIZE=3D2>NEC Europe Ltd.</FONT>
</P>

<P><FONT SIZE=3D2>E-Mail: brunner@ccrle.nec.de</FONT>
<BR><FONT SIZE=3D2>WWW:&nbsp;&nbsp;&nbsp; <A =
HREF=3D"http://www.ccrle.nec.de/" =
TARGET=3D"_blank">http://www.ccrle.nec.de/</A></FONT>
<BR><FONT SIZE=3D2>personal home page: <A =
HREF=3D"http://www.brubers.org/marcus" =
TARGET=3D"_blank">http://www.brubers.org/marcus</A></FONT>
</P>
<BR>
<BR>

<P><FONT =
SIZE=3D2>_______________________________________________</FONT>
<BR><FONT SIZE=3D2>nsis mailing list</FONT>
<BR><FONT SIZE=3D2>nsis@ietf.org</FONT>
<BR><FONT SIZE=3D2><A =
HREF=3D"https://www1.ietf.org/mailman/listinfo/nsis" =
TARGET=3D"_blank">https://www1.ietf.org/mailman/listinfo/nsis</A></FONT>=

</P>

</BODY>
</HTML>
------_=_NextPart_001_01C19ED3.0FE1F840--

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



From daemon@optimus.ietf.org  Wed Jan 16 16:39: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 QAA21487
	for <nsis-archive@odin.ietf.org>; Wed, 16 Jan 2002 16:39:59 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id QAA20675
	for nsis-archive@odin.ietf.org; Wed, 16 Jan 2002 16:40: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 QAA20013;
	Wed, 16 Jan 2002 16:21: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 QAA19979
	for <nsis@optimus.ietf.org>; Wed, 16 Jan 2002 16:21:27 -0500 (EST)
Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21215
	for <nsis@ietf.org>; Wed, 16 Jan 2002 16:21:18 -0500 (EST)
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id g0GLKDG00434;
	Wed, 16 Jan 2002 13:20:13 -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 AAR61063;
	Wed, 16 Jan 2002 13:19:41 -0800 (PST)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA16572; Wed, 16 Jan 2002 13:20:13 -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: <15429.61068.961846.979163@thomasm-u1.cisco.com>
Date: Wed, 16 Jan 2002 13:20:12 -0800 (PST)
To: Yaron Kahana <ykahana@comgates.co.il>
Cc: brunner@ccrle.nec.de, "Geib, Ruediger" <Ruediger.Geib@t-systems.com>,
        dick.rr.knight@bt.com, nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements
In-Reply-To: <6FEF757325DBD411B7DA000629A8A61E9AC63B@mail-server.comgates.co.il>
References: <6FEF757325DBD411B7DA000629A8A61E9AC63B@mail-server.comgates.co.il>
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


> I agree with your comments. One of the crucial elements is the
> pre-definition of the provider's policy - admission control decision tree,
> QoS budgeting guides, CDR generation and considerations. Those could be done
> in a practical manner only if there will be a rather small number of Service
> classes (standardized services). 

What might those service classes be?

	   Mike

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



From daemon@optimus.ietf.org  Wed Jan 16 17:00: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 RAA21924
	for <nsis-archive@odin.ietf.org>; Wed, 16 Jan 2002 17:00:37 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id RAA21532
	for nsis-archive@odin.ietf.org; Wed, 16 Jan 2002 17: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 QAA20740;
	Wed, 16 Jan 2002 16:41:42 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA20707
	for <nsis@optimus.ietf.org>; Wed, 16 Jan 2002 16:41:39 -0500 (EST)
Received: from mail-server.comgates.co.il ([212.150.198.2])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21536
	for <nsis@ietf.org>; Wed, 16 Jan 2002 16:41:34 -0500 (EST)
Received: by mail-server.comgates.co.il with Internet Mail Service (5.5.2653.19)
	id <DC2CZXVW>; Wed, 16 Jan 2002 23:41:58 +0200
Message-ID: <6FEF757325DBD411B7DA000629A8A61E7BAD2F@mail-server.comgates.co.il>
From: Yaron Kahana <ykahana@comgates.co.il>
To: Michael Thomas <mat@cisco.com>
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements
Date: Wed, 16 Jan 2002 23:41:58 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C19ED6.9F99C7D0"
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_01C19ED6.9F99C7D0
Content-Type: text/plain;
	charset="windows-1255"

Those should some selective, representative classes.
There is a work by ETSI on QoS classes (TIPHON ETSI TS 101 329 - 2 V2.1.3)
yet this is oriented to realtime voice and video. 

If you'll get into gaming, you'll need to control not only the lower level
of grade of service (Delay must be lower than Xms), but the upper limit as
well (delay should not be less than Yms), otherwise, the closest player to
the server will shut down the other players.

My native response is to seek for the definition of several "top classes"
(Very Low delay, Low delay, Very Low loss, controlled delay, etc). This may
become ugly when people will consider voice quality of service in MOS like
figures instead of max delay and max loss for a given BW, since this may
brake the rules of engagement and verification.

Yaron Kahana
COGITO Project Manager,
COMGATES.
www.COMGATES.com


 -----Original Message-----
From: 	Michael Thomas [mailto:mat@cisco.com] 
Sent:	Wednesday, January 16, 2002 11:20 PM
To:	Yaron Kahana
Cc:	brunner@ccrle.nec.de; Geib, Ruediger; dick.rr.knight@bt.com;
nsis@ietf.org
Subject:	RE: [NSIS] Two kinds of requirements


> I agree with your comments. One of the crucial elements is the
> pre-definition of the provider's policy - admission control decision tree,
> QoS budgeting guides, CDR generation and considerations. Those could be
done
> in a practical manner only if there will be a rather small number of
Service
> classes (standardized services). 

What might those service classes be?

	   Mike

------_=_NextPart_001_01C19ED6.9F99C7D0
Content-Type: text/html;
	charset="windows-1255"
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=3Dwindows-1255">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>RE: [NSIS] Two kinds of requirements</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Those should some selective, representative =
classes.</FONT>
<BR><FONT SIZE=3D2>There is a work by ETSI on QoS classes (TIPHON ETSI =
TS 101 329 - 2 V2.1.3) yet this is oriented to realtime voice and =
video. </FONT></P>

<P><FONT SIZE=3D2>If you'll get into gaming, you'll need to control not =
only the lower level of grade of service (Delay must be lower than =
Xms), but the upper limit as well (delay should not be less than Yms), =
otherwise, the closest player to the server will shut down the other =
players.</FONT></P>

<P><FONT SIZE=3D2>My native response is to seek for the definition of =
several &quot;top classes&quot; (Very Low delay, Low delay, Very Low =
loss, controlled delay, etc). This may become ugly when people will =
consider voice quality of service in MOS like figures instead of max =
delay and max loss for a given BW, since this may brake the rules of =
engagement and verification.</FONT></P>

<P><FONT SIZE=3D2>Yaron Kahana</FONT>
<BR><FONT SIZE=3D2>COGITO Project Manager,</FONT>
<BR><FONT SIZE=3D2>COMGATES.</FONT>
<BR><FONT SIZE=3D2>www.COMGATES.com</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>&nbsp;-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: &nbsp; Michael Thomas [<A =
HREF=3D"mailto:mat@cisco.com">mailto:mat@cisco.com</A>] </FONT>
<BR><FONT SIZE=3D2>Sent:&nbsp;&nbsp; Wednesday, January 16, 2002 11:20 =
PM</FONT>
<BR><FONT SIZE=3D2>To:&nbsp;&nbsp;&nbsp;&nbsp; Yaron Kahana</FONT>
<BR><FONT SIZE=3D2>Cc:&nbsp;&nbsp;&nbsp;&nbsp; brunner@ccrle.nec.de; =
Geib, Ruediger; dick.rr.knight@bt.com; nsis@ietf.org</FONT>
<BR><FONT SIZE=3D2>Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
RE: [NSIS] Two kinds of requirements</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>&gt; I agree with your comments. One of the crucial =
elements is the</FONT>
<BR><FONT SIZE=3D2>&gt; pre-definition of the provider's policy - =
admission control decision tree,</FONT>
<BR><FONT SIZE=3D2>&gt; QoS budgeting guides, CDR generation and =
considerations. Those could be done</FONT>
<BR><FONT SIZE=3D2>&gt; in a practical manner only if there will be a =
rather small number of Service</FONT>
<BR><FONT SIZE=3D2>&gt; classes (standardized services). </FONT>
</P>

<P><FONT SIZE=3D2>What might those service classes be?</FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =
SIZE=3D2>&nbsp;&nbsp; Mike</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C19ED6.9F99C7D0--

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



From daemon@optimus.ietf.org  Wed Jan 16 23:21: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 XAA29106
	for <nsis-archive@odin.ietf.org>; Wed, 16 Jan 2002 23:21:48 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id XAA03411
	for nsis-archive@odin.ietf.org; Wed, 16 Jan 2002 23:21: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 XAA03357;
	Wed, 16 Jan 2002 23:20: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 XAA03294
	for <nsis@optimus.ietf.org>; Wed, 16 Jan 2002 23:20:31 -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 XAA29093
	for <nsis@ietf.org>; Wed, 16 Jan 2002 23:20:26 -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 g0H4MVT25312;
	Wed, 16 Jan 2002 22:22:31 -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 g0H4JKN16881;
	Wed, 16 Jan 2002 22:19:20 -0600 (CST)
Received: by TRIMAIL2.ad.tri.sbc.com with Internet Mail Service (5.5.2653.19)
	id <ZND321C4>; Wed, 16 Jan 2002 22:19:47 -0600
Message-ID: <905A1C4ABF353F4C8CC16FA9F53DD0D632241C@TRIMAIL2.ad.tri.sbc.com>
From: "Chen, Weijing" <wchen@tri.sbc.com>
To: "'Roy, Radhika R, ALASO'" <rrroy@att.com>,
        Steven Berson
	 <berson@isi.edu>
Cc: Michael Thomas <mat@cisco.com>, dick.rr.knight@bt.com,
        brian.williams@ericsson.com.au, lieve.bos@alcatel.be, nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements
Date: Wed, 16 Jan 2002 22:19:46 -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

Roy, Dick, etc

Let me re-phrase the requirements from a telco-head (or bell-head) point of
view to see if this is the right stuff in your mind:

What we need is a signaling protocol simply from user to network (edge) for
user to tell network where he wants to go and what QoS associated with it.
The network can accommodate the QoS through whichever means, e.g. set up an
ATM SVC, MPLS LSP path, route through IP network, route with IP reservation,
etc. And this signaling protocol message must be deliverable through a
multiprotocol network. It also must be able to carry different QoS
parameters with proper data flow classifier (IP flow, MPLS LSP path, SVC
VPI/VCI, etc.)

This signaling protocol is more like DTMF in POTS network. It is universal
and simple, yet effective. Once dialing digits getting into network,
different network will have different SS7 (North America SS7, Europe SS7,
Illinois SS7, China SS7) to handle the request. Same with this signaling
protocol, different network will have different NNI (CR-LDP, RSVP-TE, PNNI,
etc) for it. The signaling between the network could be solved through
signaling gateway.

Therefore this signaling protocol is end-to-end from service aspect, but is
only end-to-network and network-to-end from network aspect. The
network-to-network part is intentionally left out.

Up to recently, most of QoS effort is focusing on QoS parameters mapping
among different network layer. It is a necessary work, but not enough. It
has missed half of equation, which is how the user explicitly tells the
network what QoS he need. After that, let the network worry about how to
satisfy the QoS for which there are a lot of available solutions. 

--
Weijing Chen
SBC Technology Resources
9505 Arboretum Blvd.
Austin, TX 78759
512 372 5710
wchen@tri.sbc.com



 -----Original Message-----
From: 	Roy, Radhika R, ALASO [mailto:rrroy@att.com] 
Sent:	Wednesday, January 16, 2002 2:18 PM
To:	Steven Berson
Cc:	Michael Thomas; dick.rr.knight@bt.com;
brian.williams@ericsson.com.au; lieve.bos@alcatel.be; nsis@ietf.org
Subject:	RE: [NSIS] Two kinds of requirements



-----Original Message-----
From: Steven Berson [mailto:berson@isi.edu]
Sent: Wednesday, January 16, 2002 2:08 PM
To: Roy, Radhika R, ALASO
Cc: Michael Thomas; dick.rr.knight@bt.com;
brian.williams@ericsson.com.au; lieve.bos@alcatel.be; nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


On Wed, 16 Jan 2002, Roy, Radhika R, ALASO wrote:

> Hi, Mike:
> 
> Let me try.
> 
> For (a), RSVP has definitely some characteristics that can be used
> at the application layer on end-to-end basis. In fact, we have to
> look into RSVP, like SDPng, to examine all its features how we can
> exploit it for using in the application layer. We can then
> determine what we do when think that we need to develop a new QOS
> protocol.
> 
> However, it requires that RSVP needs to be used on end-to-end
> basis. If RSVP is used on end-to-end basis and if we all agree we
> do not need additional features (e.g., SDPng and/or others
> provide), it is definitely a good candidate to examine whether it
> meets all requirements.
> 
> What do we do when RSVP is not end-to-end? For example domain 1 =
> RSVP, domain 2 = DiffServ, and domain 3= RSVP. I guess that here
> it breaks down. One solution may be translation between RSVP and
> DiffServ. Then we loose the end-to-end picture.

I think this was adequately addressed in RFC 2998, ``A Framework for 
Integrated Services Operation over Diffserv Networks'' by Bernet, et 
al.

[RRR] It is a good point. If we look into RFC 2998, we will see that it will
provide a good insight to develop our end-to-end application layer QOS
(generic) signaling protocol. What we need to do to make it evolve in such a
way that the end-to-end QOS signaling will be able satisfy any combinations
of network layer QOS that has been implemented using RSVP, DiffServ, MPLS,
and/or other means while testing RFC 2998's end-to-end scheme as one of the
implementation schemes.

Regards,
Steve


 
> Hope this may help to answer your questions.
> 
> Radhika
> 
> -----Original Message-----
> From: Michael Thomas [mailto:mat@cisco.com]
> Sent: Wednesday, January 16, 2002 11:31 AM
> To: dick.rr.knight@bt.com
> Cc: brian.williams@ericsson.com.au; lieve.bos@alcatel.be; nsis@ietf.org
> Subject: RE: [NSIS] Two kinds of requirements
> 
> 
> 
> So, I'm really dumb here. Can somebody enumerate
> the *specific* things that are broken with RSVP?
> Before we run off designing new protocols, it
> would be nice to know a) what things the current
> protocols have problems with and b) whether the
> current protocols are fatally flawed in the face
> of those problems.
> 
> I know some in (a). I don't think they meet (b).
> 
> 	Mike
> 
> 
> _______________________________________________
> 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  Thu Jan 17 00:24: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 AAA00209
	for <nsis-archive@odin.ietf.org>; Thu, 17 Jan 2002 00:24:30 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id AAA05699
	for nsis-archive@odin.ietf.org; Thu, 17 Jan 2002 00:24: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 AAA05662;
	Thu, 17 Jan 2002 00:23: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 KAA04974
	for <nsis@optimus.ietf.org>; Wed, 16 Jan 2002 10:22:51 -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 KAA10874
	for <nsis@ietf.org>; Wed, 16 Jan 2002 10:22:46 -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 g0GFOoT09403;
	Wed, 16 Jan 2002 09:24:50 -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 g0GFLqf22052;
	Wed, 16 Jan 2002 09:21:52 -0600 (CST)
Received: by TRIMAIL2.ad.tri.sbc.com with Internet Mail Service (5.5.2653.19)
	id <ZND32AAB>; Wed, 16 Jan 2002 09:22:18 -0600
Message-ID: <905A1C4ABF353F4C8CC16FA9F53DD0D6322410@TRIMAIL2.ad.tri.sbc.com>
From: "Chen, Weijing" <wchen@tri.sbc.com>
To: "Chen, Weijing" <wchen@tri.sbc.com>,
        "'dick.rr.knight@bt.com'"
	 <dick.rr.knight@bt.com>,
        brian.williams@ericsson.com.au, lieve.bos@alcatel.be
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements
Date: Wed, 16 Jan 2002 09:22:17 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_000_01C19EA1.957FD2B0"
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_000_01C19EA1.957FD2B0
Content-Type: text/plain;
	charset="iso-8859-1"


 -----Original Message-----
From: 	Chen, Weijing  
Sent:	Wednesday, January 16, 2002 9:06 AM
To:	'dick.rr.knight@bt.com'; brian.williams@ericsson.com.au;
lieve.bos@alcatel.be
Cc:	nsis@ietf.org
Subject:	RE: [NSIS] Two kinds of requirements

I am in pretty much agreement of Dick's comment. I guessed that service
operator has similar need. To elaborate more, I have the following diagram:

[ Oops, I missed a picture here:

 <<muni.pdf>> 

]

 












In here MUNI (Multiprotocol UNI) signaling protocol is the ONE we need from
NSIS. It must have the following criteria:

1. Where: MUNI signaling must support destination on demand.
2. How: MUNI signaling must support QoS (bandwidth, delay, delay variance)
on demand.
3. Multiprotocol: MUNI signaling must be multiprotocol.  a) Signaling
message must be delivered over a multiprotocol network. b) MUNI signaling
must support multiple data stream classifier: IP flow (src/dst address,
port, CoS), MPLS label, VLAN label, MAC address, PPPoE session id, ATM
VPI/VCI, FR DLCI, etc....
4. Independence: MUNI signaling must be independent of the "core" network
technology and signaling (NNI and NNI signaling). a) Separation of MUNI from
NNI ensures a simple and widespread MUNI in PC, network appliance, set top,
gateway, router, switch, wireless handset, etc... b) Separation of MUNI from
NNI also ensures a portable access device market. 

Therefore the scope and requirement of NSIS should be focused on the above.
An extension and modification of RSVP is most likely solution. However we
are flexible to listen to other suggestions.

How the MUNI QoS request and MUNI session mapping onto network NNI QoS and
NNI session may not be the scope of NSIS. Regardless, the following are
several potential mapping schemes:
1. Dedicated trunk connection: One subscriber session per trunk connection.
Ex. ATM SVC (Layer 2) and IP RSVP (Layer 3), MPLS (Layer 2 and 3)
2. Shared trunk connection: Multiple subscriber sessions per trunk
connection. Subscriber session QoS is managed by CAC function of trunk
connection. Ex. a) Best effort: Extreme case of shared trunk connection -
one trunk connection per network with no CAC but best effort.  b) Priority
QoS: Elastic shared trunk connection with CAC by priority only. c) Trunk
reservation: Shared trunk connection with proper CAC. Shared trunk
connections are dynamically pre-reserved between network access nodes with
guaranteed aggregated bandwidth. Individual sessions are admitted into these
trunks provided that the total requested bandwidth of the sessions does not
exceed capacity limit of trunk bandwidth. When the known aggregate bandwidth
approaches the capacity limit, a new trunk is setup through signaling
mechanisms, ex. MPLS (Layer 2 and 3),  ATM PNNI (Layer 2).

--
Weijing Chen
SBC Technology Resources
9505 Arboretum Blvd.
Austin, TX 78759
512 372 5710
wchen@tri.sbc.com

This e-mail and any files transmitted with it are the property of SBC, are
confidential, and are intended solely for the use of the individual or
entity to whom this e-mail is addressed.  If you are not one of the named
recipient(s) or otherwise have reason to believe that you have received this
message in error, please notify the sender at 512 372-5710 and delete this
message immediately from your computer.  Any other use, retention,
dissemination, forwarding, printing, or copying of this e-mail is strictly
prohibited.


 -----Original Message-----
From: 	dick.rr.knight@bt.com [mailto:dick.rr.knight@bt.com] 
Sent:	Wednesday, January 16, 2002 6:00 AM
To:	brian.williams@ericsson.com.au; lieve.bos@alcatel.be
Cc:	nsis@ietf.org
Subject:	RE: [NSIS] Two kinds of requirements

I was waiting for some reaction to Brian's comments, but as there aren't
any, here are my thoughts on the requirements:

I agree with the analysis that discussion has been based around
application-related signalling for QoS (at session level) and QoS signalling
protocols used to actually provision the QoS at the transport level.
Brian is right that there will never be an enhancement to a single session
protocol that will satisfy all applications.
However, for similar reasons, it is never going to be possible to prescribe
a single QoS mechanism to be used in all networks. Existing networks (or
domains) will not be changed overnight and new networks already face several
workable mechanisms to deploy QoS.

I think that what is needed is a new protocol that can signal the
requirements of any session and can be satisfied by any QoS mechanism,
existing or new.
To be more precise, I am suggesting a new protocol that is independent of
the underlying transport technology and the QoS implemented and is also
independent of the session control protocol. Such a new protocol would be
generic, optionally implemented by applications that would benefit from
end-to-end QoS, and would be complimentary to the QoS mechanisms deployed
(and of course other mechanisms, such as the routing).

I think that this implies a more abstract definition of the QoS mechanism
and may lend itself to the signalling of pre-defined QoS classes rather than
parameters.

Dick Knight

-----Original Message-----
From: Brian Williams [mailto:brian.williams@ericsson.com.au]
Sent: 22 December 2001 23:57
To: lieve.bos@alcatel.be
Cc: nsis@ietf.org
Subject: Re: [NSIS] Two kinds of requirements


Hi.
While the two types of signalling may be related, I think there is a
need to develop a QoS bearer mechanism which is independent of any
specific session signalling, and thus can be used for any application. I
believe many of the applications which have identified requirements to
the working group have their own specific session layer signalling (ie
it is not end-to-end SIP).  

Having the session and transport protocols developed separately of
course does not prohibit the two being used in conjunction for a
specific application.
/brian
 
On Fri, 2001-12-21 at 22:24, lieve.bos@alcatel.be wrote:
> Hello all,
> 
> >From the discussion in Salt Lake city and the drafts submitted, one can
> easily see that people are suggesting improvements to QoS signalling at
> two totally different levels (some at session level and some at
> transport level).
> 
> First of all, there are drafts suggesting some improvements in the
> session setup procedures (i.e. the ability to negotiate the preferred
> QoS level between end users during SDP negotiation in SIP, so before the
> actual resources are being setup). The QoS information negotiated at the
> session layer determines the QoS level both endusers have to use for 
> their local access connection. This first kind of 'session level QoS
> negotiation' happens end-to-end between the two end-users.
> 
> Secondly, there are drafts suggesting that we need
> improvements/alternatives for the QoS signalling protocols (e.g. RSVP)
> used to actually provision the QoS at the transport level between two
> endusers. This second kind of 'transport level QoS signalling' can
> consist of several phases: end-to-edge and edge-to-edge. 
> 
> It's important that everybody realises that, in order to give endusers
> true end-to-end Quality of Service, we need improvements for QoS both at
> session and transport level. Also its important to understand that they
> are not uncorrelated. Providers want to be able to control (e.g. via
> policy control mechanisms) that the QoS requested at the transport level
> is not exceeding the QoS negotiated/authorised previously at session
> level. So, what about developing in NSIS a modular framework
> incorporating both session and transport level QoS signalling with
> possible hooks between the two layers (e.g. for policy enforcement).
> 
> Lieve
> 
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis



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

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

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

------_=_NextPart_000_01C19EA1.957FD2B0
Content-Type: application/octet-stream;
	name="muni.pdf"
Content-Disposition: attachment;
	filename="muni.pdf"
Content-Transfer-Encoding: base64

JVBERi0xLjMNJeLjz9MNCjYgMCBvYmoNPDwgDS9MaW5lYXJpemVkIDEgDS9PIDkgDS9IIFsgMTAx
MiAxODMgXSANL0wgNDE2ODkgDS9FIDM5OTU0IA0vTiAxIA0vVCA0MTQ1MiANPj4gDWVuZG9iag0g
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICB4cmVmDTYgMTcgDTAwMDAwMDAwMTYgMDAwMDAgbg0KMDAwMDAwMDcwMCAwMDAwMCBuDQowMDAw
MDAwODYyIDAwMDAwIG4NCjAwMDAwMDExOTUgMDAwMDAgbg0KMDAwMDAwMTM1MCAwMDAwMCBuDQow
MDAwMDAxNDk3IDAwMDAwIG4NCjAwMDAwMDE1MzYgMDAwMDAgbg0KMDAwMDAwNDI2NiAwMDAwMCBu
DQowMDAwMDA0NDkyIDAwMDAwIG4NCjAwMDAwMDQ5MjMgMDAwMDAgbg0KMDAwMDAwNTE0NSAwMDAw
MCBuDQowMDAwMDA1NTg0IDAwMDAwIG4NCjAwMDAwMjE2NDAgMDAwMDAgbg0KMDAwMDAzNzE2OCAw
MDAwMCBuDQowMDAwMDM5ODQ2IDAwMDAwIG4NCjAwMDAwMDEwMTIgMDAwMDAgbg0KMDAwMDAwMTE3
NSAwMDAwMCBuDQp0cmFpbGVyDTw8DS9TaXplIDIzDS9JbmZvIDQgMCBSIA0vRW5jcnlwdCA4IDAg
UiANL1Jvb3QgNyAwIFIgDS9QcmV2IDQxNDQzIA0vSURbPDRkZmQ2YjQwZTAzMTQyMDg3NzBkNmU5
OTgxNmE0ZGMxPjw1ZTE0MzMwNjQ0YmQ2NGVhYThmYWU2YWUwYTRlZmIxND5dDT4+DXN0YXJ0eHJl
Zg0wDSUlRU9GDSAgICAgDTcgMCBvYmoNPDwgDS9UeXBlIC9DYXRhbG9nIA0vUGFnZXMgMyAwIFIg
DS9NZXRhZGF0YSA1IDAgUiANL09wZW5BY3Rpb24gWyA5IDAgUiAvRml0IF0gDS9QYWdlTW9kZSAv
VXNlTm9uZSANL1BhZ2VMYXlvdXQgL1NpbmdsZVBhZ2UgDS9QYWdlTGFiZWxzIDIgMCBSIA0+PiAN
ZW5kb2JqDTggMCBvYmoNPDwgDS9GaWx0ZXIgL1N0YW5kYXJkIA0vUiAyIA0vTyAoIFXHVscuGtcC
YI6BlqytRHrTLRfP9YMjX23RX+19q2cpDS9VIChbqybsLbZbSEBTTG7JHJO7p26rxsJDskz162UX
PIq27CkNL1AgLTEyIA0vViAxIA0vTGVuZ3RoIDQwIA0+PiANZW5kb2JqDTIxIDAgb2JqDTw8IC9T
IDM2IC9MIDgzIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9MZW5ndGggMjIgMCBSID4+IA1zdHJlYW0N
Ci5CWlKgemf9PinhffL8I99U1Bvu+oD7Bx4WWaEF2Xt6ubyl3Z7mUTOQurq7bUldBF4PjXrL9eC/
SpzybMKEn4dNIZo2ArVxnjANZW5kc3RyZWFtDWVuZG9iag0yMiAwIG9iag03MyANZW5kb2JqDTkg
MCBvYmoNPDwgDS9UeXBlIC9QYWdlIA0vUGFyZW50IDMgMCBSIA0vUmVzb3VyY2VzIDEwIDAgUiAN
L0NvbnRlbnRzIDEyIDAgUiANL1JvdGF0ZSA5MCANL01lZGlhQm94IFsgMCAwIDYxMiA3OTIgXSAN
L0Nyb3BCb3ggWyAzNyAzNyA1NzUgNzU1IF0gDT4+IA1lbmRvYmoNMTAgMCBvYmoNPDwgDS9Qcm9j
U2V0IFsgL1BERiAvVGV4dCBdIA0vRm9udCA8PCAvVFQyIDE0IDAgUiAvVFQ0IDE2IDAgUiA+PiAN
L0V4dEdTdGF0ZSA8PCAvR1MxIDIwIDAgUiA+PiANL0NvbG9yU3BhY2UgPDwgL0NzNiAxMSAwIFIg
Pj4gDT4+IA1lbmRvYmoNMTEgMCBvYmoNWyANL0lDQ0Jhc2VkIDE5IDAgUiANXQ1lbmRvYmoNMTIg
MCBvYmoNPDwgL0xlbmd0aCAyNjU0IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCscR
0hsHVZba0DKhZi9Qvt7r3CsmQ3NZA+O3k1Y0DgfGSvoDqizD3fqj2mL6ugBJzLNtCQ2nAFdqw32g
H5wVTaB4I81Tn0km0y/lqCGkUzY4vl8tgJiENRcYFUSM1gF06eT7Nu736XS2FM6x5JHWPk4sphMy
+2BZv3e3IB6DABUa0m33V5G1039UN+wnwu0i/WuFb/6h6KSGDKJt5MzG/uLtOoWUt7X4CJ0c8HMd
Vzow1qTNd4XrydPq1ip/9uA5yUjDUTcA9TKyxB7HvSza4zI7TggsYKpU6o0Nc0gECGwCjJjsjIGo
1tpXZjSCFCsJbQuxY8E7qqnMIB/jMgCYfIXUcKKOtlboBqAfjLy/ou2S/K24/ZpAhfL+yFHytFrJ
wJukaiy9APn4nS+qOZ7MRkFc9Lxfc9SoKoEdquxYpSAghwvGkYexPh9Xdo0VF1Tt1kv9DmvboIAR
HH/CZrVa2Qf4IBOoovseapy8ppuu/W1jzjX2RqUrSaYuIIgE9B+OQ8rAsf4doFwfb7OyGYyhPEbY
Zx89XcmiUr2QMPYSMxydbl36AA445qJMbG7WHdeUTF0hA1S7cfxDHQw34Z9oI3FL4EPHg2BiF/RR
r0vGLUuwfTuRQl2yo2yq84gbUAL20XTXnHcumUlsWYeWfXBEXPVdOdS49KV2fTVohOBkfTuJzoka
W6Pp+G3moCcT7DMachIIkpXTgREOtPsZYgoOCatwM/Z3/xE5CchtVpPnYqm6p3+GemyXd25UwbeA
hSn7b6qWjKw2AM1Au34tmBaEVvOanRaBFZ4Q1Zx8UUfqyZcOd01ijkg9I7KgORfXaLWo8W5rUdtA
F1tK3WUPbAuPFnr0feAMXYltImGRnQSeqQAbV3IKwuXSu979fgcpjUVd68iWRR6eKHbQRgOn0nj3
cTvEBrG1BO+Oxno7v1qtuJ5RoMWbhUlUooLvvyIEYvpJtLIbhY7lnskTp66o4aY5f974++xjOQRE
IrHqvs45hI2mu2d+Kv8Sz4g8uxxJ8Irgpwz+Hh5Njzm7+7KXwPaSW1ZMysZyetb515xyeqVAPuxY
zUobE//mYtLhyIeEuqlOlTkoOErlVPRgBcjTDoqV3sWtw1UMNtZORyR6cNqn0yFwWNHX9OqMPRsy
cPhISmlA3SxAmnj37LwagvG/xIcxNKdWDSuQBDCaz14YSM/qfSd3VAArgmf+OiYKekC4f1fwuTkN
SnteXl3eMBdNJHTY6KB2tl7KaT9bkFWQIqvAkjrC5oFV+3na2b2zCTH/uxen/T03rDbIWQrpzFfZ
1bd2B7e5tUKbEMJEP8nLIsb3tvEwb3QwYMF1L26RGSB27I9jOs58TZGLN8kzoGiCuFmnayDNsYDX
JKN+6FN1FYYWvhKoujkCK4JYieU3pXjsflX9rjbK+WnLgt6awgIh8NuKUFPHONWRMgVpG2elJ5dI
vA9gsv7o3adcU5aheUaHZbI0UvouzlTNGefuiaRSZd5PwCyEhbNmOYNeanWo2LFfote0/JvFLMXI
mCtiMCxX+7B9tzQhaYdeYkL/I7Sv91LJQXHUJYcueECJkZWkuk4T51pifVPDpgTiz+tF5Gn2RbJf
aueNttCKtou1gx1Y+7ZyfLEpoltMqLQy9tLp2G9RvBYDaA0ZkbVGJvOmklVKP7gxWHK8WXOvCucN
EINWXx6Sb3eRyAhb5/kTScMJZH/9iocsZb7JHP21bbcCmGAUO/5JWkoYUMQ251yNmVuRd9WVJvKk
+gma6HBEQ/S4ZCBifJwsWSRCvA105/Ii1cromzYWTtBdF5M7bi8Fr62o4yZLO48nhGrkl5LKF1im
v24dxe2dJoufNHWdtlCiBHu0aigd6ZOVqXvYPcADuQQ5rxVRhIAvIsuwUGRA4cFmU8UMMjriRK7s
p9SMuJw8HsAVYi2AxL02r/f4qHsUdACUI3LKxUUMDyG74/QrPYpWPlrUlaWvWl2BPVtx0+AtYSrT
TGgAoFipEwDR+qAQYpuqLg4GS/3VLIh804TjojVbc5Eu6o0Qvc0dK2o/qXviok1pwUl1eTWMTfVE
/aBTEEmzl+VpI8tA1QO1Q9NGBz2xX4ouJHgpV6RBQlV611+In3Trog4JOnUZ2vJjp1KSBTiWFAxl
aKrjDcWDfEROXBc5dXNf9ZVLCDZ3wHLFuap7wCYgghuG+2LZOClj0rAbQTlDRncNu/c3GCfVLfQ6
mFT4Ujf1ZfvDWTC3U2tw2wIpSNRnNAnetX4Ur5iY01ZLoytc4vfVPwyufA/1msDjjSWn46zaR/OJ
LtU18rkI5HR1RjjpSW1XHeXX/m0tHxKWxA3vbz7OiTgFX22r1tmBeSJj5fwxlnOn2oE5uXgJDxx2
OKybJ8B+TeYzLONEbYktzPECEj8aSLc6RTS9YO2Wickb64BwblfNI3LIBM3mssJsxBGUpK76QGvR
IqcFlVGJ3VvlahBWNYLRN6gB07VCKfpjhJx3mFDXlUyUluac0JL5nPh0Cit5YreexDNBmqc1ynKA
c8yIAfB7jkGmylCXQKw7yxWLV1rLrIF8ip+kdFv7OpHUGcJrAkz8gY0fh108noa2Ej70eQjAixCJ
NLBSQjj1WGmh/tO/2pR0qFRbqgsUErv3+JbNqWY8yiClHOkxQAbBdwP2tJf9y53NEaCz7uXedt33
w5XE83WLlQ87iRYw5V8GJwfsm2v5piImARAv9LsWS3uJuAIJs7VLK5DSJVG0Dw/LyKjnHsYHh0hH
t+2fGFg9/ggSF+avq2jUtqF8gJjpUnoa3Uudo/bbfWM+OboCeHGVt18wsEqz6oixTRF8v/pxYVfg
1xVlqe6g2UOPfYXJSL+yK0ab5Fk/hTHEtD6x5R/ftYtGPX/TUrMH6iBsIVtO/0mZC3+Iln8n+tCx
FShwbnbhBmJwBLKIpSn1QTfwh+QITt8Pi/b5e6SMKOfJaJsiANAhOLo3xYnJRgXS1Q1k9ZS7Wv4x
Vr8MrNf61v/US+AMpB638/j/a64rQK2PolbxeghRbaav8bXSUawxkdrTgJP1dCN5K5OhJyQaNfvg
14Zn8/vO7aaB3RvQFb8oZmc0n96VShLt3yenERUxtoVk9UiurSiW1rOF3UFLn+OoxDvy9IrzzfDF
sBRdHzdUETdVtwnRvUxlK4qPpFZ7XdGz4XhO0FuI108VU4nVKqzbkaLsk7PAQ/0LfGq4LtYAx5le
Mkha+u9TfBjg9W9EyxPHbdNT9ZgGXplTQZoUAEgu9RhlvsUvkKJIlZZlEYE5zugoqc+3lBYzEORb
LMDtTlReuE8ZOgtuDvmP7Opn44injOiBePTTYIVgTIcj5RYFthkdBwKTwbAQhG0EA60962mFj/15
OUfQPDzCTM8Sx9ygw0o7fG8wHr5ytdaU2v9nvXN42e1M2rbgNgzXEJwQqRqSyhXD6jjPTrpj10zo
74hYO3eZNMGzq9yrp31GgYZXwqAyOs4T4EKpDtdDFtHfUf29L6vOQVXRvtpdENTPUlpzCey9m0VB
nJ/Xy+P58JGc7Xv7TirmgCGYlAicuQKlPAvHGZ5dDWVuZHN0cmVhbQ1lbmRvYmoNMTMgMCBvYmoN
PDwgDS9UeXBlIC9Gb250RGVzY3JpcHRvciANL0FzY2VudCA5MDUgDS9DYXBIZWlnaHQgMCANL0Rl
c2NlbnQgLTIxMSANL0ZsYWdzIDMyIA0vRm9udEJCb3ggWyAtNjI4IC0zNzYgMjAzNCAxMDQ4IF0g
DS9Gb250TmFtZSAvTEVCS0VNK0FyaWFsLEJvbGQgDS9JdGFsaWNBbmdsZSAwIA0vU3RlbVYgMTQ0
IA0vWEhlaWdodCA1MTUgDS9Gb250RmlsZTIgMTcgMCBSIA0+PiANZW5kb2JqDTE0IDAgb2JqDTw8
IA0vVHlwZSAvRm9udCANL1N1YnR5cGUgL1RydWVUeXBlIA0vRmlyc3RDaGFyIDMyIA0vTGFzdENo
YXIgMTIxIA0vV2lkdGhzIFsgMjc4IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMjc4IDAgMCAw
IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgDTAgMCA3MjIgMCA3MjIgNzIyIDY2NyAwIDc3OCAw
IDI3OCAwIDAgMCA4MzMgNzIyIDAgNjY3IDAgNzIyIDY2NyANMCA3MjIgMCAwIDAgMCAwIDAgMCAw
IDAgMCAwIDU1NiAwIDU1NiAwIDU1NiAwIDYxMSA2MTEgMjc4IDAgNTU2IA0yNzggMCA2MTEgNjEx
IDYxMSAwIDM4OSA1NTYgMzMzIDYxMSA1NTYgNzc4IDU1NiA1NTYgXSANL0VuY29kaW5nIC9XaW5B
bnNpRW5jb2RpbmcgDS9CYXNlRm9udCAvTEVCS0VNK0FyaWFsLEJvbGQgDS9Gb250RGVzY3JpcHRv
ciAxMyAwIFIgDT4+IA1lbmRvYmoNMTUgMCBvYmoNPDwgDS9UeXBlIC9Gb250RGVzY3JpcHRvciAN
L0FzY2VudCA5MDUgDS9DYXBIZWlnaHQgNzE4IA0vRGVzY2VudCAtMjExIA0vRmxhZ3MgMzIgDS9G
b250QkJveCBbIC02NjUgLTMyNSAyMDI4IDEwMzcgXSANL0ZvbnROYW1lIC9MRUJLSEcrQXJpYWwg
DS9JdGFsaWNBbmdsZSAwIA0vU3RlbVYgOTQgDS9YSGVpZ2h0IDUxNSANL0ZvbnRGaWxlMiAxOCAw
IFIgDT4+IA1lbmRvYmoNMTYgMCBvYmoNPDwgDS9UeXBlIC9Gb250IA0vU3VidHlwZSAvVHJ1ZVR5
cGUgDS9GaXJzdENoYXIgMzIgDS9MYXN0Q2hhciAxMjEgDS9XaWR0aHMgWyAyNzggMCAwIDAgMCAw
IDAgMCAwIDAgMCAwIDI3OCAwIDI3OCAyNzggMCA1NTYgMCAwIDAgMCAwIDAgMCAwIDAgMCANMCAw
IDAgMCAwIDY2NyAwIDAgNzIyIDY2NyA2MTEgMCA3MjIgMjc4IDAgMCA1NTYgODMzIDcyMiA3Nzgg
NjY3IA0wIDcyMiA2NjcgNjExIDAgMCA5NDQgMCAwIDAgMCAwIDAgMCAwIDAgNTU2IDU1NiA1MDAg
NTU2IDU1NiAwIDAgDTU1NiAyMjIgMCA1MDAgMCA4MzMgNTU2IDU1NiA1NTYgMCAzMzMgNTAwIDI3
OCA1NTYgNTAwIDAgNTAwIDUwMCANXSANL0VuY29kaW5nIC9XaW5BbnNpRW5jb2RpbmcgDS9CYXNl
Rm9udCAvTEVCS0hHK0FyaWFsIA0vRm9udERlc2NyaXB0b3IgMTUgMCBSIA0+PiANZW5kb2JqDTE3
IDAgb2JqDTw8IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9MZW5ndGggMTU5NjQgL0xlbmd0aDEgMjk1
MTYgPj4gDXN0cmVhbQ0KBg4ccO4AZkhPyqTrFcwTZYXEkn5CSq02MAY1TloJw2V+gPipEIym8MB3
uNdRQSjqr5+2rgBKuf26LMDnpDO+G+VUJOlu+3lIo8e26MhZs/8h6v+vmkMhxII+3wlNDg0ZgRVn
DgcAFpGO9nJqTxdn1GLTlam7hCMWKRzm8bHUwRHHKEw6gNSphUn1qKui/IB7PAno0MZFVfoxxzQl
Ivc1kblTCGQt4O6vdhYrW63Q3Sum9mfc2MkzzSULxPo2m0kRHcWYv+QPNP0NGVmsAmOcBUNTPHd6
yEKUd01mXGKGWX3C/S6WW34JbcMurJaXvNy5yrk4lRK7DVUeo4WcWdzhvpQz7AxB4ERP3de/k0Sq
mMV1LPoKfxPPNi7vl8BVecgGw2cWUS3uSXX9zQJszNFZSfMHbkhVsySghSFkn52kANY/u2b5jDQ5
zLAEx6m79pLQa5pQM4/HtHTj5zLj04TU6tZYx/LEp4EoRnHOnGySZmd7kEk+ztuBjDhJ+GEbrgbH
zx1B1t1Les3AS2FwIgPJzGso7ieckXu+vcVWURW8Rh7LZREJnmSamaCLapF9MsAa8D5q53/x2Kv/
ROBtf4HUD4k/lHZMIhuyR4We82I8wsapAHtB+nOl0hrwFKytTUH0nHcPe2PynJZT6RwGUxR5kl0c
QUTCqUFCHNuqNqbcU2JP4uodaakEtxwfV/38XQ6JYPpsa6IocU0Z+ZigaPZ0a+QI8ykmvsxMuizg
PcmTwB2XIVpfiKRDmbNlrGxrJu4BElQx5lOGgSkiFYOLc/M/Aha2KMfzOqd9PNJWuUi/kInd3N2t
+MbORhE2EfPT0b+fCvLMKDB9vCo7slKkDmkF+BuhXbclkJYLJXUtMld6G1mspASVDqBtjB4b8yxI
p2R9lyQbyV4FD5/d5tA28eNePsE++xfZ+20brpaCna6TCRCIRaomHz4G3CW63gY8zYQjRdYqfUyH
u8PbZFreweH985pTKvUB/cl4hYtUChqHt/T89HJNSmNxWuapN+XDqUkd28hbM3FmJbl2Ly1uY6Wp
ynmddoErcmngVnralqnSyBAuBavoIOhJS77OTWTmRxsnMa6A3XCVlnNiC7/cXYrMuQDgy+e0If8m
wcqpuJCPpvEJg4ddXWNAbpkkusV/rWTDUsAoagHbM2QOwpk6e6rpXNImAHW04zcUL6xUIM9oR1wy
47V/TwxSUB6mhlOOptP3hRuaLqSzKIktEJHN5UWKEKoU/Sd1IDY++S1F2GhP5vwuEYDCWnEG202U
ytQVRwK7Zs/s5BjvhhdmgEQmbeL9rqE8UZQcOUwg6U6tOCe6/5iPYgGFbyBkxJJu/J795AVN/yWH
X239HwL/NBPTM71KGRzMhsQ3gK2g94jH/1kIXpqbem31X4BG1EGtj86sJxUfsDKDoN2QN228enSr
lnQlNtomQ7Cah4ISGOPE6NEIaSZcIbf6r/RPRgBZQWQYP14oPXG4GP/BpyTQq8nqqBeocSQ9A/OP
1E1RFlBjX2hfjKztxZV+wFywBHD2tedsOlbk8S3KzxNH8fU8YTJwC9W8RsQwvQCx2i3dm4628z2B
pcrL/HYhynjYs/zSY+dzO7RGeB7G2BAo5fo8JjqbzkHQeeuAE+/0Q6UeJQCHG5WmhCXVFxx7Fi5n
4reyay4vR2IiyKMMYNYVOX3DWNYQgkiJ85xlq0k1pcVtTdZAWmyjw8vIGkjBfneoy22fkv530kYb
un/xZnMp/wePs7W286Z85KmGxGm81ctEcrJKLYemLKJcdcoM1Wi0fsp0PGWbXA1Y52psHgr2EhxV
kx3Jb5hoDtA30icVRHLIfyQlNLOkZtuLAeRwwxxYIZRHpCejJiJe0zGgjg1UXnLt9UuBVWD7rXn3
e56GRs/0GQbbscYCePrH8ERUpsfgI1O6hOsnxfYSAh3WoHO6vWQS9lmb2Pk2bp41l9jyr4bnUZgP
DMGAhV2sgMymFBEQv78lvBmY/R2O2NUpInpbZQgFa4MpjQWWYt1zS/ubvFemdqdc72jARtQ8SZke
M/6go5Dsja/5vTBEJcQjBD/Erav9lJMo6Z7oSS6BRQo4c2xS4eptibdqRR2cmS0ZXPOzV/YYnPBo
HvOv8qt9DS0K7wxN8WQW5TEjmnhnjTYkM1M0twWzmcawPjYNgupsVk2S+qGoUUvk2Ta9wVdkcYzQ
GwD6mU4lMnyKfVdtPx8Zk/dLsWiIvFBYJuYdP7aIO1PPMY3ylaOrFxtxZ/GlmsKHkS7CHTQzWYb0
7fL6caxm74QPbF4+JJgZ6pA4r028kZNXYB2HuLcAsICTkrzTw9tVB5DVYpT9pJ7Oi9iyqbarRyy0
ZIccPcD8D/PBaH2NVWEg4CG3ZqD9lz2R1+Mzj3XHNr3IapAtPSo5xSGJTD6ihMQSzcM8AgjLYswA
wJdZMRLjUwbXAHfkMHO3hljUbL7vmYn/uT61X85s+dfmg6r2QnP8gO7xAOEIYeaQK1luzqsUc6p5
/pLXY4H1Und0W0J/Rfg04F9zN4uB76seR7wHByohdENrJQsbe0cQ5bE97dMqdXanOL+XNiaCArwO
EU/Lzd2oTW1gREDb9zFf/go5/TFCNZ89OF4AmhPpipp05ho4o4fT0dylgPHBerQR4q+Fp6vA7tjS
Y0skXLEPHhK3W4kvXfShticfPnal2zhAYpiAxiuZxYO2kRJADA4lrlc4HNrdGyFPdylNNu5VIf6z
1W3vfcd3gv3XydSNzUyRyp4qVhu//a9/Lh1YXHoZ3Fnbh7JnP1cpFYiYJRlKPW38tqf5vC+g2MVu
qOOOc15bOhLqWX7aNkLWwHdWNG7AxnGn9/UhAJrZcK4Gmr4RqgsF9Od6zpqezRAltPOUsLHClFDa
CuKtsfMsNxLUMVkUZfVMstoCAfV3xaDMBvCdK0hkHQciaXP9INMXYPu07X3ftVbj9Jq+F4y/dZSf
l9J2qBLaMPP0r5nB7itgAvITTB6KKu8uwqtQmYng18LpZixbIJJ3L8BlvwTGgoNxp2wx5U7e6PUf
Xo52JG3MvsNNlGBM7fVp0OInZ3M38yHriCH5G98BAdfCsh/wNEiGvTa7ehlrdOnZ5A+ufIo769qf
8d+x8h13vJr7JcQgHRp5LiXz/ziAl3Igc3iSHytjESIpTNnmXVz4A4CimgUh5pSsdSE0/qXdRlM1
VUY8szp235FgLEVhyatCW9BwTBfVF5SfJ7IIhMaN3kO+bL7GsmfsD0FHfNUsNSpY5x+oO2spx69A
HklkqqtLv3TpEDYGkvy+/iXbKjBa3eOd0nhcF033sLP+uDNOn6vQYGusd1nRzJS/TnCAsB73hJP1
pSyt/iCKUZUYVoAb6Du0zuBtkKTMekrnogfGYRKdWgbap49LhW0wsHYWG6f0J7t/OfT71MiB9LP2
UsXBawYuCmJGFJ/8cbPNMUeLwmGS0hYAuFEj6mhNCoNMelvzDqPyEstm1yoKNuUIRaNfAGygUA6D
G3b5OhVPdpfLcNLCoJ+2UNL5ktjFk84MDSoAQA/g1uFKlt4eEHwmjSLWzMN80rSsn0z3l3YhBHTX
UMAxBdwbT0Vg819rLiVFBBFVuvkn25g9VXUho1UCj82m5rrU8TV9aUvk2CY+QlQCuqQ6AdWiv3XH
IWg2usacRpcc/BlW0XLY3KAXVPV6x23EUndpNu3m1UO165fgUSD0rAfiUMfZzEwmYntRektyQ9XW
a9tNOkMcYjoXS1PfuJ5piNyqLM0DiKYm49qsX37/5ZvThG/Uj3Uw9SDniG5AnW0OADwe2PyHwmx2
ECZ/AM3LOJ01m+E2zhfzOxriTVWaw6/MQQNRNPNtlbkuyMySiRJXNs/wGQ9OR1g/5L+BKeeOv/0W
s18h52qojYuzhjPSIMnahlZv++/iggSWcrLQxX0RZkbHFUkuuzzBVB/6pzYJwljC5iMZqQ0Qi+4q
zHOdjnmsDfM7uhjHax1apJwQ7BhffE+hbtRU+T6ap0OSkny7m4YTyzYOUI21+E2aObmI4ABTuAmE
xhUFwkIXGRlkVp03y38d3V2ccQwbyzle1ad6hccdaKCh4DW4T93H+6jjoomeRx5HfmTbu6bMhyzd
PL0FqVDiP3u6ia1p6HyoPSt7YDSgB4PgLgDA1PfLDSAY7xeY0q6MAk+Tbc4wKFzf5/1B/ED8HPVj
YK0rRJ4kZPw+jKKN8jE5ZKaUv4KgcQ2kq0MC1wfYLEr7tuZe+5gPSktwVRBlJw9WTKloxiQXwnht
Yea79gcexKfc5CeemW1CvROfM7snBQU3/uktklsn2cr+4MWmpfjBU5rAF8pNf0UlKUW8erHBPp3F
3NSPs6qDXF58y7/TRS2ErunaT/dfJIFFmQAuRHHBVy8EA0HwbdPGllhWETUkGoq2QZ09E5F89Kv6
FXmPpA+WSeP1hRxv/w2UhvFPtAE9pUMZRrxyPb092suGdGrVLuOo7NUTa1lB21IoZ+wx+K5kpx4M
pceDxbhUhO79nVZhR1JWpzBrp+fytVfiQ0lVNCjK6XFRuRO/pk/mVLsfdiAHks1865PwgDCZyj+q
PFIEeXszb7OzaElTZqupP4pIEIvt6lHGqJdl684MJT3ac0MeAvLx+q3n2CttZyNe8my1CO5Usbke
Q6Cdwg9AaztW8GzPbQ79XfinzFIBLRC0GWydby4AMXh0z0d98E9KrwSbqt3JDZyaUHDKQrBgCSzU
7BXgEayPUIpZ3ZLQApokec+tYH6swqGGTS/YhhFrq7nPttnd9Qv4wfngcH6gWu8x7zoa7yRp6h6y
GLhIh145aqahLk/UMhsM1gJo+wJntMX7j/qDbqAKtaEP0Q5kn/3qlJ1UAgYinsLkpArfuiz8SbyK
YUbp6cX/AcnU9hjf4osXkahHqFSMCdnAmYoTWkldc3BtrJZxaLHRhZciBKB9PADIeHeIY2vubIuZ
mfl5hd8C5O4S8Wj6bKYXr7I7pkRoAL5x877UU9fsYNNbiUtwxLv3ZJXCFQSlwc9CiOrBtDSpPYcS
8RsO8R4Qecd/ySDe0V3Dcpvso2AIGUzVwusMAXCN8v2zI/EAdLaAXAYSs/HXs5aExMW4ZHOMCOTZ
a5mpEY3580eZPcAckNae+P8qyQtB6HbBblHj8y0Cg+rSTNHLwO9Wr5Y4w/0QdTq580YqCqYr+0Q2
ONwg2cItBDpN5m6IqjuxKRhQ2oUdAxCpatvRtAiUvTpAMisqpMwsA1L+qCiGjHFDdcgVBbtFfPf4
sI935hv0ygcQ64QryfdnbSNPQbIc6QOldcbvFnpfQcrugWCVRWkkpALpk0dExWs26UfzHf2Z+iyc
fuyRFT1e5qNJ96PxDnBg9EsnMIZr2ZXeJV51uoJEgNwkeAfbNoaM8muyvwGVlayI2/R+vq4M2rJf
9GH3kNw67NYB74gkM953IOwFSF7SScPPu5iQ9GvqUklPs8b04N6CoD1WSy5zC3ONAO4+r52++IGj
QA2bmYwf5J25ZTGn4DCpYE/1yNSfzT6LrJ1U+9YMxfnGuVr3CECT83rkLNlyLm2z5BgfBuSFblmX
FZUI7ptVl55RHwiaCam22YA5TsbPtmLXvFg1y0eh/iVBu5L32As7+CnMRI5M/6cRB5G3GZzLen/b
vnqnibbBi0C1xfrwajqNmfhVEs4RyaC2a0s/WiwaKsIKJPiiUtIRAFyX2j3QHfTXQkk70NoLlPRw
QTWmZoFfBGj0+B3Odnec6ZuFHlGzqxsXzvCOS+JEQ+DnremCd2X89BzPwKMPZ4R+Gdw6hjiXmDWn
4k9dGrJvn3zM/SMkgUMV6D5Khb+F39TLCh/wol+EZ2cnExpFCt+9kfndm8B82dch6BJVLQncrgep
bI0iDfj7Dul4BspI3JOfRZ6PCy62RO+qtWO5ozG+92NrmjdOAyxnUFFZRFlh7JUwqaET3KY0ukjV
6nLI5tDJlrK+0YKEJ568hgo5k+dBIodxy6zCzAhk1NYHV8rbBbq4vU1sYDV5sBrU2XPuj3Z+xL6n
jU9FS4rvarCfcfb01a79ukEOSvTMID3aV0xeJ8Ihxk3SZTkPiNkbmws2sulERb1h7zn8ml8GLMyo
C3H+er7EpLXGwCRighiMFY93lRqRyZvWCzPVEjBVpuumtMWt4LOjIsQ8K2Jm0uQwdAJevwfmSYfy
sFomhr5ZQJ8SV3Ek3QHS9Aft7Pf3afpv2CEjZn+343uXzc+1pKC52++t2IsUn7ay9idWBBQEE1St
+fu/0JI21rS/cYaswRbyiSg9u42utpgPf6rNHrCGSTj2qaS2LDxXbK2CH+uOKGXwLUbwVGgftAQK
FP08rX35rS9bF84AcTwGXycPYK3G+ZXQdj650xwF4fq6ZZqKsfsXGV9OshinL3IrlFZwXsPosZ6S
UESe9I3Prs2qlf4k/SwtkNLxze5GuQ5W6Fgn7mm/efYA4kzCIRSbffkbHeEpAHlaMuGr+SwKSyEM
luGp09c66dIUqlnfaEhpZ65M+/IeeocqY8Kl8jSB8ExBWsAbyvv9YY+6fRGfUkPmNju/ZGhPR6zu
KgXIU00muH1Td1cgzBcy0hkPyy/CqkSXP1Sb0ITuXOF5NOB+HJwkcy/OUnBO70APCZEgVgbZulmu
T5O/cShYl3v+N42kcWY5+P6SlekRsqsMKwBFWghMgaJE4TkkvZLzwZy4GrwE7Ayb1LZo34jKEm1B
lVVauelu35LdyQ4zKg+8UtffR/JvVD/+B74KXMdRH9T9z1Iavysp0qdwpcwUKQgpMEtB3oHuladY
tygFI+TMd3Ju/xheLDXx45H1wb1kHbGsQ7c3DqbuIKA+Zeat2aw2qlvNvlaOAGziza31XyUw3uEF
dOzvIjcDpFtomJCnZBXw2aqvmcItNWDQmhmr2OS3VYzViW8JvRePih12vq2TteSO9ggFu+NlVUVa
TM0SQX9+YUffPRbTbBvg2HxByHphydogIaA/BOwpG17VC8ItUuFbpO0vnyCrA8+6b+gz3xFOodfC
G4R3iiG8FQUIVz6uUi+Mbt31amZ9p4cjCtEqwZCx1Bf5sGPWr3dWSpowkUS7Zs3FRm1xcwe77yqL
uu92ABWMgGhIR1xcpQnF2XYf2iQszN5qLFhZ99yymwK+wdDX0Q2Nt7OvkZHA0N5PA6BnsMj5DghQ
GMiOpTFfDTTobBTI9B/reQfcvemIZsPM5LrDGAzLyPPws5PJ6tdGFX1GUEpqsx6t8StJ0Lhsi0AE
7Z3odmxVdfQTtne8u/bscMea6p1GxNKPeU+XaaXYsUa4ruozY5PkIvdPP8t6AlpTzjRPUqH0S2C1
9YUrye+/dyqYR1syCmgwoYe76Niqf7b5Tbk34Rs4djGuguuzYjHZ09e0ogsRj2DJL1p3zZ0DpNmB
B5OT+FixSUzg2+4aJ43ehUalDZ19Q26ZIKjvB1X7h/Xg7pLIslZJLsbVtkshT143fXimMvOEzi4p
xom6t2FtUDhBkz6cVGVZIUTV/aTASr5pxwizH45jpGkQW3jbYhYhMzRFvLVkZ1iEptdn9SB78UiJ
6eMeBxOnbbAAhsVJ1BKT+iAIUoUNR61b3Ik1esfWzsK8bp9fT2gHH+Kji62lpaccVH7usxFZuhB2
cyQd/Wd8I4eDve5CKuHCaN5+vIR7Vpow3cQCblODnONLfNSOXfa1IMsgGJPuleyLOhatM2UmIeSh
aNcH80jwtxyu49xf7f1NLu/SNISEkPLwbt8wt/LSYDtNt3ALNUwcjKktdaE44DZqXUc6UYXOEGT2
ZlmcGvrQ+wyVGAiBImN+tg3egEv0LA+RPUyOxWDjqXPhuz8E6P+J9NgBE/3PeBy3j/iO3Htr1Efi
4LUFC0+v2x8bk4iIkDPcXvAQhdwQu2ETpUXFnteN79hXadITAhJ4R0K7ElaOCFssWpFO45x/WSfp
D6OXE258VlQvr9eER/o0g0nm+aoSO6HiJ9NP1EhntAWTwoxk15SLIJFCzsm3v4VoYav8ts+wgqb4
/R2CTRT8x0uu179hwLk5aoM6zsl/pVRjRmnPb3jSKcsyuFiT4abhweJqGfjkRvXJUjI6uXJj8FbK
3pJonGNHD1OWUXc4w6c6y3mzXfOWXAODlRbRlqz0gdN1AVBxo5G5r9bsmEHaoyvS1B28cN5caST1
UzHKNPG1RhNJuRbu15+BidGV+f9oe9QdltMFbBLgzYdqFbImhWj+opVs84Wy5J9EB3dAjGlaYt9o
5PzmEUv8J9jrc1LNQIsglHUDCloPtFmq1p1T2Q1XS8jOiEU5N1Z/1VgoRDxkt1IubjfcGvBtkHZg
74XDVAN3u2sPIzWMvwmcmCnNAA0aIzzSCuyDlh0lgv0Gt934gVGqVxSiyYVSYNVLMJ5FqNNQQk9J
JYYk8ogyRcBgup4JJ8f66GO+FeootDqLT23H4Dss++8wB+ziCyCSzn9JfkvC8MFK9Kd/vKdUrZKS
fBRVOoS/+xTPe4Z2G7844JOyYrylj9IzBR2WivFXrEQ0cptYWMC589H0iEZpy3eagM9gtflLVCd/
k+zy1/ZIpli7FxTGWk0KsT5stKPpexFsGevIMv8v2nBa3TxKFtJYPI/GSmXBe9Ha7Vg7pXjWSY7i
oToCiNx/0uJdT/ENig4H6kC0fB9PYn2H3CxxRUnyHhtCK+VVo2BXj8Q+7MHrNLf7dwAP4aqjnD3Z
vWLq4Leh2ION93vat4RkJljHhjmSj69N6trL9lY8aorFFSXyBSktdLw5E2zakj3RSUaTMBR3KRCL
F+1jgmFBmYdvWx0pToMPV5NFpEUe13r5qA/wr281KG4Y7E71KfmOubprS+kZZcItJisNX1V0w4ve
pIE1sW2EtKx5XvX73Zaam46j1sPcUrtK3ZHOCYuqT9lsg+pENkmDD3c4/9p0hNcIB7ZO4Xa2Dnc0
JJfxjrg81Qs+uzmGgCTSVy8RTl8Tmm6TH6wsVueghqWkNo3VEPwXocfmEcfDWrL8th/Mv8gPV9CF
ZtBLG6ojD59L3KJTS3UuvynwkTM0LY4rSf7+gOdO5CehDothmM38QU1E20GNVoFS1x0BRyCbIplk
81WMhoGkpU8fFenAof/mUthA5o2LPOmiKG+WLKycSZRY/KRiuMHaXjGrqlS5LQCjL/PrWCcDTtnd
qou0GsUGD3wH/7ZO6SboQtbEnBqajaWZlQc6wvwWOWB1SHdnc/hJqmnw9imxbcTaZ0yEB/S5WKS2
tygCLLh92z6cIihBU2FbXsHOiAzOJFSC42UkfLWgEZH7SWtFk8MNN7ykHUY+snXxINVt4Q3uPIR+
pUXPR2ZYMnGzbMmRC9kiZ+cuJNecmtqdiUZl2ev2/XA2bdb2pFC6EWZnHeaO/n1JUBo20m86NsVf
GXQu7ikwu3gSiZ3ejJSx47SwBH460kLrIrULHjZaowduq+C1pvnpyHpTzzRZYB8kAmwm5ndyllV9
D/QpE7vTBKlKnGsVnJ/gaGor2NFmYQ0jjB5kC9zu9PLhyqbqo7Qy0DR+rXPKZJqDvBjXqWIb2RKf
xfqbT5omstRutctS50k7hXjolNp0Vx9VJ77FoxJsVXcQOYr60GDj2bApaoWFt87NM0CiK5BaTLO+
fFR/GvMSsOFIRK+sPSo4hTMbS/DIDcg6iXEI5ohP4uxes/2eDf057MyUGZNzKwE7q7FmiLDB7/5Z
j0bOB98kw/h5nVtLptjo42jScNEuoEHnhW9cc434Xx7uoEwJm+lYA/hpV4o5n8yvknqT98bFUD2V
lQTFMmRAF2vCOzcOAA1/hrk8aPFd/ePX53AkclW5OX13zVQ7JQYT7x6fTSDYPHSST0fmIBIRjmy2
wySf39sxE9h5rBGX7PnYiVdtWZ7jyTR/cOM39RB5I8njZteDJ51nAQ3mvoSe/VT8tHXxax57h8dz
GZexjlsQ+shMTGmIjy639FQyI4XERr+7CXhjHkmd2pbGgInmX6gTCfkEj60MRK9aH335IZMBMQzS
jXNTVvs8Sf3Tmx3JtHGNQXMrrh7OKZNBPI5CLZx3NPzC9rRxv5PLRZB7poxr0zyOJwbTspmKg2ay
mgQ3rW8EEAfynWPH+BOwdZeOoI5fxejxAAvzA6drIN5AhMIkMBPWFCaVJp8kdH6fztkPQoNRSkYP
qunmM5fD2u9iwjt8Vz2XA/iMSVtbOODlhKzuAT2ZPSG+e81OWB7V+FWSbqInmtdFzyE3e97cDE3a
mbhX3RQ6FGKTagKcA/GQ34TW7XdMhwNul9rKZ0KKFK1CXvyaAta1qlNyQRa57s7ouIv9RoOMG5UO
PiJ4ut4ioPEKck2SOxvvDG/bs3O0yjzpJ0+INqqEdnO/APEGkjLohu0xd9ca9xRXFJqZKPUdOhVx
YuF0SuWX51px8P+/IisLaKAKgDs0OCs6yxKhebDFKsGjaS2Y52NTyESibFCQrH1cQ+tbBIuI7WYF
IDPAsdE38QLkJc5G0t++0UuVsV+qat3HMP7o6SP0OtLHzZJ7w9NztR01RPu3xqDG+69g/vJlElYb
0U33iU8GPl0vZ+uIxUh5TY0mH7VEd+gEeVjGI0uJt3c6f0j1j1DxoDmg9OyDv0XHLNV+FlwRBQRH
vWGp3KlRIewk6Ursh/8nAFEpyvlZ9xIxgtjs6miWBb1qHHWWCv9kHvSuKr+YVl7G+ydx6Nb7uWjE
fM0o3MsiW7QSXzvfZ7xW67OobgP2stvzVAVJPp3r3/nIJkSHj104MoL4CUfa506YnyHhxGLa2swu
C2PAgsMsSc0CV0UO01j7uJYfRrCq6rkO/2gloTVQxTFreU+ffUqIfzEqRF7Uco5honWo2setBbHp
+lMtGmdJ6q5QMZSTuBSsrgfWk45ru/GG7k7xPTaGMyiRwmeMUHkNeQqq3Zw/nnWdyU5RcIeVWxNC
yc3BZydtd7ht3PxWmW7jdMEhBhA9yRwAxiMoiOY2neqCgLbT4B+vqbb5b5rWMfiS4IvApChN1nyP
RA7D+pkim8UoF5jqRWWK7Cv+a7Y9gZPa97gYARqaNYyDPSmm0JpQ9RfoF8mG1F/PQSr8mJWC7z1u
Xb8ogD/WMx8ZIBkkcehdhVf6NOr1eFZMlmmlZVOkuduMinFvTjN5/YlNq+UBWNXbbvXcf1Wl0yTl
AWlVkSi/Mv1VITt8wCtrwerM0p9Iovl36DMX5q830FO3N50UpHBymI+ljLjtJLzPeP5FietcQQm2
tjBe1v0FoWFxdOiPX0dv+bN24N83bM/8x0gORV3fV1W5BQG+7Ijpbr2lLlMr8vyVRqe79NAomDhd
ZuOQJTEpRZCOcLLUM5OydEfrzaSZToddSSUo0QdOgssZG0/gvvhLt764WrtEyOMweXeSIpwuTNK9
+pKOseuoYQg1YLOrGTxaCXw6iYKpGQcffEYVos63AtNrx//C9OUy1wWHHWzgZcK+zA9Aa967yeF1
pjHMN8mDlzGg0lOCsj0jECy/gQKDsb0EyG1NnSfjdLP47kT9Q7MF9m6zOu+rCS1LcOSEwCQpdxg2
NCL+vKFJa5+QERsdk2B7Qzo6tJwEoXnC1dUvdDc+jok2M09cwyElHgB2/2kdZGzIO+ZadWjNnmcb
/yZ50jUNGaADlDpXITyIEF+daOZ/vwYH6b9wZGDI3c0cSJXu46s87UfJJWOxY44fL8wnQJhNVTdA
K2MmybOSNROPjH9BC4naHQ0jNji1uuMQXmME6KcGU9ofbVCwynP2hGZogv0rgyzRTwdb0o7AoKS+
OkqfueAiGnJav1ADWmuYPNuGtgJ1HKJ4qs2C/+g6UUsOjIcrH7jWvdCO2d9htNTHXFF67i3hGdsZ
xHWfQbWDX+LBQG7TSlp2Yw+62L28hlSjhKsmXzZz392Gy58U9likfRC/luSjhmNJRYL3RZ4bl6Li
ZePqzdvz831p8GwI43xuymMG/NmFd0mb9PmPMScXI9SC33mGSsvTkjavYNErzDS2e8u6PSmb1u2u
2WKfFp/PH1kR2gQVcSlKqmvK7yDP7Iq+sZa7IH8dsdFW0dKlQ4JvCULhudzBFDQBjz1mdscglOnp
ycyrDvVN7ozkty6z20qM5zD9SN5WxxSsnKnAKgahT0lxTZvx608FQnX0s4NSh+md67ev8czoaJi3
68wGSsPYJY8HLdHgzW7stj2kyQ5a588oawI/aXVUALU6bo8TyoEmJKKGSbpJfAF98TTjixDHDx/P
iN9CqyIMti/JwNLc1q03qDnxLG3BGxZ83rz6OS7j4zJJGSueLbezWGCeRXcJG4qKzPBpNiCQIcaG
Mofa3cy5uSaE936hpithbql8iNSFQKwa2xnFS2lYmMCXRA3fyATEV9moZuFOqqGjde+NepyPML6N
Nnax8/rhEU0NWuuMgHJV32OtjKQilyTxTXe500ajpNuT9s/yk0m77ipoOydvVo8ANd7fDqbDhqmt
Qp6L0w6sMDWSH1AeRwYJsMQdh6JUcXXcH6biT1MXNntx0oHGL7ZmOmdZ/DrTJ18KGhMNmvcbMI7c
tpCmiOGO4odxRryWlQotuPZi6dsppqvdXFWQEQBm3NP+K6YAZl1MNdWnqY4ooOeAabGPf6LRQgVW
gS4jLaf1NSa9WMdOcNBatIxd6zkudjcFZHOFUaDfIFiK+sHQMbkM9l0MtQ1dHgASmC6EqQId62cH
V3TmS/qfsBTKAwADn9QlQE1qbULszYh5KMJnKAvaA+RVvatxW3ABIqL9njCov2l3SswaiHv8HJz7
qlPHEeO1dRsHhNDyYTYuOnFgBZxPs8QwPdCIC1kDFh8kuv7/X0DnrmCfr0Bo4KtkgFfcEYc0Z9EB
ZdvtVY3AYc8iMYnhTGNqh/B9kPbxPSkuU4oKpEeKOWnvep0/se405L83+yhBdQCqtif8EuCJeAdu
tPPxDFY5uEmS4X9I/J1wEzPm3xB5/fmFFL7fLkvL4VieEe6gLZghuX3qpeoaaLQF7LiIsV3dkbgd
JuAN8L9Reyrmqmz/gjFSvwylhQCIQuf+53iPeAK9kwfNfbfJLjVKJCp3tCP5D6nJ5/yIkCx8mJAp
KfDL8l/Io+ZG5e58r/W4h+0BBk44lM+KqYliA9V52FqnbWy4Tr/zV/50Kd2p7E3QUaAAozAEt76N
XCs8AZ6dFWJC8vdXSfsyRB0xWJUvXNdYDJtEsJZTZmri/ulPXgEwYDLWZW8po+6D0Tel60GPBVXu
7uuhNWafnSp6v9Y6od1it4nK+PTVY7IvYKlpTeasoqQwym6acIAwPXQXvBGAdHfmtmXuYYl829zH
3aWQDLnRk6LWew+RqbtTdibAL+OkppjYM5yerq40dByv4TtdB7XJ149Y7CEGCcHmlI6Kg+QWZ+Xf
vCQfZMOYv8DNxYpgzxcFdxLvLaRdUw3YUlNhR6+s6ABiQvjp5zxFyC/KFywnxqBlWhNCC4cuGyat
MaTWrnMJ95+FPH1oQJIzlcd97V5GTwBXnM8vbOTiuymVNAKVrJizd/4rqRTG4FIxfDdLNt7VQeoC
sKZUqZhkZsqF0xhQamP8RW6OMuIczIEbI2NhT2QNpMQPay2tKA/HFVYoN/OAiewgjKC8LERTkOmO
q2+DPNSeLGKsBG8LS6aVnTF7zMXATKTolX3cwqtp8JduFtyvq9aGHhXh86Prq9xq9ob3vUx8L5ch
q1SNa2kMwEjvGksaxE1Kku4FajEL9huENkHu7wclIcOKO5GCBxcS5QGnkWI/5o46K7gQ+TyL7lJ7
SHzRvtvi/UwKEg53XnVh+fghs0H08pmm93c0Qz9AOaUNy66bhgIJmyEr6SMtRPm9MR6oFBafFwSr
h4fyD3GzhNNxHNCabldCjjpjQWboYA8J/cKdoZCvI/eTp0rdwx1Ncwcb0R9jfODl3gP3wwBtXP9B
lqHiTCvE4+9n8CLIiTaWJn+bBVgadWt/ElgtewBP9YTe1SXNXc84VXGL3zp/bGBb3qjU7ejtzfce
4Z/Yqj+QrkM/8RZ0rNwpgabdFDmJoQO2wkD9IMT3q0xFlw3BlZ/q8jb+PnAWitHUBKfiTum5cKgk
rs8/bjvqnp9qkAWyBYvBOxvvqxKe8o0ef59X0R892D4lbo2xEGlX8rnN/5OD55XF7dirfmQU5s7s
CwWVkKvr2Tj12+NdZh1Z+vIncM2lxJa+nkDKqRYOVVED27FkE5Hucv6+jI9u+P1/2CihEfbJBaqv
47WQPbUDXRX0RoHaIleuPvLohFpAom6XEq4kKeL6FnkHj8guaQz+V2dHfWYF6OH84FFe8P/zvHo3
AjcceNq1wdn6M4ZILQIAYw0pA2mRqOS5n5/ttCr/qVtwoYaPsxssIaAA/noUqpvA4BnjIvLVXh3Y
QYkeo3GFCZra8iPTP5qseR4sEvvX3EUjMHDjMhZ1RizU4KB9ctS16TwZejfdTFgXzTcSSafVjcj6
AJRjuT8MuFKP4JALG+ecz5a2wcthVTCPdjR6My9wzCExDBpSJbCe9zVSHn9S1iyfa07Bk76jHWcI
UPBkEgaaqV5XYFTj+xninFgAjy4gH+3vcq3Q8MlI4mIJZRA6kRjF2xnwqEN8Xdr0UTXAVki8G/Gw
jpP3AvDYLuXpIeVZ5XrZ8noSYLE4VWUgTajJURPmbszl5da3dbV7dWzTmby4i+LPqQeBo87wJTkA
PcHiK3C9kJDubWISU7A1NeQlgg7M0ILNrqueKDLycdTA7PuLjuc32EOsTincFZqrF1salmL8ZXAE
I9NXzHTIUaGei8xFRPE81MVi0WQRVi3fBDiq4GFk/MAdPsSzYIVrso8/Jyv9S82BSEuvO+sh9+yj
CAVZoX7JZzNhLOWKfSI7vWKwvdEuFTN1ujHJBh530n+s2+lNycWlVVUFgWKdj7gQ5foh9mw3bbBf
QnpbVhQJGDgNqDyfhV5vQX6Op1PIqYuoSogsywxUabaTdHoBOVi6l0o5jWQDh0q44vOF7yUJFOTy
CHZz/K59hoHKRXh7oNulVQ5hU+sp60AeR8a8Fo0K4C9LXgTZWRu4s/cdayRmQzO58tv+k4Vei61X
ohy9KkAmpyaDc2e9pLWQHKYZ5AgBMUBcOT/EBETdkA3SpxgTUy/N6lQbFyuUecOipZ2rhNlv6qo1
YdA/v07zip8ylKil/Q7wscKe+2AtmzGfMA+05KdwmdLUwU4JicgetfiJJY+eA5bqgQUeAa1gz0/p
ug8FALrLEbUQreDN32G7mr9f6jOPd3yndF9QFGqZflyY/Zp8N4WgAHjf6kNJyli0V4L3JwwMv73h
Ni8JJLa2aqCB1NPJysOecP5Sp5yVa/C+8KZIdq+Ph5mGvrEU7korfIAL6CpOedL8SOtml9WJnTpm
AYOi8QYpZfxbiHGzpneBnKbzpiNjR1fLsBSD0B+FtQge7c0TvGZJ6Ogk/MdS5ixWhAy0A3WWYB7T
/UtGrl47GMYefMAdaDtH0ScA75Df21GSpunesjGa70d/OSA9czGNTqNRc2tRUlNaVIrWq3846HUY
GxnuOn8bZH8fjtMrkTvAoc9kxIlvfJYYMpto8TGLidmkkTM7AN06fkUjPf0aXarwFJ8Zw7XFQmqX
v1i0wjfJZ6nSi2TTnBhPRJ4bW5ht7xdWQTCrvd8Dad+vi7eIvcCH7Jvc+C3Hup7tLvG7XEwJ2rC6
d/eGzFpvxpyuOvD2/JXY3fYFnn3EdDqy0MRvr8iRKYtQjhlFUoLJs6wBrjRlFIzI62876hj8j4nh
KaHrpI4TXmtZj1SLiCU63ggvOduOqtG/l8MPGp67JhE1HlLzrWFwH5mle73DV0MX8BOdb0uhqt4h
I8lz9yErvHD8mG/uKxS8cN0FApdSgQqhtWAm7jaPbDG7wIO9YvFIoBnsYfYQTBnoB1wej84hKCr0
XpiJvsRsxRRKLcCi/pzGkXISzkpRI6nqfxN+ESUDSiJY0DRxjziJXdC+azV1jbRwDeyr5FKDpjB9
nCECdKiGERwdgYnEsdb/BBFey/luXItRMQqaPFYGWtdqF0h7/F4JB+KV/EabsaC07sqFlnkVGemn
tePNhvf4Ddc+QUfl4deJqkzXP00p6fgbjEDPOfGSUzEXB9N5Bd+TQct08Di4VRsos2U50t+Dp3xe
me9cnqvxqfdHYSXBpxQ0iK731tBUqib9BLVI7/bhexa7tDjJwlC0JKr3lmKXJPcYLXA2njfwsrGs
yzIvF6PhJ0KjpHG/0qBba9N1kH+hmckvOcYmGviXkA9g+4NAgoF6qLBjbtFP1ONXk7ujUbVybUy4
yeXK9xneGZwcGIyJuGuqgQ2lcyV53hYv4+07pnunMkYlWKqBbCxDOAcer2a0FlI0YQZ69xlFt9ot
VvGcm5hupfTe9k/d0lIZywFOH7Jpw4pftWrOYnl+VhPwaFcdanv+xpGyCKDLG9OtOtgvmtEj7KdD
k4epB/Ah37+pkYccYqpYiFiakDUoTWcXkHJm5W/MU95t3ALUAeDOQNOO05BE25KJPELjYtzbnHNq
tRHHZjN2rCUJF6bgj2v7FcmEW7WcYmGPhyMv6I81AsU/pDmSkU5dITEXgliV6iEmqchcy/xBowST
Zpvsl8Ws2WeIK6XHjbIgj9q7hN2Jcyu1781m5s6GyYIfNHAGhxk/aORwA+NcnzBlxSEOjda2FMlF
7fHAajD5/0/Ekc5z2tArUE7nYAq+ptUmj/TXWdFes34jR/FoVyK9lrknJQ4AxBWl85kgsc4pezED
qasjO9l12ZaEGFaG9j/ALZmNl36bXFbcUdDAdOnYVogXbdlpX2mhE6j3nDbOjq3+NGK5pwHAj582
rDW5Bn3llfJQbXf5cO9tG04vsD6Z9xwYg3nqBDaxPfM/iZ9K6DEBN3bGQJImD+P5OUPr9xqaDJ9l
yNQfFtfdl967hlDjQyf2/DXudfKWb7PIcoFHRm9T7QzmyqAVT6zladZBUSzL+b4/5HzDT9I6K7NQ
Og0dueieAte0yof+MUxs22PpH/KYQL2Mz6ZPUWhyT+9Hguf2JGKi/OZP+wAMeN2rE+GzeYjlyHl0
w+U8eMLskSdun12X6HyguElcgJWtGmGA4zLmvazSB5gf8qo0zy+Y3rTk5J7I6gfG0DV4S4OHrrzf
6tcVFAgSDmUD/UHPxBcBVVSOszlnu8SA0LtNTCBjvHtrzkza3vYw8ZiD/6roEz5AXjWcyIw0Ztex
tREiWrpIxZVxBPF+e/2QnbMcer8Daf1hg28MKg7ZnJuvZ1ftHM4WczmKW4+4fgjUAclggr0hv0Nf
52XhPHr1UE2pOVL193yVDLBANBaqMaoD8L5RMUGgGpzSuO7g4KJvCaDO7tSH4KM6ItOkQ4hylbJK
28ZWnwCvayNjsG0ZtF6e/qZMaxgeWIH/AiveEOsGI/dFBEnLLf6tqGqg8JbEXimqXxmvt8isxkBG
LHu5MCrpmDW+stNY572gghbqih8woispCJHosurXiV/LbTfrlsmV2evoiqX5vqueEGfWuXLytxUm
gI2/ly33Yz8mCTfdF5H4C/rYMxftkE5KZInxhI6TmOoAhO9F2fq+8+ZNDtIQukq3rJM+r+tCJ3C0
2TKrN7ocjd9/ydZrexXx7KiJIscHrErYvcHMaHtlkqmo3WS+bAG8w/vZl8E0D+mZJ80BKI566XrQ
cOPn9yvG8gQVcCiJAo9kjkUxy7r+gX7qGWrxP6tS/V8ttA6obZmrDZc326lVxExJps5QkFbowmlE
gaKume8oDT78nnQiPb470mX9nUvn2I7PpfUtkCOBQBi76VC0Q0B/UaXz+tma+1HTsvniDJN0gvtd
mqfemefc89LNoMhj9T9qoxqfb8oUxTnMNvK7r3GH8nAU1Dd4V607K1YsfkdxBITtCbbV6MKuBcTy
GPNL3CE2jVL7muT+Qcf/6+kSsf2QVXfIowHxg8cPSJdLujadUTx/hkg7uhLheZsIkf1nz2IjkB3N
KG6/NzYcEt8jYjsfMfAb83ro1jkDZYAww7ESce49iL7dNkrU3+uFtcyQO+ndZQOA41e/N1Z9uLLl
3Ao4odMAiCoK6Xdkh7T4LMIUwAN19v3r4rnvvy/BPkNVMBck3DkEdMtQGfCiCFEy4Ctne++NqB55
driF5q7FrcFgHQlNXqX1imF1JaAYZd8M1ctPxaEUjUGPJ5M+kLOxNpTHzpcZ59VR7nXjaa1qJsHh
lPAxdB1+RmYQJWw1I83TB8HDeB43CfUecIw3Mv9g4SEdu4eEru5JxG0NbSOtyZ+LA92YXsNoydlS
cOVY8zt/QCv4nQohYy2T7/ucnL4bACVQWu+uYOzmFtvTqRYB6MvtkiQwVEXCp81dAj3zt8jQYlwa
EK/WNG7pYbr5Tnzbw0EHhXmzkXmGBot/pPT5fgld5nmUiVkP//q/3goT8S/LdfHFBIBVbFlVYiNH
BR8PeP/OwTC/rugavljlCnjADF9HTYdjDKWPEs5LdfuZ7FO7gm7MTFX8AqE5FsrSUncO5JOYCxJr
zLVbG8ITNfHbRGX2tpILy0TqVMnGAULJ2soLRhQq4TM7EyB/as/oJmAZedMjH7hzZ9X01AOX/YfE
u9yzFnd5Cn6pSP5PVkrFNrwIkOJAWFaHWOfLVVRywflNW2F/hlIYnXd81smJljQ3RBiC+MF0UO6G
bipiLnXH2qIBQ5quzj6V0eUaVwuoSqhXBAjb/IDboaAEZc06tyJ021f0MgkWHU5wDioybSwFdDlf
Wz9CgZB10fS7Tr5tq6CBv/wvGTE+SXnxKU3+Et6+SW0KtHDJy/1lXDtJ1DwY5f4X9VVIAnQJP8XU
qDSv1GpKQJnAhUYPGaduOBOH1jhwuI18YN9zkJ1y/iJLts9sa+bZpaO/+wXNI0JMDWKFDu2kW2D7
Py40oYAU43ZSt0cz9K/OKQ02R3JWpJUPaTs5OiqNSBCowZoFbtN6jzTpeqOzd3DdTBIw0+DkumUy
k14m3gIaUMzTZAjenv5WNK/HA4fLnV/tRvpWwO05ALAtbU6Qk4/gSJNRXiZy/Wp1ZQuhhHZs4oiv
my8N8YeKW5qG7tMwpbHr5XlQrKZxYlwkuOHW4wlf5edj3ND2ZCiOSR1xr93z2s0y+Bz76jjnn7WB
H00PT128+QpdXWgccTq3tWArOJmkV196J4dAWOg2IZtvAihD2ryIjmjs+RP/pBA3OTm6RJTcLe5q
y+7RXsiMO7cgXVVkI0J3xc59Ze1CRBP0mGPfzJ89GQowEYk+3XUqCh5W79VNoNyQknGvB1lKw/ev
O6CuvrZM9/IZQC7POhunlIL9chFHzJVDI9PrCvt6nHMS448G8vuyrrVuW+2WmbM4oFootZq4ilRR
7lS4U0APMET3ggwHw0vz7O0oFrdySmom4ypcgSVwOjevXTitBxuvmcZf9gmzMKrDzDfMEM478AaT
huK0gilmGdhHzIgyYUPWOyv8Vaglh27VCwexo+3Ukg5wJpRCivfmeM4912W3T9jAtlfOi9+eTiS6
mDICx8QtWre4sfCkWoefA2XJcncy2BZ6Rlty0JSdxKW6UYHUVYnb+1pnv8ZTfKZytv6XepSrQA3e
prJAidEeYfTcZRraDW9bY+ZdCP8e1pj+EdFdlQn4Yu18OfTXTvH8gj9suDD6U/UirBQdjIahYtYW
oOge3d5r2N7hdIHxSPARXoz09o0ltd+ZPU9zWQ3E15BzLkyqiQWJznLiRomX3i02yc8xdeo4n1D4
4xTcN9O/eBtDZ+wrsb67pYJbUMCRVkU+tcdUB8gnqL9Ts89aCvC4VLd+mfWehWba3ei+MmMKJBs4
MeCE7872J7ux668XS+OlL0SydElk0miKqYGwbc/RT1uBx1G9GDGSldkC9Hatzi6Xjw+0GDOObPde
bNI8QhmKZiAjJmI8S5NawGdYVpoM+SDRmddWekR5SGciBfxYAcB5kdXudaQEOka7d/R8j8Iy5x8A
6fejFppYhu/RjBehA6aRvkrLc3l6SCQd8QIh7DckxoZw+cPH5cuLaKZZwK+oaxsI5XZGWQ6RRK82
nncH/K5vwckAj4KmPp4To0EjMVJ3aXntHrdJTuJ/bmHCbHoNV5SQu7Hur95rmSVj4jydl5PZ2+ZZ
QUQMzxiUl5c1scOL0nkyT94RMZqlUeApxe4EkF0h+QYpKt5N1EF/GBTXHu6OU9sUjDv1hQgCkk//
5LAMM9C7T3sOcc7+P18N6hpQZ2ZzCp2dmLTSLDU1xqg94hatxNTg9l2+BDpIC7Rea/5qEVtyQb49
YD0jqHxlOk4LlqAvZHWUipoRnV3UJWTxrwSns0StoJ+659zrfLDx3yvaw45FDNDSKQHXFsyMvq2u
REblyalo8OqU8WUxaYTZ4pK0TtWTNT3Jxd4JtVmkiP79Hpa0mz3oQf0b31igj2ij6sbwZ7CWe0CE
/lrep2r5FFSEsGLYWvNVQKQ/m98q0CBV3cBdibyTcE4QKMHkaX8KZD/L11PeWTspMYFesbAcLtUG
/HjwM9hQS5LAhFsUDJq0PuUHr9MXUkfgBrAPyO8BBb/PjTkQckcqvwnJF9LIjombKS3+hW7VXrRC
eN9t0qyF4WMiNC0FJOMc4OqZYz7n71R0yM4siXkYNzhaFq1kDyai4QgxlJqLkPYBEF7TN+inJv1C
O0Qbqnv4e2pPXDhgU6kaodJ5mXvW4GZxecviDbdVvS1Tx/sPMuPd0hmOGHzFgpa8EQOoDvtqzyZ+
Cray8x0GP6fjt09Y0KCfDcyUr4fXS3NkLLHTwyahRQSTXfvhYI5IBsBIFNbbA7O39zuNDb93MVs4
L+8F0QKz+UMcTwlVCjy7dfmn7iRtGx+mYPr5aElcuGH6BHUh/Ik3c219rnVDSStduW/PFPhHyeQq
kYNKt6MQPWlGSGTr7n9yQKHFkPHdb5OJQCQGqQ5njHQFjRmfcxBNrDw67eS1YsHoDNmkMhCVdAQd
Ta1XnsTWbBS7FiagfRGldgDuBW2uo2lQht+0IWtmktshMzqAnVCZun0uaVW9Y1JIbKvvpCmNE4pC
xl2d4FPbsxN7Xdm0QhT2xeghe6C/bFLOZVVLShA6rX9vrPUb7MvM7ugbnEL4NK9umbzRBeJ44+qw
Ccf2xYHXrDLsQdaxq/7FCOQ5KjJbjPGSQzaCgJHpXbs5t4gqRsW0s2rFR4gWxZWrhybGe3sEbwbW
xjAXlEBb/OEmcZYIsaUJLJ4WdjfnGB+K9T6gjnYiNvp2jbLlYtD3EistagM3Zkd24Ow9cZBhVXeZ
aZuy2ezkSeNWi/C1xc/dkM8JGgG62cez8VkxnBejOhQGrsEI/tHPU7vRs9z7dYUr7qX0YAAfD3Uu
sy3eZgwm8yyjLh+S0/aZTfMgKvYNEY88UJFKx88fFxd8LEe60PkUc6wlEp8+t/uEl5IKSPmzSgaZ
9Yt7POtTWPJwD8LzearoaKQw+A1lbmRzdHJlYW0NZW5kb2JqDTE4IDAgb2JqDTw8IC9GaWx0ZXIg
L0ZsYXRlRGVjb2RlIC9MZW5ndGggMTU0MzYgL0xlbmd0aDEgMjgxNDQgPj4gDXN0cmVhbQ0K+MXS
KX3r+CygQP2EotDVHyzqo8Ik92Rxp6FaXCJ6AR+ZXYdH9TLVp3WjYmJ/b7o0oDR4z1QNmyVzA/6z
O9kSp93exca7xjdm5wjemWXaEXMqpOh7nmIbh/N0dNrME82bDT3bWIUf7s3qY/x2GvG/fYRhTwGI
1/R06AnQ+C6Y9t9B2Dq0rpfDruM6g/SjTyF1ShelvORjjzRB+FtMoU/GPABgRhNlG5ejo1AzfUkk
sHCwhtZbsmWoIhKC1dILJLh0JGUihRJFAST3Z+LNghHGKJxly5Tbhch80AaPJRhHuPLgtMv85O9k
VVAc+w9ag2Gn382g9xcBWq72L2g4VJJF234rj1EgezHIMt4iDnS3mALB6WFqC8AASMDcXL+zUBp/
ZS+hV81kMIdgtCmpHXHuqElyTZ8+Ong7PrRRq4wGbwJlNAbDbhQVu2hgrbT2SB8EwiBPh6XR9qoF
IO/pM1+3Wp7n6we6OLEOhWzPd3uvMzq68UQLMTkrqfO47QrpnUkmsEBHVsUCH9adUCHO5F7TO4tN
a7oDsE1N7b1SAMCYOdNaRlN+cmLnY49VBhFUs3r4BpYbvCZ3goH0lLnhTW1m7W6fBAX4gTd3AlzJ
M1Atahs//E/twwlTC8sUrX0Pc/iEdv7xYrpHYBqfc9uettw4ftF6YEzugzxjymVxFTvChsnm1/8Z
iE/dgDGMrbSBc10pRJPC9InV9nSa5cKicEkKZ2rUCbCECj1TEwXzDLA9s0efZYE/ILTFYKWx94aw
YoG+2sJRswyjTpPxOZKUk8mSXoIxaQY0nALFA8bsQkoK8qHN00h+8PsHi1FAA1LzlrglWntdpXFA
7bFm9R8VB6MpGzcEXTNtl8oHv1+0sibZu6icaWbL1SJBjJOVzQEcUs3Aj65dqqCpxlbKExqzYGiq
ZXRBvNSJ1hED3oQsMN0kDGcCkqtl5YSn8oAPLhZ2v6spBE2msbTVvQVO74jGUHlxH2bMGEsOjTJ9
HNiA7C1/DIw2Pc7h306gzho0G61xH0J84rIwwkSlZLsjGJGcLmjCtaf0UKyI8G7WYDHqM0QBc88M
ME1OrLCAPu7VvP1SD8Efbs85meyap9ZVV5FxoxQuyiZ5Im5OuIkrijQKwHo7Tz7L3Z+v/ndhSPZ5
fKppmqKps4uKF0y79eGsLl26ksBf1OtxPHqK80gbN7lifW76An5I8m6RCDzkpbzp+SL26XzYic60
Xx5Iz4wrTO6Q8hYBqwqCRo+QliQ1CcW8v+vHB7QazToUzxInZr3homEbtJXXMSXfVkbr437+XcWc
n85neZ8p73+N2glni50QzLRU/VDaQ0iaoz09kBsrlePOcO94pu7Pk/0/ywssVkaRC2LtuXlH0xMK
fBDtU0XwK6ohJd/nenQaEJj0kkOiQqOiNlJQLmvs17Kcyf3uc4FO0j+LkFHVg4TT2k4o6NqrI+ty
N7wkWHlUIhjVfjBKPF5gxE6s2FTec2+oCjYArIqZKLkrBJ7V3UPTWkRIkJaSb7GTGGOzFCwS8aOI
QOuNKtM+mKHQct4TBCFis0vtXNqzV3d17cNFozc68gkMVZNsSCt55Kv18eQlNQmSduKuwPh2qVKq
q/BCVMdI8iMNs/jBzogxrx77ry+KppABsXLRZ1QviQYp1c9rL/cZRVk4NKABkVjN06J0ZdtJ1GmB
0cGFrCJ1Kmn5LIU4POcml94ilSho/Mnv2mEWnhZZ5OPo8RciVvgvHeFRuGEhNtIqQfs0rPc5TLpk
VyYZh4ZCMKZ7Eaiv67V/4lzwFEoEKJ52yTvOL2BtGy74B8IqpX5B2CNIZPtb3CbVzaHG388lTQla
J7pssY4sSxYc2QPM+HSzUtVwMqA/MsDbtj3h8zFFDAc+ur9rWl84RpWXT4zs0Ua5grEp2gxqCd2R
75BiVyhUtePtFGh2Jj1WQJAYjJVF/Ka5/BO+9WWB39IPrAiBXF1tbIo9ES5HmTgQLluKrxf6xD/g
WCn86AGV7tqJiGyb1EgPuV8AIN54e7BiN9Q1YVrh6OoKI0etPDvRj9eptvpQk9FEfAmVZ0R70cwj
lAXDFmLbaoBs2qc/IEm14btdEg0J7ijbcpQycCN9qDyUool1s+Z7GEFUQjarSi/3TY+HjI9jhedA
iNaRecD9nSht40dtfvADLk8lwf9CWIISy5wtKz/qP6hO4GVVsBwaEH1sPeU5xgHlEIBEMHhjBJbN
OpDk0eIgbES/LYKDTd4OApmuV73H/Kfjdrxuh1S87VD+swbgELCKaRRJgyDZcoNVBsF2pVEM2Rh3
39lKJVMbtlzk0cv6XmpSmkdW3kAxVnlm4LaqUjB5dojt5lGnh15SyQvr62MO8qsNXcXfiwLXjQcF
0h4XZ4SbWr6+N/XN4x+H4DalNOJO+NGuYFxk5fi6VVQLfteHf+LeEwSbjC9GGDEwtfDGgh5HkDGS
hba761htcx/c0HPVynyGzmcwEiQsW2RQncsQoIooK4HtWa8dtGVra0JVG1bfGf+54kE/0gYupX6a
NYp2Oizm7pmR+vQTXKfSmmMD2v61IWBbzyFKRljjip5o6EosTw7Lx2M+PyQtrICV0aWgI2gT/AbI
t88vla5l/OvwQchTgjIQDxBOcrfUjIzrpBh5eQdtSzkb5L2CzXdmHPYWskFZca67it1NwxfW5JVC
XQLkF0/m4qLpKsxFBiKj/h/8y5z5x3q5PdU0TUJV32cEeqaxMlTXndHozpShzXC3DsXu9Tm4IOTo
j4KRVM9bl4qXTVauPuZI/weEApnjLePldyo+4nz4X0hDBtibZFkVyEb4W2+ikCShAy1N1NKug+XH
utY9kn7HKfY2Rh0fSVoeGPcfFBxRgx3l6GBipxpSD2g4PLJwCyu1xRzEQjeIqog56zuxZ9cYVpJ4
r3cCMX7CwgPIDJGf886n52Rl8xgRsNJqHNKswxU4kiSY7DEv2aOXOivu/7uUAfne7ml45wPIQiOE
3UbObASPUH7g4U0VllwF1dbnchKOUJ2ba1iV4SUR2vMUsmRssz0fJVle+4MZ07ueg9hvulaX/nHl
kN4xNdxJzXrQUVYzda+AhBw0Uz7v9JH+h6E5fq5k3PQEcpBSq0NQJMWBiaY8iLvIaAxX2ZnWlVKr
1jvKINdDjr0KcrVK3iEl5z9qdgpoTKJ//Hnong6BQp3a9VZLILOkSJJtWgpxqY02dkN81EBR9WeJ
a2PRkApsZxxsa4e7iw2Gub0JcJp53YmNAJTEJM5Bfhvb4OxtvClNHHWZ6ktLMnCDHVz5Sqfkeujw
tSQlRgOiy8Ey8q5mqdthr1XTCaDD6fTyRDm7WHO17LvJtOz1+eR3TeWhBxmNi0brTE/tzI1vXs9L
0a5kc77lp92yytZdZDCsv80XPX0A098QTzr6Vhz6w86KHyhZl0m//nvU3zwQMqIOzytB30l5Gw5o
X8lJtu0rMDjXeMPUa8Z18BFveybUpSouS4s7kme2rtRCofAehftXfwWKef180vXsaYpKZeNUIOC8
y7djsM45Lum/V0iGoS45+X/PRrrjPGkMUh0+s2zB8u6uPwEhnkT4C0rGaydyuz9dyA50Kv9zdNqO
OAhMjCxB75i0gGczISWeW8O6rGXOSu+orXvYwfutDvkFyGcWVNowNL6oIzHRfTPQAoJnC57TAM4e
QiQYPPHgHLWRYYQqhqrect2HR5do+zg9/tb8/BWyrhUc42UTw8ctL9+KwFRs6OCaAg9/lBG6DPGv
3QhMW9ulbFocJ7QYLDhQXsyZX/64MH9dFo2nq6NhUO22+XRyfbEmIhFc0RYKhx76UUmhZ9Cd6WIg
rll4KpxlkbJa/pPF0+YulGQlNg8FXZeiDimW8wCLlVXxQvYRAF4VCZYd6pEr2Y9JJHEbIlDWkwYK
1FJYHmTbHHuZmeeX1EGATxVuk5kC+IQn6nhAceS5f30k+vUjzc/sHEOoVejQSXxn9x59p+HAPMj8
xcbJkb94KUxVE2/9YLhWxnl5bzCY5g0Sd6k4lxalPVldK0R7nSL519uhYjPefrCl7DvLMNTZK3Ut
/CLX/l1IQltxrqMUWwhjzKwxV/YwBpZGHW9+s8VgjIsnzl/z1OfzK397e06LRTvkc4fh11ZHB93f
Pr7alBFyTK7Xf1W+3dMP4GG2OYbNUTQuBTf8dfDupmILhsKiFDDiiJGzamxGsGEPBoBIwHX7WTD6
2BV8ciX+U2XAIWV8eSwmNmWWYqdnxD9ohOEdfJfbXPygqxvcwH0YhjsiVgWI24E1ElYk4yeYe3AL
VvfYitE5k+j2YP4xLQPXpJatfRrnA6Z0FXeFa+D6T4PJgy0h/FQbZWqNPGi510nyXrag4d7yWdTR
zGvO1csp/Bm7c9vmLLe8BQvbY+DDijWjDf8RiWEMJ5GibzBhE+Bi7rVjauZqlFQgxB00jCtbm9DD
crhOm+kcUgBzTQPjo+NXx8SvA8wK587kXW7yVT3Y41cpJDgWRAZMOrOAFU47qdUW+vviaiHiuSfh
sLlb3YIVocCz2fvqLNXkBJY/nOrbJWsY3e+e66/c/IKvsCsaG/ld+7hcyt3iERF9lI3me17DWrCf
YBtR22HACOI/CQu9lr8t8YjAzB6tJYnB59Ny4O9zKnxiIxzvEoWeQ/SeWeDzx0PigS/FDChSs5FO
Ml5h/rbGzkfF3+qalWdnlkntf4fI7pO/sbVbxRlCICvK0USY7HqjYQfhOrFbISzzusMUSXdDkfXt
21D/1jaI+fGsuVDrhMXdf1BWwqCo4iiqtqtG8Kll27Grpvg4k1M5fbL7tZwLrMSktq/xpgMjBstL
MryPsEKqPw3sH3pYSoN0iQGcqM9jGNzqZc0WOVekU006zMUkprmHGN3EyL0fJQr3JU7z9AUBeQ1w
rLtXPpCJe9UTDw0byomgDFOXsvLj3c+wXajvF4GfMVRgp9hxRs0kn1iMOpourHDD4XOrNB2G+0cY
hlCSrSJ28kOvq5tqllkep7elWp/5+smb2hZLaj/X+dfuwjLVJfFlBIUbBFRbqyBE6uGBmfUPTYfN
8DvoWg6G1UQz0GYYv05WTDACYrrAlPSOVQWroXBWNLUucnABK/yVT7+Rt9cDRc6TMpuzLkDnCUpu
gdrKi3UOFc4V+aWDduHnqL/YdvzRDyS7UGdkmy0uMbf04MwiW/1ZcN3d3WcykeoDK6Pw0eMAM12U
aRVG8FXUim8I7ijMtx5eRLNomwdV+ICfWtENWdxWXygE76Nqg2hP5GXfVS5Tyz+kIOj3sggtrVAu
zyRA5Ga79Nqlz6FIOWg2BM40qpuHXNnZjUcqWOEYbtah/EQz8mU65WrNf3rLmjkoS6N02TbvcCpi
wq8YpFWujNppzRVJR98cmVy/fokxTCH29l0Ta8tkQPgY/Jf7d4UtIBIgEMhe7AiY1Gayp0xkuLRl
ich4NePvOmVZYIjwdvQKCihX2goYfDl0j+TJi+x5pljMzuKpQOyH1hRGksuMFySfZh4GRi/CZDQt
eDmwSEICUMEVibrsD6J1T3t0qAJNFdBQ2nABDnrM4mGeAJ+g20YS2HZo4fKGGJGjuSayfVvt49cw
DPIGUTNOi1vDGvb2+Mw6mLslSlVNsOV2hCCkbyU8eOFGYIvt/TTlMn4ZxEFyl+SCeZzwwQa6n5pS
geO4D38iJD9abwIg+UzGgtsKImnJO8OI/vN5b6oYK/Zm3QsM4oM717aYxaIWCrXX2AtRtg39Sy7F
pi2I0fAXyd355UaLbkZ02SPsz0c146eY5UAbUXx+OZX+7xoCyrn4KFR78emj42s4f1O6zswZGRNM
R7GVMn1leSJ2+6iPZzUP9eAwtdlbn+NudIWdTpSgRpQVraPEqdgYiYX9I2gL3VXc+qSI8Lb+l3D/
bOSCztRZ7JC4nvm0FjrTP1YJdciUId8hXJX4I2e96B5hPSo1BiyNqnoCWyE2Akxe/R8D4csykC7o
tksvPGElPGYxEhWcpSLz6to1iQeeqxm3nMGVZ41SgnuyGBnrv5ecb4ZL7mG3bvIQjQrrkCNq7TQr
caqMBR+bzab//bk2I42o6nC/KyIpsmgLS6dOYScLBjImmMYB5GyPYRYTtXtuW2LQBTThpILYqQ+m
WJSDQ4N3vvDCjNSN4lOemB6MSsQg64RwKvvtoaL6WVD8bkiXH6dh/CbHOzOuQSrAZX7nA5F/iIaa
K/kBytD8G+IhY/N1kfEihiZAfNWATSClGOC8SqHqgr3iKCMs2Qrdln4v9EGE+AqjYsggpEFkUFYe
mY9Z50XZv7BXVqzySnPPu23IbUIm7ry7Zlf5Pmt36n1jTv5i2jpRY8OLghXC6d1V/MmjtwDJfXWq
u5Get6dzmlyXfXNYySU1BRKwf1iiKs41MPuWKH6YAGCKwTIPzSZW3aZC/XQTdY23qVpWrobrCOAv
YvJviELai7ybh6rqYg6FmBjjTyxQFKpodi2V+8jtjFrstS1onBXCy/AwgrkjIjRSzzMihs4B5zIp
W8wY7tEDtFrv2QTyI0RIPbfmmOI0o/lBOg1V+LTsvXlfwkZqk87dZk2t5+n5gLZ4EF+jtg5WQbEy
bWttrb74+men2VvXaCKXpzSimNYjXEM9mPuidcV1w/0CiYxDg20Ur5tEMR2Q+gPhKSxOpZKxLTnD
1g7qppBwadB/ykMriPLSvnLpzMSV4LRlXcT4TOD8x8/QU03JBuz+6nXFnyWTSBiJmY2DBe16Mo+y
BgcZSLVEbym8qH4IGXA6pfzFtCqq/3lkasFQtF1MIb28lsKp5lrmI6LUxhCjAqY5jzc3BTdEMI3H
WLpbht37BX/V9M8u29H7Qg/58fn35RTOotpbict5SuDe2FZHTw5YJKxA5ybK8BygCXrMz4Kzmezo
YQGZlhLh9vTDEY9lA3XrjwoVgSNUUIqzh3+dZubj8Q8MEgk2qKcc8gGWpH+x9U6/oBHX0GydfiRL
7k8rRKeZBVyszXQ6GNtSUXFqutuQ1rbV/sZyzd+3r92mVYVb9EYfwvp+GFrjaUkepAwFL6SUfj9w
ScZ5CyINUCgIowEeMHSg305ZCWeM9oADSLFAO8s86QHX6ZDdbL0ZrkZbbXvvth1MjAcTrmeFo9gX
6cnIrsVqOhbWiAnBoP1f7O6RAiF9B/kZwJR6txTmmJTCRZTzE7osOvl5Sch+BIj3A5bAOnMNZx2W
Z3UsxwOIiaCGJREqRCS7q7sbEvyo8eVl4botk/45tN7+iLHmukEn+uYDTntC1y1PvQp03sTt4e8e
dnvDY3PVkf3gmzKzleVElCvC6ed7+6IZEJFJxYpr6CvKoj9PD1MDB2mBotsb3aMpne8eByqCkOLt
NZdhe707Gy6zjP81HewM3YfYJFzKgwmTuFGHwJuieOupChK+F5vwDP5u8NPi980o/TDrQwhj/rV/
ca6eTAOvJWGb7ZcV4ETH6SB/HnJ3K7Ktg1zGlRL3gcLE+/a8NviU88VPUgLH/MaTDx8McrCfhcwr
3QZe/ZyE9MS/1kzgc8WllGghfXyTmhwjoHIQ+Uk7bClR0UuUK6gweS6sDdc453wUALxgBfhcKRFM
6aqAuqlubFBGCq3FGFf6npboyvC5ae1nm+lo0X3ISYIP/Xah6A9gBkAAUE+zf2qzMpxDaoc9Yv9N
YvvRl8+nR5dg27CG1TwENpgGilCwpJG3WnHAIsreH45pvqbK1lsofCX7bn+/PJNN+SDJ/plroi80
tb1lL8tdz60lUw238tVzb+xP2QUV1x9KHMFuJ2Fwq+UkNGpaBYyNfcMOLHo0P6hSpCJIO5wcZqEv
vsAkUFikjvbSdZurbJ3MCCqJnZn52k1vvTbz9DCoM844jL8wy+mIFu0DrH3nuyeszlACGntL1Np2
dhj2lrBQ+CUIM3F6ybPonodah50+3n5N7N6f2dgvVpAC/3pr7dcmXQZ3qFaH83Q6AnI4BhFA84/e
oUWWbGKvtTxIet7f+gIz1MZhHm5PTaglMfI20g4jxPDHkXkqRiBcIyqMsUfWSCcWFqfLyqnN59r8
dPMF7Xic4se9ieScLmAm4lNq7zbI93p6HSVt5QF9P/sZj9KYjMGiXa5x70+6La66xihlsAUINMuH
am91VmR6VYY6ATQXBcD9AGI7SMDHGKzlEPiPI9uuBVchcugkVb7DNtziOhblMxd6msgEr+oFhnVY
QxyGLK4w8srSLj2ROhbcMJUu3twbzB2vjrTmX/OzNed4uhUhiTIp8jor6E93FD+5b4t63LoxP1gO
5sXHQnL6GcQIJc7czofZER7cfdDPvXXcuTkyFivjqOxUh9oNgPj85BThzDVHRnNT6s0256JP4rQw
vTVHhPiL3m2b67rIExx73StrqMxp7w9Obgj+xU2uHfCh/3QwomeH4RR/agBVlxUsjgxMGeU40Xk3
sUMh3NiA/RwflCR1DoWkTLM0YOPY+LSgsu+hd8sMTdwIRF3Ux77+TbLF/i7lD7HGaX0FkMLiplra
BbfclUoC5NSbTHHCujAUlPogthFUS2KDeHNUyC1TIvhMhq7X6QikNa8q8VxAzDLZxICQXbuxsFuu
NqAZ0iZpI5CDVAeZPIWqtfhzHoW6x8HHA7psX1fJ6Njknxz2wRsBucOEeg3M9uFrePU71L/sWY/Y
AuA9DZ6gx3OMq4+BU+lXfHMfl54dAqhWYJ5vm0jMILaXnBXZfwq/jPI3IauSSqGRChxPWiziI7RR
FW4LOHr8lytoZojClFsFqLcy37lrPiEROPGNIB9CsXuq//B7qVCuu1+4Y5YCy5NRxrcGGKAQgLrV
zfT3GUFjl7BCmv59OQVsfnAjYgpxCdV8zMeiJDMppw4jFWx/EHbUKr2abvSVLYMl3zpOcefSuAA8
zVc3HKAFT8jD3Z066+l8arEsygn5JhEkftrCBiYhTiDxoGvPtrs/LcLS92nLZNwC53tNIxgqlCWQ
yHvO3htccz8ZZmp7ZpMf2SgUsAhuhJugsxiVEUUuIk8bhoyAXYEC4JFkJHRKtbETqvK7HBtuffBS
mZqYHwNgPCkjNDmhXiWxeHfU4VUdatDweYli4SAlGhCAEwqPHinHUp+7Ct7GHxeVK2k+1gf5Cueo
HgYiNl6DYeMJhFV0JUQUJDRxrLO4C/Etdo+Eh7z+Ox9rZej1jWmPX6ocdm7L3IcGebhEjaF+nf+5
cSIMiatsk5Ppd/9ghnrsrQEX2sRpWnd/I0l/2IfUMjExDT7dzbYCICVAzKOcbDP/18hLDlnSoUjm
FwQ+GC91rg1+QUHOmkAD02sHz3eYcgw4UFnAlU1Rpnp2J0fM2YKBPw5dlKI9LdCrblmHyIEXn3k6
AoUuG0mROiEaf7LPE9F2f50f4KLTvxUdLxUykEf8U11J0R9u0h5RS6mx8SDa0QCSKduiJjKoVyZc
QZmLA4JPGKG4FpQxQIXicCwbCBZ+K3IFCBV1UPxUzbry2bL3/99gAwQNfZSEilSmmng+ZOw7+UVx
VlUr+vosEALMGOx+/n0e3eTojlbaMb3eVAajUg2qMs0ooVO78/Noj62RA86z+Jt+Jhndne7Hl5G7
+Ntp/+nzO6m+aK2DXHWcYGNEAGMjD1s2NBNgFk8GPtXbE78mru1B1UNmwDc8iRMrEhYdOMEY5Akt
mxJtpRMoi5NCh+8pTqZYBita5eq3zWnKLnS+8U9P7lmmxSI8JUkMPuuo2jp7jZgLpmfjsvO1Ec09
eY2iXV4cCKmaHY6vG265hOGrA7kZb6yO8Bm7RlFaLPRi3FWpFX9lQ4RNgEy/OzCEUvYrx9GQCo2B
X/Z7iweul6DUl93YWpOcFik/yraINWBUuc6R8aBgrlBt+wPniJINzrHG36KpUy+HzA3Yqd3vXk+n
mYmPnvR4YwB8OZ0dG/pZHQtI91NPEhiJNgZ1K0qZEREpC8919tfLBdJgX99tCP5a9r0Wc2FK6qOw
PFhbBINO1SwfHm+gnKx3goKtKOqNkIgVyCvJBZboI3janunkMi7P2ftjYsJIosHVs6Ql6V++ub2w
z65cgE+IF7HjauQRMfkkmcFDQtqXTZkyAbhXhJTilZ7dPndcoGuAF5RkxFiPpC66vkjf3dFWFbdQ
TEJ4CE0gVOvNrZdcBdlhZJXkCM/SszD4Pzf7UIF0lY8Yw4YRF1LWwo1eASZTvNjA1bn1A5oDhJnQ
YOAHF3ujBuzo/rizxWdC7a+mfXM9Wml1D66ANguskZTeYfRfUgDskaMsPg3JY0/du0ujFukr5toW
qL+q5DOhaX02pGPTLxo5BEBDzqzaGZWe8QukKy7ghFbp6Mq5cVIiVW0KZ4TZ8M3WHQ84hTZVtpAC
Imr6UJGospRmlv2T8lzl0OdrG829VwX/8EQ8zrFWIt2eRfmYjIni2z9i00j37B2yq687H3Bo2/Jh
Lj2ADmt3f8+NsU9evCLlvEhlMTapx6WXEFHc3XK1er2a0ecWGK8sFjPxUBo+vwF81F8GtiOvIEkr
RTV8Kp5mmRrjflR5F8JpSCiq3lQyfqMH0naILVajlI4fC34cZPST/SwXAI938vFVroy9zXt73DBx
o6TwoklNl+RsZZZJCwaT4ajJ/Gm0dtOKk0EYDDYIhATfRCef1id2cnariV77gB2oimtqwRa1kaWi
LBHHsbcyb8Xsv0dSn/VxlIYulf+gG7AKKS/XSoOzcs+Al24Jz1QbsnbzXIjaPDdglSDsw8BaXhtR
3+CS+0VKgR0fTfPJDDNXavaQg5Ce3+RSIBnFaux5j76LeiJ/2fa+IPgrZ3KgcjtmC2y1iysD7oa/
LM5O3TeH4F+nFl7vA5byAaWHU464RmfXUbw8jo3Eyg6OJIupIhc6VKKsiQza328tBZfqO63CVdQd
27Bmpt3BL7fF8haZUPNeQRjK0bAWalgk+Iw4ZfKeocztSR3sgpqLifFQfxkkWjpQg4lcRb7e7nmV
zU/tsQFLTPn1145pMOd06AXBEtGoBFjioLm1AtSPnvGnjil6VQKNnwje2AE3mkVMVpGDUOaWNF+e
KWJhDzCNPn/hvPDoCv+ESEHws6QIq3FRaogs5e4IvR5Jkz3u30KGxvrVey/MSRiPSlX18whl6up/
iS3jV6+5AacnIcaz7LXMqYschzFqVYlTkn5zWuwRAzAuvQshs4eO+ny+iNgFYp0NvVm+GDZqOFn1
RiiM9gGk5tOJ2+6gfpQ2TrhEGz20BfE06rEwuSP33TcxwmNyJgiOiGphnxg3glBt4x95cWXYcCzz
kpQpScSE3DK+YzejWKwH4Pjg+OcAm5Ujcql6tgj6ofFNHRMyaR90MCGXQ3AS/goh4vUfAuzx79Zs
p3Ce9uetttDIRG4l0jivBN7K53CH9VJ/C0l56t0gJJwss0Cjq1z/jHg0rPErcuZvVoBZV4PTKHyy
ThpcZrYRHQC60mjQrDEVmcQ59w9Czy+D8B3eeRE5DSGmqPTcwV3uzPC9dzqxdD6jF+FP+iR7GqOd
dQi1cRtHvBqLs1itX3liAe2JVggebHnNTsysB+I0GUBc9gvH69oZ1eyvSpAxSZjMLtlAwPnPrr/9
ykZP4be9YWRBg4WfkjDj+I6eSDajzinBHta0F8MhTRq9p5QZfyEo+P34QjQx4H8rr2cnZwimsDCT
4aVA0YW0XSe5DEHsJ8CD7Tvl8e9Tx33Up5c8RSQ/+A+f2AvJOPbAiQ9B9eYiWlary3haT5NNbBiH
WsLQtJbZejzLWhG1MjkKvqsK9NLLGQOGJBqz04Wc64cL4cdNF+ujqjNOvYWzJRTOgHQ/1DJTL2kc
FGWLfPmLXO44EFztgLJR2mdPbsHFciHmb5pTA6wMuX4PgGLuNq8NA0pNHG0XexZAhQljZY3peRIC
oQUUkcOYqsK+pVSq2UFEGkj2hbMr6GUvrZLX+bkZStWoA5E9WVmUuYGmbkqSA0zZk7LhQYbsoeG3
vGbH2BDQLG/nAV+oi2E6UqL0JytMwO+ncFzl5V4V+ITizqig6ZNVtjDEGLwigcTtfGPxNnbsYBOw
4BcAOfprhe3hh5Q9kW5dGCVYz510bIXDo7w9VybCueSKObs3Dr1FWsqTp0zixlmQT8rr0GIzl11/
UX3NFP3cPpsusErUkBXwnmu+QG5BdGmRmfpEJXZ9YOsm2Y+wxbXxwq4I5ILZ8QeOD2hk74N4oeou
lm6hY79dJVdN0k/aq9fuaXA1kwasMOfHlGsJ57qAimZptdKhEBo1PYZU1j1gZZxI50N/4KgfxPO7
5efYvTGZRPYHZtu84SFY6q7PrF6NrUXmT4sgxzQe/BkU9jXl/1x6tjXmuG7hCPIgePBkak+/cRTG
+ptDSvjnF1Yz7Hrtr2uYY4ydBCBwoOWi/wL/s8JiMOyaQXjIWns/ThjqlL8VeX1cwK8bKdfDX9+h
a1FGgxhCby2V4vLimUO59yKMPnsAE842iWzypQ93zt6XltcCs5K11uSdK3VX5jtO4xe6icX1w+Qk
KeidjIyH6tknFwcYWxGwpElvZu2WCixtCqGHFAmYNV2RPYS1xQm/qkX7JfbgyGaOpmqUOWNws9SF
IIl0f+wFjsIfB7vgtmpAd3Pt1FUz1KWswo2Y0synFHmoOSzLVppc6hR06Fg2kSLP2Yz0nO9w1ehH
J7XajspBeokalace8FS+iaZHPVg9gIcF91ceJ2qhg1nXFyq37gtkUhp/Qg9I7NC6Ys6BdrhOG2m7
PFwMT9VQzRr3WjIwRtkYJ9Uo8M3+FzDXF5aVzo2gPh1cBRUURbzzsC6OwogKanAylWyg9PMF9u5p
T75Wrx4AFmys8ahQSjHArj2jDYQIwW3VPsL9mBgAzhMmX57c9OIP6pemWeRjE8DzGiHZ4OVvEf/v
2Onu1NY23srm3fLXbiIaesXM3sfqdY6HuW8rIMTGckBoNSpg3VeS3h5napyX2VD3e+kyqx9Zz+/p
FMlqco8kRzUJJ9h82tbnyaJ2hByrbQgEi1jpTjXI1QHJSEnsLvqaQ0FnZmyPZbVsQ4IONcmncD1l
6R6DY80muKmq5jRBNc2KsDOltw6zbNQ66W40MSSywISTmIDUW6tpm6JbDTBwJ6gGpV/VA9qdZM8O
qyq3MPbwR51AQcmdmzxTdR7zV1VHuz1h1WgU3eWomUOWoHutPSrgSE6zR6vf7ztjOlK+zF7qlaXa
pFBJ/v0l1gxagyHCFHFFZuZuG/zmaR8pb/a2YzL8PXuTBwZBIMFJXvPAQMcMdH+NEMfObRhoK2pr
30Uc+x6ZH2RMtvZFY7zq98TpuzOwF9dTcosG59p36LCuvxNJZTunK0L3rShCSnJ2virCmSJ7Yf9o
8+DmW+kCqDkUFAm4FAiRCYxmi9aPDpdLuUNUQk+iMrMpz9Zzu1rjssKiv+wsxJSVyY02aZxjtTOY
WLQTY0DXCp6TsG9yWhAucbKJQX0jZlUvk3QdYtiuXA7kfYShBFgEE+6uUctSByJsVt39gBekd+GU
QSCG9AvCCSRVF2tSGAHzmIw4qEVxDzs+SYLn58+RldkcCwDGrTZxGibmoma9/9Q3mqOCbwtWpsn4
tiS47CNipz1Fal1sGMfdHBeJSiYfk1vTdfEPuQfoLzeBf5pVwDXQpURepmL9Mam/4COULjgYeRkj
na3AcLtshdpoyCT/qMn8m8ubda04hplj4wQ9micoseFj4yzd/Ywj1ZyG24pnhBCyVg1DO5AS+8aK
XpnmSN6iyVhYB/VCPWK9YIzPeUJwH1GbVJvqehVmEu4BepN9hZ0+1TGZdFPpIX/iEDEW3AGT/kcv
s5+QCPSvENI/Qygr5TKAPgrTHZa8lvpbrFCrEVfZBs2VMMLrKYOLi/rrXoDeR/UJ6pM4b1A+Xdkt
NwqYnEEkalCgpE54J7RHSD2NrsSb65G6mkKwWOEc6C+u/2gTL71rDLc3etGF8QiJqYUIo4oHAE//
nuTMasgBkA2JFufOf5/jL/SUkOqETjK++63j4NeksrJKu3nz5xa2d+H4Rw0ypf844I6ty8dhdcJe
wd5g1+xcaZMcPwKPPG4/Yt4f8S7gJaaG1pjU6x16OHU1eGOw9tjwqtr/2MFwOX2UcP85F/MjqldH
4z2TBENwSFlzu/JOxV42vXi9oyd8ywmEn8inh6HmL171Lq4P5gBhv2VBQC1OcKFeKhsMj4MQ2aC3
iytZ4XTSaytXgVOfb3ho9u7kygXiV5pPp8YCeME7IewPeISfXX0RgCBJKFvZCKc84oDJvdFHii4r
+JjlHFrKxW0HG7WP1JCG7Tpcn/pUT0vu4sZ4rOQT9VFjv613sQ6ekq3WcvURDk8qtYx1hLglXmJO
sVAyAszyj6GZSl9mfKSZXSNTthtfjfRq1NjWZ/5f2aJ4I59ZAcRS9P+WvRyXcvDbW41rthPbplR4
JkBTAf2WBU+LRfklMckEO0nVTKL5Y+s3uUNsHtuGE1QNqNA1pbC/dOHE/g+PLN4prhWv5l451kwk
Bdr9+J9sP0sRJVzn0YL0iKD46STHDcxwYfVJg+b9Q4vHwip10xdt2sXM2domVLVNz9PRGQamPR/c
wqgYAPzgdYtGCUunAZRuiUfZL8Ro7tvUt2ssHrpCOYPEAv49c0BrO3NrPd0wU51KK4bl/5uYbIn2
1ZSsba18nyIicVGsGV0ZV/QQN54l6gLmaAWDKRj/iCi6KzgsgKlfWBmjmxwQ9+Hn91X9FZX14mbu
kqHU1gzSk9Tv4/WfdD5uspJ9yoZEpkcxi62cwzIOYoQdq32ejJ4EK4odwHlej4cTb2cHa2OhHWxG
oLHNlWw/5aHHtQYO6RmVFC/7HaVVrY9Qogj6YBx1b9y1y1msYMIDjS06pGoyanmZCm1J8RM/8eHP
mic1udi8G7b5jqZo4ONFal8/ZhI34joHBQM6r0ghdhdauiwx4orvY7LamO9p+W/usGQhulE860u3
nvwQsFsMWFgUKi38z49Iu8peRXZlbNUOSqMOpGbgRHRhF16czfoud/9Lk/NxwL4497sI/eoBtvvz
Yfq6HL4oOGWHJlGOipkpm+YQqS/2XFkw9QTQnz83cDXVw85vrbrgyANDPJbBYeH/hfxmKoRu3GBE
MPGxAR6/OuF/eLVPrwrdqIG8l/sIkCAo9IJLoV6qOo4pFjv8Eu1zU3bJoesumezXUb+TzjJksUwF
g6f9wl7cn+UleF5uxzH5r8tfclnU4jMPE3C4ie641PNNhQtCjL+bO40V2pP8X5glOsFZMJRYJM0R
DmOkv49CerixamvbC0GRRc+nteBZocrCzlKE2CtgJu+tbxUySfifxMybnsq8CZl4XLOa4gkTBfhE
8wXUwqXjqm6dCKPsWJlLYsq66VKivgGt8far2089N4HZjrZFdu9VaNZgHLry4DV78X9O0CkWEIX3
6bKSwTuHqWr95oYhB3g69ldw/APdcmIag4ALmmRuxqaRHCKSlvmJG7GbWHde0DfwAm7L8ZEy8fNt
uvHjvYei5yMbWAyuUHQPNd2NPWThpibZIR72IrIFYcrx84YwxPH7vo+gpJFI1MEBTzp9+8WFeFHO
g0qdfzXSpRExwd/GdzQX/Myky0SfZvcIs2bNLtMuF3p1XHO7jeXAOshye09VOBrkmE8n2po2RHi9
ngTzeFvxJRWBUOw7TfTc2XIyQv+pqvB9T6fzaRzuoTqnMcjUv3AP7PfmlZdGQzalVnG4Cqu6gnO9
bSaJmWRC8XbRyG3kv4BuXFZJ+VqRZcCHv9xVs1A3TnzyY57ZBO8FWcho0TXvZjeUgG6a5TQxd2dX
tboei1sjwfM8b20ndrM/UFK+lQXe9Pym7Ic6YR2qSg5mWL3WbG3ZgompmaxMmT2pSzBAzUxWNe9N
9b0VKPOpspz3TAtD9TIjywOXnuiu/H4lgFxykiOuI0kUf3+5ULlwvdfHuywVubni6iQFaKmeVTtU
fZ/mMgJ02v27WYkb/8DVm4QU7hkwAMQOIIqEX63cZitwZGe+TXhbe37zBGk86d+boul8ghDq0NNO
dbFMAyqOg/1CLRbD9Oc3d9BmerBuYOakszomxAH/Cbiu4sSLAfwUD+y+y2+WgB1X5l6OhmgZRDSy
wkU7kareU2ZYqCb/QX617lPzspm5poQjmUuESexk0Wjq/aOK+VwDa6UqJPlctWM+1mLbtD13vVYZ
7G18LgewQ3Ou/24uvz0OschD8Cks21URh+pkqjPO4otFOfunvpzByLvXUTwxttJdWPFYFrMBBdPA
6HKv56WJTn5XxLOMzefL/HmlGfib7ymCBnAazd2BtdWS/F7mdX2qLrYtqBwiLEpflYP0xh1Zxraf
bvHx/bBcad7/Xs4dBRR68Q+NLou08RqBfDwebWjWgAzAgJRxS1ykhF4F9Rscn0g5Iwnv2egUf6UH
lZtA37XIbnXcm4sjxIG03OsXnmq491e+KcXrIbo+LqrKGauusm0UTIMfx1+sq99RhWYUTdeDpxVf
WKvfbHsLJL/I3K4QYIMnrvgxWcscpExkuJA4xMa7fimeXJwz/yBIM78KJjYLfVMInBItz5Bq4/3W
Yd9KYxWKYm21F6GKPVvVBrrqvn7AKicfj7a911s7Y2x13gffuoJcOkOLAnyR+mJVHzF0qTKjhiTL
3v1nLeh5v9AldPMzmrUK0CuYMKmjpEN59WM1LIVe+Rjhf+s6zCJ7YsUHWK21aAXQjeJUEh7IKqWr
FtLyaSM9Z6qcazHHVrUIDaDgLsRxYyrFxk9J6ZcoQhFtMypEo0kQnr+YtyGQxitHNF2u4kT7Qpeq
SKa3KFLa5YbydrCjJgOJO9hgajCzkVdjGSu7ZI04Fe86Wd3swB3r6eayh7OC8sUmNd5uPsj22FLt
I2d6yQgwiMQUlsZ13tWJ7h2GvUoca65g1xY/sivngOEKDi5y450BNWoJS/jtnEbSV9UIRwjfHFzs
i00rQ/zrsjb+qgXet0QIt1hvxcbGscuh2PncBbHXWwu2Ma2haG8664nK/Ht1f8Mq8onjR5dTzzMv
Y6yXF2MQUkCrZJf30z4mL/e3B+Ke8B8mAQLr7ZiXbchEmqQ/W9q5MLOmS3o48i1P1Re0Rrd4ktri
XF/Y5yiFkT+BC7e+DGmbnisP1DjQEFyHciXf2cAcdPWJ1h9PtQGm+TK2rCaIzwE09ZcF5OjNOaAh
o6+Fhkpj0KjXXsIcoOCTSKJuF3b52T+7GALwovJt1Y3XV2NT4nKCHXK9lG8yJhkMpxHn++EUfDiA
AO4Evzm9TlCdisNgAov72+tHP5sADOG0MdUTLKp/kn2UJEL4f95sFTcasyXgPeF8gJwZCeGfTXpZ
PUXHqGzx/0jrqRVegx5xAFmKDQVkvN8oqj2ur3rA4/dJgUEavdBjnskXqQI3MrblYb69QwLlKECD
8qabUnqYnmPsHBOg1tGVRXYXsYN4btd6DpUUc6R5J/cwsMe1TrmS4Jh725NqFJiIux6GeN1dwH+o
1adVp949Dw1zBICfJEVwxzIDOkpKsKzf4Ok38cut0MXzrV0HTUqGGQBY3xuc/7UC38/0nN5nXQNm
2sz8oYnX6BgqwCQBMGxaheC6mko/T7cMGEp5dT3zCPYFcy315KNHBIlqyVY4naOIxhlZumhwlFtc
Zym0iQPZzzyXTDkJRxRn6n4CMybQaM3KicUlMQz5DV4oMkU6AoHE9TbjeCdB8gWp8Hoactmvqn+s
h7t/zk+Krk1FremWe0vACNcT8ioVkM27OODPZcrbQObecfu8+uHGaXoTHHlmmINUqdlyoJI828nk
je0XIGtfXlvyA3X5DJDNESXv3iTXNWaYQhxt4ngWAdgX0ZlYrIy1lS6RbNM8ECIJRYvNVzgwD67f
T3IQYxlfYMe4eCuYo0i/YfQ4X71DPQ7iFYMvpyEbGO5dpBmhh3/hSqgUJH1AXBuE0He/biFE+5vs
KLOUAPVprKnIneHtyzZit/ZmZiJpOCvyIJ05FkVlMp6K7tSsrB4nzRkAnpCNrs4C+nrwqZbusi6z
U9Sf9yblW+qggCXJEHc+So1oCe2en6V4AWPbrMTPT/0HygW5g3Jut3BWMWa3sszn78DOsZnAzp6S
x9IkEiDTtpg2S2n1Tef+qZc3poT5DsDcYaa+XoO9g7+EdePthJMYh4YrgQwDZDcN6Np8DhKJL6Fq
MhJzaZksY0ghdAcQhqpNBdq/hXG+knCLw2vVyaK/eHRoH5WT/KI87Iws4KsARD8eq9Eln13Arqg6
Xqs1t2rxyzAQKCyBcIJ3fOZZmpVSkJG2cQBG+vTFdzWFhXL8jJRHowF5gq6v1A2URT2cqrhimjeK
MUt3PpuMM808z/yYBNHpMIQAxiF7P/lxMlpoOCZGaw+QLd5gMSivRuBJ0FT/uQfZQHcpAkEb154j
ArV8p3M/UuER5Ku6VvHec6n956dIO+NoGF+PDWv07bvJDckfzM15TQd3opK0OnH3sXQEXKHelh49
sdVD/JKbhQdrauRSRWBsU3SOYtCoZcER7da2DOZLV5z08G+vIUTDe7l/hhMAZgTNI+kY6dwQXmGj
PPlg+2N85Ea5QlrjRcrgzt4F4mwACN0EjmgsG3P5M0+pufb7odRN9mNU1u/7WaA3oG8oj65IpwNv
jwUvnsINbvdRiJyStsMxzkphboBj/Qk0n8lva7cE20leI9WRrWdJHBrrEjmwlG5Dv710Rw7awCGN
213J9d21sBtaLFiOBofaL3B3SO5EVOHeZ4sNTVVFNodD2XK81mlQXRYh8dsL7kjBggnfF4C7Rz9v
wkUDIAyAxX8AtQ2zD6DBnjkmu8gYZZNSTIaUJex429B8x7vVSCZxCnI0Y4ubVC3WzOOn4VrWDkFs
3/6xr8ercdFL4btx0bDjVWC8aycCXnpetk1EmKr9qFmu1ZvR0ESJq1CIcE5jnTW5CaT//87FEENI
3MbmskOQW4iNIT+WugQBRX0uAprR+7Ocedv6v5YWcHD0tBPk/Q9gILl+qnQYfdEK3ABjEdIQPjd6
AGF/hcmXoyTk7lyK3QCNvDF3gkY35fKBeKKg3NrUKPESomKS+rMrCVbsnwmGSkF6hOCVcLdYysDP
BsRdDyhJPtq22F6M2FhQe4tfRALcM9xw42gp3fQrPP+isgM2SQDzpJwEpwlMl1lgVECz7N9zmExN
8JAHIEIGwFrUbl5rOdQBsXGiPaBz5WX6E9wMI7P03zRdAhrEPobQiAi6NBeVlSjJShBvCsBuXeli
fpeIDOCo0Erbv3TnYB7Mv8kbfl9AsDadsXXrz5cY208A0JcrPWeOayFZgTTL2mlgBZpSqbK57Xdz
+wGHiRuZMADGkabvLsx34UfOGXEQJQSIWk+vrOOBBGMcCQ7Ls0N7bEA0777QkHAdEvjYL8N0wh5t
/1PwqoBM4DvpaKvvC0c3X2OKp8vpoDigKhmWQXTWAaK4SaGKzyOG1W1atfWC1jgproP696E7cmK5
fxPu5WhK9AHX/oaKVpzhXo1OBMVHlRcg7Ep98JodDu/d4paRmTt/DIwUlGURMe6FWuk1/eorMmyn
nSKrF+A7DnIfQ7ZU4REDCxpl6PSTZ9j6Ii8i5/ZxTS5yjJ2zmDXWuQtbOp81/nucxHr5C2gyN8hC
Wdil2N55RY7ztj1sotK8KM7JNA4RwIFBZxCmVSsCHkudVXxlyx2t8582M/LywJEEeKK4gxaQHk8w
rxv2roreeINAg3FyjsY4HUHzkVCdNsAG1hkA+ECyIN1K5xS3eaYC5uS25nSiZOTLzHGzVOErH/d+
FUw0l/AfH35jwgkp26MYCzB7noOnxoTN051zA5HlQhQAQVfc1zRGkSP7bE31b/zey23zQdkVToIa
6Pe4k/pIGncudTDMEVG+zQiyT6z8QnXhqxy82Uz5/BtBDHM0sORhQvDP5DguV64rXI272heFfoIi
RzOgCWtVBibIwAkdgSeRxc1s6iDFLxK3GQVJDENRIDN5jB6AbZDNcWE2Juez2CHsWWg8zPwpW8i7
9plafxkXhOjtpf3RhXrRTE7bDhE8XcPn23uLyaLCQATLYZVgOtcYK0ZWCvVLjY0VBOJpLSjRlUoc
J7s5IVZGxBlZYya3aYOs+97b+Wle4JwTb/VjCqDt+a8sZs5/gIobsAyVbv7cQZYrVPCdfBSq/a3V
OXywMF+6c4uZMz9KUTyY9eY7fIdp9vlmPLVAlOliUfWdgi0oCJQDXuZ9/yXuXACs9T8/698cbdE0
HoJLPgUssLIsCqZB0jedVRIW28hhYsnzQUAOAS0a5K7Z9DxoggUkaOuMGnZL7wvHtXMAIa0IY7zp
ad/8olfC84V0wpGkmYUD+//jVLnAK4JmJRTC6OD7NQdMu3IFQc6/gWAfnXbtpcUqvTWsfx6sPctM
XkY0KqD07s9Lngiql8j0GCONrTai1WLHQwo26Xb2OtHmVDiMEtp4bpOjN3c/ZCZEvOFA/QMxqlID
vUV28inJUgjVJDTrMGHBNbTX7JdjYFCOoVas9Md5+RIek7CDA2s8Q05XcirKEx7DX5/f9wdGswQX
j3RQt6uE4IAjKn3piTZ4cBCLkm30QBU3G+iSF7+qMk7BUzdqeAgaNDrXmlBcd5igmG2XCiBjSepD
LV1FHb29GHFnylhts8KBQj8BefbHncH8XQngIgAoygx6c0URSNghV4wUK8lS0GUMSsxApyDRrecy
nN1BGCiiqpDiB/nBibmu7mMXLHBwFtsnPnViYwTwOGdnmfy/VHq74x4XFw1lbmRzdHJlYW0NZW5k
b2JqDTE5IDAgb2JqDTw8IC9OIDMgL0FsdGVybmF0ZSAvRGV2aWNlUkdCIC9MZW5ndGggMjU3NSAv
RmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQqUpewo8sB2G9vGK03N+0aaEtvYJ0J68/im
053VGFpF5ny4i3B7JZbhg9hjOPPI6lNP3flGNM2MkHet3Zr6M8S8coz6zzIpw3MT20PTbCc/0EkB
wnEVJEc4amHCkfxiZizFzwM6Hzg3DLZP3h0cdNPxM0PdCBKrkg7nbeRwM0lFmS+/lev3X5sxMGRz
F1ryBZlNqT+6jj59cjFk0c00MFgKTsmuIwcCrkXt4qIEbR9uZcqXXAHimzRtWt2KQ7OGc+uZmYbn
fWCVjEEvRMeGUacZWJT+vbhKKwbDIaI9Il3LrraTXMIhAOnF4vEu/B4Pv+oBjIJi9O45ANVMO3du
ansTihWnDFLHHrBvhHEAR7s3WN9eubdkZfb2ZQYVPRNQBzWmtAXDGKEA/thcB2keaE8QmGxilPWf
GPhDK4JjxNuZEPyzt5EoM4It/p92WGm3WuzATZvKWZaU31QwasyV3XUGadLUuJHyXWLxg+4Tj757
moMsvTqsSQavJzoeluJ8TTN7g1ksLPfheehQTn+y1luTNQpDHk9d6StKKR5GvQY+xOULp8sQ3J7F
BECQefG78GKjKyapj5ZuNGYKu8TCnL8kk+2L9tqVlOa5lgi/Sz8ceROZ+f/2ZkEnt8Bfs04eE+lO
v3zP7NudnkCDf+qxEkinO74k4L5q9fRBs4mn9AVM7cs+pAQF7zUndjVVowggagjzqpdpuoSnV56T
ppANJktbZNljmc1sFBfWVtC+7Tqbw4e34H+7hhtmYVysagoqkcjJd0aNwvL6992NHXiahemMGuiL
/9l64eWsdmk9bIQrJqd9IJgodaHl6bIPtwjDA6aEO7H8SKz8WIPFAZxUL3IQYPcZI5K5ElzbcKlX
z3PeZC+QYO+/YYSgLNrFzI+st4JHTCzmx0SaKBZOBIdfY2b7pFksAIigXm4tOH+2s/tp4x4vEjWI
RAwxtTZ+tKxTM1mXv3imNnDwJ9E2W5EPOSK0SH+p+Pc30Frvszx/KcXF28C5KSODbWXdiw8cqdzI
tVWJ0bA4Snqwf871drXGPDACuo796GimgTWPv6CfzQOGSH1hqNVepa9H/+jz3NaWCvRVIItyTHuN
i/k532Ta2zgCHZum9te02sFduf9fh1wAA7tV6cYky0yHHl79OX8Dpq5H4G1qkdYLbpiCjQ1PJEl3
KC2RznX1noTQJFdhImy5kEOVlKnRRqwklljjZkDncSIkhN2d4BuAbPyv8knxMiBJUub2tq0hJ/mJ
6KYlCtyy0iU8piAqCBIlpWVPcjnV8VUcDUfAAJ2RRiU4zFUN+PoxsizKkog6NMW7xrjU3HTV8qmz
lAeMOg4zfcFYsUs7NSRUnvMCjie6v5aX+YFKWD0XhUzIOQDchJzIZggY8cEmLL5FG1d/1RzjjuRS
rwo/y4kpLLMP064RE7Lv+uP5BrZoRabx+HdbZQM5KHNwuIxuRjX/sggn43EBE3XGJIbAmkuRFnEe
nDcDxHHM1aOducfJqIt/h+vXq2xN/bF99YJue/hnsMpoji25By8uOXaPj/qPwyIWnWuwiW/897mF
hhw6JbsZ5XZWCHUL9QpOl6dMIykIZ9zDO+eZ3h8ShDCTsZuSM9vt7XSFHiKYvaLMhCxMOXsxdXYU
c0kg8hdMIZQW1LGYx1ukKsdmHB+yNpVjGgmCeMPvDKAOl6u6M4pIHN2v2Ib5udEQQS0D0mihqfmQ
Ryno/ra9HjCdf802qhhznQbiJjUv1XR8fyUzmcaCFQ3ZCSZkaVbgLYudQoo9HLfcUAvvymiEsGJq
G2v1ICGKtxbNuJqnN0zwpTJJq4Kwg16yoIIm+5Nxb+v7DgHSpV0BRVa31ykPeI79UXz3kYOSQLhj
vZscOaWOt4y/qJ2jTMQPyMY3UuU+8jTq8ecXiuyXBJ7VyHYL5QI2FZ+l6t8kfDmBUbTbrHhZcsml
7M098bC41hnJykgpgdJ1xzgy+3XDfduf/qx3aYRkAMAWALs8OL8+619cmZ96PpMmYmcGKBTx+kIU
BdB3joss8Zc4nVdumgKeIdm5JI1/Xz8Ngpo3g80WuWu5fel/QlJz3aYDQSLvXTBwkAh10GaOEd1l
2uxy5q0WI+ufJNfU3dl0ksrOqHh6npzl536lHFF3nacDx5ZYjZXEzDEg7BByibZHsWG6dAANuj8D
S8CQhvlJp+su9LMmPAJDO3IzSPvMHMSCobVzz8WoByzPSvLgfruGh80UMnlqL8Bc9xah133wNMZl
PHZ5f7Cp/WvXgGVfrZa6eU3L7RUqKa1+DY58cmpZWL+k4DNhGmMIDClVKY6/VsVp5y3u+wwO/sii
zix5E3y7kY7hyhnQGJFzvYz9F9W2HotmAdTPVGbdHYNJFlzIfiKMa6IMP6UTSFtoqsrbdvcqVE6E
24YZEOP/Br7KH1M1Y0RBt1ZQ35iAiHnuOCjUwunVdDtQLO3IWoOZ4zjtPlReq9pXTfsTwDz8LWEY
2yTqRZFTuvr1zBFTdj4pquyt2rxV3BFCEnLwNbvFAgzM6TVjY0g/iQuNgTf+UyJVfuMGLXRUVeDg
sfn0rlC4OfZ1ltovYo7v+n/wE1D/FyNOSU40yikAyrUqUEo8PF5mqvkC8CfUM6COQIe5e4vJv+K5
ByGKRyOrVTEp/+kcmu8ItmGwLTqmZf6McfPOITOXZop1oQ2avyY77a6YSmlRXzi4mxo1WXCbTxOF
egsVDWv8OuaHv9UlpdnKP3uHcmMCpaYEx6ZgUt9TO4vCI1efLQmsEPueaXAXR3U8XxMdBWAZPdgg
F1UG35GTPtq6hEWGh3sprQlFc3KLYJaHfGmaTsR2WhDwZ+pW1pONGoYfrWG6Bbt9PiSjV/CUCVJB
qF+YNqKOS1xYpi0hVqLZb/mBZQ0U+iLO4I6TaKHuZROYTnRiXd5N/WhZkrfWSdeFQHYvUbYooIud
5IO9rl4PQ9zLInamU4ekqGWHtjUqyMvyBvy+YmnctrOjEqoDLIaOFVw6wqsi81UShMGWiV8Zs55F
vq82fTA4qlZ3S6vWBoeyHQjTJNy44/FqYQgq3NEQgkxQ7wr980JyKhR0r7MX0FJe7Y0ZTsF/nrgg
fsAoo0NfNLXgkOCFrP5zzSQ59uLdyrqfyYtFgysIZBIWqFoC+3/sojJ1yu35f+DUYoQpew8011ih
ZXWLU5LbGUWhtC17MQxfXcWxJKLKWDv2dy/RFV00rvtwwWkoswXV/45bgEmn6fzZVz/eZ6ep9dGO
MJRGjH3L7e8XA8RlXBCmdGPhm/f8YB34SaiBjyjyrDqiHaUGgZqF7697vhlOwHNLYbSos+89DItJ
6zGJcp44jaAWfi3oINr/O8/bLe0mccz8DsGRTXBUCneaQy0QOWbJjccgTwjaPixw7P7CRmEEGF5k
Hcs/8CkPTpf626Uc5OZxJPf705DgDNnMY+6OiLlEgWUkBgItdMXQn705DWVuZHN0cmVhbQ1lbmRv
YmoNMjAgMCBvYmoNPDwgDS9UeXBlIC9FeHRHU3RhdGUgDS9TQSBmYWxzZSANL1NNIDAuMDIgDS9U
UjIgL0RlZmF1bHQgDT4+IA1lbmRvYmoNMSAwIG9iag08PCANL1MgL0QgDT4+IA1lbmRvYmoNMiAw
IG9iag08PCANL051bXMgWyAwIDEgMCBSIF0gDT4+IA1lbmRvYmoNMyAwIG9iag08PCANL1R5cGUg
L1BhZ2VzIA0vS2lkcyBbIDkgMCBSIF0gDS9Db3VudCAxIA0+PiANZW5kb2JqDTQgMCBvYmoNPDwg
DS9Qcm9kdWNlciAogh2n/s4OiqvgMM1cKauqPpyi3xXZYcayiwAYpXWehsSzPikNL0F1dGhvciAo
gBaw/4BPqe7NM9czpSkNL1RpdGxlICiNEfXCwAaa7oRcctdcKa6jKQ0vTW9kRGF0ZSAoh0TnoZxd
zrqVb45k8/9myf3PFtBh2KApDS9DcmVhdGlvbkRhdGUgKIdE56GcXc66lW+OZPP/YMz9zxbQYdig
KQ0vQ3JlYXRvciAogh2n/s4Oiqv0HfgQo603i/DKDsdxjujZCB+jbJ+b469+6sgpDT4+IA1lbmRv
YmoNNSAwIG9iag08PCAvVHlwZSAvTWV0YWRhdGEgL1N1YnR5cGUgL1hNTCAvTGVuZ3RoIDEwNTcg
Pj4gDXN0cmVhbQ0KRz/cxUtmATDEnNjON67Ach5euV+DpotZwHi0pRsPq+thEr7GNJRKMc7cCENI
dWWXGhb4WZ8HUyU2rZl2TM5aTWrPRY7Fga6WXwTwuBz8X7Y0Fbs2ahV9SlPCHHHNATE/AWPwC40U
8TS+/o617jJYfoMgsape10YIr3AEJ0XV2ZsZqFIySa2Jex6T4c5HMi+z+b0Eonax2FjYyDKEU8Yc
e/BTcNKJ9tosaNZVZQ5diJnf1bjRj5Ljqz6bYJaz4EqRvk0g/K1WVyD6x+lKbCpBS6bP0qyVKBX0
Cj3n2Q/pTFTv4Pdn9k/JTjBsUZ40+AHVWQRD7AHusdTTgYpkeZXk2WocLtappTzmGAng2VYVOpbt
f48bo0/fp7MHvE8WElSS3levQfUX/JUmUyOKf8bFLHhIPIltRV8acFVbXJpXeX+Ofqb17YBCzqAh
8Ybje38wG4d8valSGAQb+Y4YDbpsCoT54huibJmUULAZEbCCl8ebcStLPprn+45C2iQgScH1ccTP
6w4Ok0ybWAWwBWZd8D5OppPCpaZZzcjHJSV+pc821LLhfnKhISxwUHHmoXcoUoZe6q+9iae7rEFU
xp6vLzsAhlJuM/NjCWXFToek2oQNQM1H+y7s6uM4AUf4wAAswZDc0iGBuRrmu1DUAm1znsUmqL2l
FegncWLylwYWmstZ1E0ZakML6q9ZBCUenIEe4/bl6mH74pzJ+w7sZIxXJ53Rjvujh20sOzKwtV+f
Du36xzBG5r/Zz9Y3zeZDMACYB4EVEfbab2IG+dmtl2WY2x0oiE1z5QFLoAKaBom/848p5U9AWc8+
E9sqxg6KgIGNsFgxfLNG/LxmN1TQYngmkrVP3trsQfGyAtoti+Zy4e5VAnh4YPFeQTOv2TY4lr5/
ItKNGnZ/K2RT11oFa5Tk6/oLpZyVojl4Y6xo9H1I1Hhm+6fPpmNbaSv1sVZgQMKcc3WXcbdosrH+
tck0dGdW33ErOaPCQzYcZcbWgpwrCkbN7DfDjcaaOth3lptoZXUSTu79nYzBl1YPaHab0bFyh09S
vMMv9GYtoAwoVeU+EwHSU8RTM435pQ7g9/IK3rcjWPk9BRM3x6lyW2knakFxdRWvut0RUzUURfMI
lnhNGSLGKmKX3jGPqFEqzOvdQ4SAdw0Wu9JuWts9lNG+ZMa/hdsYgZER4dOP6RNIxZvN2/JdIE2o
tuhZ/Sp3FmzSrPEwtzcQW7xjxydmvGWPtL45XmzIlQ6uyO2qtc14fVynRWHoso5vUuZEPzojJS/p
WiWMIWPMIbeFCMA0EPayQ3Auh09WIgniC3YXylHmXUVdgLVZUM1D/V2mJYMhi50g1iqQMRPnDk6W
u8u44+Yo6r5Phifk5dKYIAkTiENYNVBhBkzck7nXbNQx2x83wvu+USZofw1lbmRzdHJlYW0NZW5k
b2JqDXhyZWYNMCA2IA0wMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMzk5MjQgMDAwMDAgbg0KMDAw
MDAzOTk1NCAwMDAwMCBuDQowMDAwMDM5OTk2IDAwMDAwIG4NCjAwMDAwNDAwNjAgMDAwMDAgbg0K
MDAwMDA0MDMwMiAwMDAwMCBuDQp0cmFpbGVyDTw8DS9TaXplIDYNL0lEWzw0ZGZkNmI0MGUwMzE0
MjA4NzcwZDZlOTk4MTZhNGRjMT48NWUxNDMzMDY0NGJkNjRlYWE4ZmFlNmFlMGE0ZWZiMTQ+XQ0+
Pg1zdGFydHhyZWYNMTczDSUlRU9GDQ==

------_=_NextPart_000_01C19EA1.957FD2B0--


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



From daemon@optimus.ietf.org  Thu Jan 17 01:42: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 BAA00950
	for <nsis-archive@odin.ietf.org>; Thu, 17 Jan 2002 01:42:52 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id BAA17053
	for nsis-archive@odin.ietf.org; Thu, 17 Jan 2002 01:42: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 BAA16569;
	Thu, 17 Jan 2002 01:34: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 BAA16519
	for <nsis@optimus.ietf.org>; Thu, 17 Jan 2002 01:34:36 -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 BAA00817
	for <nsis@ietf.org>; Thu, 17 Jan 2002 01:34:34 -0500 (EST)
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 g0H6Ygk02118
	for <nsis@ietf.org>; Thu, 17 Jan 2002 08:34:42 +0200 (EET)
Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T587ffdfdc4ac158f2111e@esvir01nok.ntc.nokia.com>;
 Thu, 17 Jan 2002 08:34:34 +0200
Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779);
	 Thu, 17 Jan 2002 08:34:34 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [NSIS] Two kinds of requirements
Date: Thu, 17 Jan 2002 08:34:33 +0200
Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFA21FD3@esebe004.NOE.Nokia.com>
Thread-Topic: [NSIS] Two kinds of requirements
Thread-Index: AcGewYZzLAgWPwq0EdaSygAAwCUaDwACDTQAABVvDKA=
From: "Loughney John (NRC/Helsinki)" <john.loughney@nokia.com>
To: "ext Roy, Radhika R, ALASO" <rrroy@att.com>
Cc: <nsis@ietf.org>
X-OriginalArrivalTime: 17 Jan 2002 06:34:34.0168 (UTC) FILETIME=[06E7DB80:01C19F21]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id BAA16520
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 Radhika,

> I think this was adequately addressed in RFC 2998, ``A Framework for 
> Integrated Services Operation over Diffserv Networks'' by Bernet, et 
> al.
> 
> [RRR] It is a good point. If we look into RFC 2998, we will 
> see that it will provide a good insight to develop our 
> end-to-end application layer QOS (generic) signaling 
> protocol. What we need to do to make it evolve in such a way 
> that the end-to-end QOS signaling will be able satisfy any 
> combinations of network layer QOS that has been implemented 
> using RSVP, DiffServ, MPLS, and/or other means while testing 
> RFC 2998's end-to-end scheme as one of the implementation schemes.

What would be good to do is document if something like RFC 2998 
can be expanded / extended / (reduced?) so that it supports
different combos of network layer QoS.

best regards,
John

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



From daemon@optimus.ietf.org  Thu Jan 17 01:42: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 BAA00965
	for <nsis-archive@odin.ietf.org>; Thu, 17 Jan 2002 01:42:57 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id BAA17067
	for nsis-archive@odin.ietf.org; Thu, 17 Jan 2002 01:42: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 BAA16625;
	Thu, 17 Jan 2002 01:34:42 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA16544
	for <nsis@optimus.ietf.org>; Thu, 17 Jan 2002 01:34: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 BAA00828
	for <nsis@ietf.org>; Thu, 17 Jan 2002 01:34:35 -0500 (EST)
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 g0H6Yb905074
	for <nsis@ietf.org>; Thu, 17 Jan 2002 08:34:37 +0200 (EET)
Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T587ffdfe3cac158f240c7@esvir04nok.ntc.nokia.com>;
 Thu, 17 Jan 2002 08:34:34 +0200
Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779);
	 Thu, 17 Jan 2002 08:34:32 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [NSIS] Two kinds of requirements
Date: Thu, 17 Jan 2002 08:34:32 +0200
Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFA21FD2@esebe004.NOE.Nokia.com>
Thread-Topic: [NSIS] Two kinds of requirements
Thread-Index: AcGewZpSjsyMNX7iT5KmfNHLp4vJ4AAXZkFQ
From: "Loughney John (NRC/Helsinki)" <john.loughney@nokia.com>
To: "ext Steven Berson" <berson@isi.edu>
Cc: <nsis@ietf.org>
X-OriginalArrivalTime: 17 Jan 2002 06:34:33.0106 (UTC) FILETIME=[0645CF20:01C19F21]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id BAA16547
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 Steve,

> > What do we do when RSVP is not end-to-end? For example domain 1 =
> > RSVP, domain 2 = DiffServ, and domain 3= RSVP. I guess that here
> > it breaks down. One solution may be translation between RSVP and
> > DiffServ. Then we loose the end-to-end picture.
> 
> I think this was adequately addressed in RFC 2998, ``A Framework for 
> Integrated Services Operation over Diffserv Networks'' by Bernet, et 
> al.

Thanks for sending the reference - it saves me from having to.
My suggestion for all those disinclined to use RSVP, 2998 is
worth a read.

best regards,
John

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



From daemon@optimus.ietf.org  Thu Jan 17 01:43:06 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00981
	for <nsis-archive@odin.ietf.org>; Thu, 17 Jan 2002 01:43:06 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id BAA17083
	for nsis-archive@odin.ietf.org; Thu, 17 Jan 2002 01: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 BAA16503;
	Thu, 17 Jan 2002 01:34: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 BAA16434
	for <nsis@optimus.ietf.org>; Thu, 17 Jan 2002 01:34:28 -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 BAA00802
	for <nsis@ietf.org>; Thu, 17 Jan 2002 01:34:26 -0500 (EST)
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 g0H6YYk02045
	for <nsis@ietf.org>; Thu, 17 Jan 2002 08:34:34 +0200 (EET)
Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T587ffdde36ac158f2111e@esvir01nok.ntc.nokia.com>;
 Thu, 17 Jan 2002 08:34:25 +0200
Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779);
	 Thu, 17 Jan 2002 08:34:26 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [NSIS] Two kinds of requirements
Date: Thu, 17 Jan 2002 08:34:25 +0200
Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFA21FCC@esebe004.NOE.Nokia.com>
Thread-Topic: [NSIS] Two kinds of requirements
Thread-Index: AcGehgcOp/8IMGojRcankOHstjZE0wAlzZnQ
From: "Loughney John (NRC/Helsinki)" <john.loughney@nokia.com>
To: <dick.rr.knight@bt.com>, <brian.williams@ericsson.com.au>,
        <lieve.bos@alcatel.be>
Cc: <nsis@ietf.org>
X-OriginalArrivalTime: 17 Jan 2002 06:34:26.0078 (UTC) FILETIME=[02156BE0:01C19F21]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id BAA16437
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 Dick,

Thanks for your comments.

> I think that what is needed is a new protocol that can signal the
> requirements of any session and can be satisfied by any QoS mechanism,
> existing or new. To be more precise, I am suggesting a new protocol
that 
> is independent of the underlying transport technology and the QoS 
> implemented and is also independent of the session control protocol. 
> Such a new protocol would be generic, optionally implemented by 
> applications that would benefit from end-to-end QoS, and would be 
> complimentary to the QoS mechanisms deployed
> (and of course other mechanisms, such as the routing).

Yes, this is what the workgroup will be working on.  The 'new' protocol 
might be based upon an existing protocol (RSVP) but used in a new way.
Actually, we have been told that we need to look at using RSVP first
- however, we are given the freedom to propose changes to RSVP.

> I think that this implies a more abstract definition of the 
> QoS mechanism and may lend itself to the signalling of pre-defined 
> QoS classes rather than parameters.

Taking my chair hat off, I agree with the above statement as
well, with some reservations (no pun intended).  We need to
examine this within the working group.

cheers,
John

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



From daemon@optimus.ietf.org  Thu Jan 17 01:48: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 BAA01045
	for <nsis-archive@odin.ietf.org>; Thu, 17 Jan 2002 01:48:24 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id BAA17165
	for nsis-archive@odin.ietf.org; Thu, 17 Jan 2002 01:48: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 BAA16636;
	Thu, 17 Jan 2002 01:34: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 BAA16546
	for <nsis@optimus.ietf.org>; Thu, 17 Jan 2002 01:34: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 BAA00829
	for <nsis@ietf.org>; Thu, 17 Jan 2002 01:34:35 -0500 (EST)
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 g0H6Yc905092
	for <nsis@ietf.org>; Thu, 17 Jan 2002 08:34:38 +0200 (EET)
Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T587ffdfea9ac158f240c7@esvir04nok.ntc.nokia.com>;
 Thu, 17 Jan 2002 08:34:34 +0200
Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779);
	 Thu, 17 Jan 2002 08:34:30 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [NSIS] Two kinds of requirements
Date: Thu, 17 Jan 2002 08:34:29 +0200
Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFA21FD0@esebe004.NOE.Nokia.com>
Thread-Topic: [NSIS] Two kinds of requirements
Thread-Index: AcGeq3EzMyTCowRtRlKH6EM0v3XM5wAcx08A
From: "Loughney John (NRC/Helsinki)" <john.loughney@nokia.com>
To: "ext Michael Thomas" <mat@cisco.com>
Cc: <nsis@ietf.org>
X-OriginalArrivalTime: 17 Jan 2002 06:34:30.0015 (UTC) FILETIME=[046E28F0:01C19F21]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id BAA16553
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,

> So, I'm really dumb here. Can somebody enumerate
> the *specific* things that are broken with RSVP?
> Before we run off designing new protocols, it
> would be nice to know a) what things the current
> protocols have problems with and b) whether the
> current protocols are fatally flawed in the face
> of those problems.
> 
> I know some in (a). I don't think they meet (b).

Before we go down to far on this road, let me say
that we will need to fully examine RSVP + variants
before designing a new protocol.  The IESG has
given us some room to discuss and make modifications /
enhancements / simplifications to RSVP.  If we
go through this exercise and find RSVP to be sufficiently 
deficient, then we should document this & then we
should be able to work on an all new protcols.

best regards,
John

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



From daemon@optimus.ietf.org  Thu Jan 17 01:48:27 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01060
	for <nsis-archive@odin.ietf.org>; Thu, 17 Jan 2002 01:48:27 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id BAA17180
	for nsis-archive@odin.ietf.org; Thu, 17 Jan 2002 01:48: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 BAA16502;
	Thu, 17 Jan 2002 01:34: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 BAA16436
	for <nsis@optimus.ietf.org>; Thu, 17 Jan 2002 01:34:29 -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 BAA00804
	for <nsis@ietf.org>; Thu, 17 Jan 2002 01:34:27 -0500 (EST)
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 g0H6YCu22093
	for <nsis@ietf.org>; Thu, 17 Jan 2002 08:34:12 +0200 (EET)
Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T587ffde29bac158f25077@esvir05nok.ntc.nokia.com>;
 Thu, 17 Jan 2002 08:34:27 +0200
Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779);
	 Thu, 17 Jan 2002 08:34:26 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [NSIS] Two kinds of requirements
Date: Thu, 17 Jan 2002 08:34:26 +0200
Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFA21FCD@esebe004.NOE.Nokia.com>
Thread-Topic: [NSIS] Two kinds of requirements
Thread-Index: AcGenLBijAnNhaByQtuGXRmV2hOlogAgT4cA
From: "Loughney John (NRC/Helsinki)" <john.loughney@nokia.com>
To: "ext Geib, Ruediger" <Ruediger.Geib@t-systems.com>,
        <dick.rr.knight@bt.com>
Cc: <nsis@ietf.org>
X-OriginalArrivalTime: 17 Jan 2002 06:34:27.0169 (UTC) FILETIME=[02BBE510:01C19F21]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id BAA16440
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 Rüdiger,

> Complex services are hard to sell and hard to provide.

And are more prone to breaking.

best regards,
John

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



From daemon@optimus.ietf.org  Thu Jan 17 04:41: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 EAA10741
	for <nsis-archive@odin.ietf.org>; Thu, 17 Jan 2002 04:41:23 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id EAA23536
	for nsis-archive@odin.ietf.org; Thu, 17 Jan 2002 04:41: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 EAA23477;
	Thu, 17 Jan 2002 04:40: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 EAA23449
	for <nsis@optimus.ietf.org>; Thu, 17 Jan 2002 04:40: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 EAA10683
	for <nsis@ietf.org>; Thu, 17 Jan 2002 04:39:13 -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 g0H9dDK10621
	for <nsis@ietf.org>; Thu, 17 Jan 2002 10:39:13 +0100 (MET)
Received: FROM esealnt747.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Thu Jan 17 10:38:49 2002 +0100
Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <YHKTKLFL>; Thu, 17 Jan 2002 10:38:49 +0100
Message-ID: <E244E44D6AB85E40AEEF7EAABE3545FA823363@enleent104.nl.eu.ericsson.se>
From: "Georgios Karagiannis (ELN)" <Georgios.Karagiannis@eln.ericsson.se>
To: "'dick.rr.knight@bt.com'" <dick.rr.knight@bt.com>
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements
Date: Thu, 17 Jan 2002 10:39:03 +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 Dick 

In principle I agree with your comment (see below).

[DK] >> To be more precise, I am suggesting a new protocol that is 
[DK] >> independent of the underlying transport technology and the QoS 
[DK] >> implemented and is also independent of the session control protocol. 

However, a very important point here is that we need to 
specify a protocol that can be used independent of the underlying transport 
technology, but that can satisfy the QoS requirements imposed by these 
underlying transport technologies. Otherwise the protocol will not be suitable
and useful.

A way of achieving this is by first creating a modular QoS signaling toolkit 
that will contain mandatory and optional QoS requirements;
Second, specify how the protocol functionality should be separated in 
building blocks (protocol components) and define a minimum set 
of mandatory reservation options/features that should be 
processed by any network nodes, e.g., end-hosts,
proxies, edges and interior nodes.
An example of such a protocol decomposition is given below!
In this way each node will only process (check and use) the protocol 
components of interest.


|---------|                                                         |---------|
|everyhost|<------------------------------------------------------->|everyhost|
|---------|                                                         |---------|
|         |                                                         |         |
|---------|   |---------|                             |---------|   |---------|
|everyedge|<->|everyedge|<--------------------------->|everyedge|<->|everyedge|
|---------|   |---------|                             |---------|   |---------|
|         |   |         |                             |         |   |         |
|---------|   |---------|   |--------|   |--------|   |---------|   |---------|
|everyhop |<->|everyhop |<->|everyhop|<->|everyhop|<->|everyhop |<->|everyhop |
|---------|   |---------|   |--------|   |--------|   |---------|   |---------| 
    host          edge        interior    interior       edge          host


  NSIS protocol decomposition (building blocks): 
 *  "everyhost", "everyedge" and "everyhop" are protocol components;
 *  host: can be an end-host or a proxy and it can process and use the "everyhost", 
    "everyedge", and "everyhop" protocol components;

 *  edge: can be a Diffserv edge, MPLS edge, etc., and it can process and use 
    the "everyedge", and "everyhop" protocol components. The "everyhost" 
    protocol component is not processed (used or checked);

 *  interior: can be any router within a domain and it can process and use 
    only the "everyhop" protocol component.
    The "everyhost" and "everyedge" protocol components are not 
    processed (used or checked);


Best Regards,
Georgios

-----Original Message-----
From: dick.rr.knight@bt.com [mailto:dick.rr.knight@bt.com]
Sent: woensdag 16 januari 2002 13:00
To: brian.williams@ericsson.com.au; lieve.bos@alcatel.be
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


I was waiting for some reaction to Brian's comments, but as there aren't
any, here are my thoughts on the requirements:

I agree with the analysis that discussion has been based around
application-related signalling for QoS (at session level) and QoS signalling
protocols used to actually provision the QoS at the transport level.
Brian is right that there will never be an enhancement to a single session
protocol that will satisfy all applications.
However, for similar reasons, it is never going to be possible to prescribe
a single QoS mechanism to be used in all networks. Existing networks (or
domains) will not be changed overnight and new networks already face several
workable mechanisms to deploy QoS.

I think that what is needed is a new protocol that can signal the
requirements of any session and can be satisfied by any QoS mechanism,
existing or new.
To be more precise, I am suggesting a new protocol that is independent of
the underlying transport technology and the QoS implemented and is also
independent of the session control protocol. Such a new protocol would be
generic, optionally implemented by applications that would benefit from
end-to-end QoS, and would be complimentary to the QoS mechanisms deployed
(and of course other mechanisms, such as the routing).

I think that this implies a more abstract definition of the QoS mechanism
and may lend itself to the signalling of pre-defined QoS classes rather than
parameters.

Dick Knight

-----Original Message-----
From: Brian Williams [mailto:brian.williams@ericsson.com.au]
Sent: 22 December 2001 23:57
To: lieve.bos@alcatel.be
Cc: nsis@ietf.org
Subject: Re: [NSIS] Two kinds of requirements


Hi.
While the two types of signalling may be related, I think there is a
need to develop a QoS bearer mechanism which is independent of any
specific session signalling, and thus can be used for any application. I
believe many of the applications which have identified requirements to
the working group have their own specific session layer signalling (ie
it is not end-to-end SIP).  

Having the session and transport protocols developed separately of
course does not prohibit the two being used in conjunction for a
specific application.
/brian
 
On Fri, 2001-12-21 at 22:24, lieve.bos@alcatel.be wrote:
> Hello all,
> 
> >From the discussion in Salt Lake city and the drafts submitted, one can
> easily see that people are suggesting improvements to QoS signalling at
> two totally different levels (some at session level and some at
> transport level).
> 
> First of all, there are drafts suggesting some improvements in the
> session setup procedures (i.e. the ability to negotiate the preferred
> QoS level between end users during SDP negotiation in SIP, so before the
> actual resources are being setup). The QoS information negotiated at the
> session layer determines the QoS level both endusers have to use for 
> their local access connection. This first kind of 'session level QoS
> negotiation' happens end-to-end between the two end-users.
> 
> Secondly, there are drafts suggesting that we need
> improvements/alternatives for the QoS signalling protocols (e.g. RSVP)
> used to actually provision the QoS at the transport level between two
> endusers. This second kind of 'transport level QoS signalling' can
> consist of several phases: end-to-edge and edge-to-edge. 
> 
> It's important that everybody realises that, in order to give endusers
> true end-to-end Quality of Service, we need improvements for QoS both at
> session and transport level. Also its important to understand that they
> are not uncorrelated. Providers want to be able to control (e.g. via
> policy control mechanisms) that the QoS requested at the transport level
> is not exceeding the QoS negotiated/authorised previously at session
> level. So, what about developing in NSIS a modular framework
> incorporating both session and transport level QoS signalling with
> possible hooks between the two layers (e.g. for policy enforcement).
> 
> Lieve
> 
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis



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

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

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



From daemon@optimus.ietf.org  Thu Jan 17 05:07: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 FAA11054
	for <nsis-archive@odin.ietf.org>; Thu, 17 Jan 2002 05:07:28 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id FAA24343
	for nsis-archive@odin.ietf.org; Thu, 17 Jan 2002 05:07:30 -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 FAA24327;
	Thu, 17 Jan 2002 05:06: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 FAA24294
	for <nsis@optimus.ietf.org>; Thu, 17 Jan 2002 05:06:35 -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 FAA11048
	for <nsis@ietf.org>; Thu, 17 Jan 2002 05:06:32 -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 g0HA5rH56562;
	Thu, 17 Jan 2002 11:05:53 +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 3A0A0C052; Thu, 17 Jan 2002 11:05:24 +0100 (CET)
Date: Thu, 17 Jan 2002 11:16:58 +0100
From: Marcus Brunner <brunner@ccrle.nec.de>
Reply-To: brunner@ccrle.nec.de
To: Yaron Kahana <ykahana@comgates.co.il>,
        "Geib, Ruediger" <Ruediger.Geib@t-systems.com>, dick.rr.knight@bt.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements
Message-ID: <3422841.1011266218@[192.168.102.79]>
In-Reply-To: <6FEF757325DBD411B7DA000629A8A61E9AC63B@mail-server.comgates.co.il>
References:  <6FEF757325DBD411B7DA000629A8A61E9AC63B@mail-server.comgates.co.
 il>
X-Mailer: Mulberry/2.1.0 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1; format=flowed
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id FAA24295
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

Yaron,

Good point, my question is whether the operator more likely opt for a 
simple solution, with little flexibility, which implies no competition in 
the type of services offered, since these are standardized (I assume there 
is still a lot of differentiation possible with weaker service parameters)

Marcus

--On Wednesday, January 16, 2002 11:16 PM +0200 Yaron Kahana 
<ykahana@comgates.co.il> wrote:

>
> Hello Ruediger, Marcus,
>
> I agree with your comments. One of the crucial elements is the
> pre-definition of the provider's policy - admission control decision
> tree, QoS budgeting guides, CDR generation and considerations. Those
> could be done in a practical manner only if there will be a rather small
> number of Service classes (standardized services). I believe that this is
> by far the most practical approach in a multi-providers environment. This
> QoS protocol should be supported not only by the applications, the call
> control elements, and transport routers but by the middleboxes, as well
> as the SLA/QoS verification entities along the way and the billing
> elements.
>
> We should try to keep it simple, even on the expense of full flexibility.
>
> By the way - did anyone considered the problem of a non-cooperative IP
> domain "in the middle" ? for example, Suppose I'm making a call from Los
> Angeles to Munich through 3 domains - LA-NY, NY-London, London-Munich.
> What will happen if the best/cheapest carrier along the NY-London domain
> won't support this new protocol? Will he be condemned/ignored? When will
> he upgrade his infrastructure, before the chicken or after the egg?
>
> Yaron Kahana
> COGITO Project Manager,
> COMGATES
>
>  -----Original Message-----
> From:   Marcus Brunner [mailto:brunner@ccrle.nec.de]
> Sent:   Wednesday, January 16, 2002 5:35 PM
> To:     Geib, Ruediger; dick.rr.knight@bt.com
> Cc:     nsis@ietf.org
> Subject:        RE: [NSIS] Two kinds of requirements
>
> Ruediger,
>
> The service needs to be defined anyway. Then there are IMO two
> possibilities
> - the provider defines the services and offers them. In this case the
> provider needs to describe the offers in a machine readable form (most
> likely with parameter names and values)
> - the consumer requests a particular service (this means the consumer has
> to describe the service he wants in a machine readable form)
>
> So it seams one has to move around service specifications which are
> understandable by the other party anyway, what is now your point? Is it
> that you want to limit/fix as many parameters as possible? Or are you
> more  think about standardized services everybody understands?
>
> Marcus
>
> --On Wednesday, January 16, 2002 3:45 PM +0100 "Geib, Ruediger"
> <Ruediger.Geib@t-systems.com> wrote:
>
>> Hello Dick,
>>
>> your suggestion is quite reasonable. I also favour an architecture where
>> a QoS request by and large is predefined in terms of the resources
>> required from the available transport mechanism. Service specific
>> parameters to be signaled during reservation should be strictly limited.
>> The more mapping and evaluation of QoS parameters is required during
>> reservation, the more complex the service gets. Complex services are
>> hard  to sell and hard to provide.
>>
>> Regards,
>>
>> Rüdiger
>>
>> Rüdiger Geib
>> Senior Project Manager
>> T-Systems Nova GmbH
>>
>>> I think that what is needed is a new protocol that can signal the
>>> requirements of any session and can be satisfied by any QoS
>>> mechanism, existing or new.
>>> To be more precise, I am suggesting a new protocol that is
>>> independent of the underlying transport technology and the QoS
>>> implemented and is also independent of the session control
>>> protocol. Such a new protocol would be generic, optionally
>>> implemented by applications that would benefit from
>>> end-to-end QoS, and would be complimentary to the QoS
>>> mechanisms deployed (and of course other mechanisms,
>>> such as the routing).
>>>
>>> I think that this implies a more abstract definition of the
>>> QoS mechanism and may lend itself to the signalling of
>>> pre-defined QoS classes rather than parameters.
>>>
>>> Dick Knight
>>
>>
>> _______________________________________________
>> nsis mailing list
>> nsis@ietf.org
>> https://www1.ietf.org/mailman/listinfo/nsis
>>
>
>
> --------------------------------------
> Dr. Marcus Brunner
> Network Laboratories
> NEC Europe Ltd.
>
> E-Mail: brunner@ccrle.nec.de
> WWW:    http://www.ccrle.nec.de/
> personal home page: http://www.brubers.org/marcus
>
>
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis



--------------------------------------
Dr. Marcus Brunner
Network Laboratories
NEC Europe Ltd.

E-Mail: brunner@ccrle.nec.de
WWW:    http://www.ccrle.nec.de/
personal home page: http://www.brubers.org/marcus



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



From daemon@optimus.ietf.org  Thu Jan 17 05:13:27 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11101
	for <nsis-archive@odin.ietf.org>; Thu, 17 Jan 2002 05:13:27 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id FAA24434
	for nsis-archive@odin.ietf.org; Thu, 17 Jan 2002 05:13: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 FAA24247;
	Thu, 17 Jan 2002 05:03: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 FAA24214
	for <nsis@optimus.ietf.org>; Thu, 17 Jan 2002 05:03:36 -0500 (EST)
Received: from albatross-ext.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 FAA10978
	for <nsis@ietf.org>; Thu, 17 Jan 2002 05:03:32 -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.11.0/8.11.0/WIREfire-1.3) with SMTP id g0HA3XJ02470
	for <nsis@ietf.org>; Thu, 17 Jan 2002 11:03:33 +0100 (MET)
Received: FROM esealnt746.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Thu Jan 17 11:03:33 2002 +0100
Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <YHLJLFST>; Thu, 17 Jan 2002 11:03:33 +0100
Message-ID: <E244E44D6AB85E40AEEF7EAABE3545FA823364@enleent104.nl.eu.ericsson.se>
From: "Georgios Karagiannis (ELN)" <Georgios.Karagiannis@eln.ericsson.se>
To: "'Yaron Kahana'" <ykahana@comgates.co.il>,
        "Geib, Ruediger"
	 <Ruediger.Geib@t-systems.com>,
        "'Freytsis, Ilya'"
	 <ifreytsis@cetacean.com>
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements
Date: Thu, 17 Jan 2002 11:03:31 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="windows-1255"
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 Yaron, Ilya, Ruediger
 
Almost all issues that you addressed in your e-mails can be solved (see also my previous e-mail
addressed to Dick) by first creating a modular QoS signaling toolkit that will contain mandatory and 
optional QoS requirements.
Second, specifying how the protocol functionality should be separated in building blocks 
(NSIS protocol components) and define a minimum set of mandatory reservation options/features 
that should be processed by any network nodes, e.g., end-hosts, proxies, edges and interior nodes.
 
Best Regards,
Georgios

-----Original Message-----
From: Yaron Kahana [mailto:ykahana@comgates.co.il]
Sent: woensdag 16 januari 2002 22:16
To: brunner@ccrle.nec.de; Geib, Ruediger; dick.rr.knight@bt.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements



Hello Ruediger, Marcus, 

I agree with your comments. One of the crucial elements is the pre-definition of the provider's policy - admission control decision tree, QoS budgeting guides, CDR generation and considerations. Those could be done in a practical manner only if there will be a rather small number of Service classes (standardized services). I believe that this is by far the most practical approach in a multi-providers environment. This QoS protocol should be supported not only by the applications, the call control elements, and transport routers but by the middleboxes, as well as the SLA/QoS verification entities along the way and the billing elements.

We should try to keep it simple, even on the expense of full flexibility. 

By the way - did anyone considered the problem of a non-cooperative IP domain "in the middle" ? for example, Suppose I'm making a call from Los Angeles to Munich through 3 domains - LA-NY, NY-London, London-Munich. What will happen if the best/cheapest carrier along the NY-London domain won't support this new protocol? Will he be condemned/ignored? When will he upgrade his infrastructure, before the chicke

Yaron Kahana 
COGITO Project Manager, 
COMGATES 

 -----Original Message----- 
From:   Marcus Brunner [ mailto:brunner@ccrle.nec.de <mailto:brunner@ccrle.nec.de> ] 
Sent:   Wednesday, January 16, 2002 5:35 PM 
To:     Geib, Ruediger; dick.rr.knight@bt.com 
Cc:     nsis@ietf.org 
Subject:        RE: [NSIS] Two kinds of requirements 

Ruediger, 

The service needs to be defined anyway. Then there are IMO two 
possibilities 
- the provider defines the services and offers them. In this case the 
provider needs to describe the offers in a machine readable form (most 
likely with parameter names and values) 
- the consumer requests a particular service (this means the consumer has 
to describe the service he wants in a machine readable form) 

So it seams one has to move around service specifications which are 
understandable by the other party anyway, what is now your point? Is it 
that you want to limit/fix as many parameters as possible? Or are you more 
think about standardized services everybody understands? 

Marcus 

--On Wednesday, January 16, 2002 3:45 PM +0100 "Geib, Ruediger" 
<Ruediger.Geib@t-systems.com> wrote: 

> Hello Dick, 
> 
> your suggestion is quite reasonable. I also favour an architecture where 
> a QoS request by and large is predefined in terms of the resources 
> required from the available transport mechanism. Service specific 
> parameters to be signaled during reservation should be strictly limited. 
> The more mapping and evaluation of QoS parameters is required during 
> reservation, the more complex the service gets. Complex services are hard 
> to sell and hard to provide. 
> 
> Regards, 
> 
> R?diger 
> 
> R?diger Geib 
> Senior Project Manager 
> T-Systems Nova GmbH 
> 
>> I think that what is needed is a new protocol that can signal the 
>> requirements of any session and can be satisfied by any QoS 
>> mechanism, existing or new. 
>> To be more precise, I am suggesting a new protocol that is 
>> independent of the underlying transport technology and the QoS 
>> implemented and is also independent of the session control 
>> protocol. Such a new protocol would be generic, optionally 
>> implemented by applications that would benefit from 
>> end-to-end QoS, and would be complimentary to the QoS 
>> mechanisms deployed (and of course other mechanisms, 
>> such as the routing). 
>> 
>> I think that this implies a more abstract definition of the 
>> QoS mechanism and may lend itself to the signalling of 
>> pre-defined QoS classes rather than parameters. 
>> 
>> Dick Knight 
> 
> 
> _______________________________________________ 
> nsis mailing list 
> nsis@ietf.org 
> https://www1.ietf.org/mailman/listinfo/nsis <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/ <http://www.ccrle.nec.de/>  
personal home page: http://www.brubers.org/marcus <http://www.brubers.org/marcus>  



_______________________________________________ 
nsis mailing list 
nsis@ietf.org 
https://www1.ietf.org/mailman/listinfo/nsis <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 Jan 17 05:29: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 FAA11202
	for <nsis-archive@odin.ietf.org>; Thu, 17 Jan 2002 05:29:59 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id FAA24785
	for nsis-archive@odin.ietf.org; Thu, 17 Jan 2002 05:30: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 FAA24642;
	Thu, 17 Jan 2002 05:20: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 FAA24607
	for <nsis@optimus.ietf.org>; Thu, 17 Jan 2002 05:20:23 -0500 (EST)
Received: from albatross-ext.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 FAA11149
	for <nsis@ietf.org>; Thu, 17 Jan 2002 05:20:20 -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.11.0/8.11.0/WIREfire-1.3) with SMTP id g0HAKLJ18430
	for <nsis@ietf.org>; Thu, 17 Jan 2002 11:20:21 +0100 (MET)
Received: FROM esealnt747.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Thu Jan 17 11:20:20 2002 +0100
Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <YHKTKLW6>; Thu, 17 Jan 2002 11:20:04 +0100
Message-ID: <E244E44D6AB85E40AEEF7EAABE3545FA823365@enleent104.nl.eu.ericsson.se>
From: "Georgios Karagiannis (ELN)" <Georgios.Karagiannis@eln.ericsson.se>
To: "'Loughney John (NRC/Helsinki)'" <john.loughney@nokia.com>
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements
Date: Thu, 17 Jan 2002 11:20:18 +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

In the "analysis draft" located at the following URL, 
a "brief" analysis, in the context of NSIS, of RFC2998
is made.
The URL is :
 http://www.ietf.org/internet-drafts/draft-demeer-nsis-analysis-00.txt


Best Regards,
Georgios

-----Original Message-----
From: Loughney John (NRC/Helsinki) [mailto:john.loughney@nokia.com]
Sent: donderdag 17 januari 2002 7:35
To: ext Steven Berson
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


Hi Steve,

> > What do we do when RSVP is not end-to-end? For example domain 1 =
> > RSVP, domain 2 = DiffServ, and domain 3= RSVP. I guess that here
> > it breaks down. One solution may be translation between RSVP and
> > DiffServ. Then we loose the end-to-end picture.
> 
> I think this was adequately addressed in RFC 2998, ``A Framework for 
> Integrated Services Operation over Diffserv Networks'' by Bernet, et 
> al.

Thanks for sending the reference - it saves me from having to.
My suggestion for all those disinclined to use RSVP, 2998 is
worth a read.

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  Thu Jan 17 05:55: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 FAA11558
	for <nsis-archive@odin.ietf.org>; Thu, 17 Jan 2002 05:55:20 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id FAA25575
	for nsis-archive@odin.ietf.org; Thu, 17 Jan 2002 05:55: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 FAA25551;
	Thu, 17 Jan 2002 05:54: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 FAA25478
	for <nsis@optimus.ietf.org>; Thu, 17 Jan 2002 05:54:07 -0500 (EST)
Received: from G8SBV.dmz.telekom.de ([62.225.183.235])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11550
	for <nsis@ietf.org>; Thu, 17 Jan 2002 05:54:03 -0500 (EST)
Received: from g8pbq.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Thu, 17 Jan 2002 11:51:39 +0100
Received: by G8PBQ.blf01.telekom.de with Internet Mail Service (5.5.2653.19)
	id <CRHD0M0Z>; Thu, 17 Jan 2002 11:53:18 +0100
Message-Id: <DFD875E85664D3118FA6080006277DE70362C825@U8PN2>
From: "Geib, Ruediger" <Ruediger.Geib@t-systems.com>
To: brunner@ccrle.nec.de
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements
Date: Thu, 17 Jan 2002 11:32:49 +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 FAA25479
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,

if the QoS signalling supports a service description as follows:

- Service ID (say 32 bits)
- Service descriptor (0 to whatever length)

you could operate globally defined services as well as private services. The globally defined ones should be pre-determined in terms of performance parameters to the largest possible extent. This would allow providers/suppliers to map the global service to a network/system and to develop some admission control prior to operation/sale.

The service descriptor and its length are not mandatory per se. Both are service specific parameters (i.e. to a specifc service belongs a specific service descriptor). Obviously, a globally defined service requires both, ID and descriptor, to be formally standardized. Private services don't and may be "flexible" (which, to my experience, means complex if referring to QoS).

I didn't check exactly whether and how RSVP supports this mechanism.

Regards, Rüdiger


> -----Original Message-----
> From: Marcus Brunner [mailto:brunner@ccrle.nec.de]
> Sent: Thursday, January 17, 2002 11:17 AM
> To: Yaron Kahana; Geib, Ruediger; dick.rr.knight@bt.com
> Cc: nsis@ietf.org
> Subject: RE: [NSIS] Two kinds of requirements
> 
> 
> Yaron,
> 
> Good point, my question is whether the operator more likely opt for a 
> simple solution, with little flexibility, which implies no 
> competition in the type of services offered, since these are
> standardized (I assume there is still a lot of differentiation
> possible with weaker service parameters)
> 
> Marcus
> 
> --On Wednesday, January 16, 2002 11:16 PM +0200 Yaron Kahana 
> <ykahana@comgates.co.il> wrote:
> 
> >
> > Hello Ruediger, Marcus,
> >
> > I agree with your comments. One of the crucial elements is the
> > pre-definition of the provider's policy - admission control decision
> > tree, QoS budgeting guides, CDR generation and considerations. Those
> > could be done in a practical manner only if there will be a 
> rather small
> > number of Service classes (standardized services). I 
> believe that this is
> > by far the most practical approach in a multi-providers 
> environment. This
> > QoS protocol should be supported not only by the 
> applications, the call
> > control elements, and transport routers but by the 
> middleboxes, as well
> > as the SLA/QoS verification entities along the way and the billing
> > elements.
> >
> > We should try to keep it simple, even on the expense of 
> full flexibility.
> >
> > By the way - did anyone considered the problem of a 
> non-cooperative IP
> > domain "in the middle" ? for example, Suppose I'm making a 
> call from Los
> > Angeles to Munich through 3 domains - LA-NY, NY-London, 
> London-Munich.
> > What will happen if the best/cheapest carrier along the 
> NY-London domain
> > won't support this new protocol? Will he be 
> condemned/ignored? When will
> > he upgrade his infrastructure, before the chicken or after the egg?
> >
> > Yaron Kahana
> > COGITO Project Manager,
> > COMGATES
> >
> >  -----Original Message-----
> > From:   Marcus Brunner [mailto:brunner@ccrle.nec.de]
> > Sent:   Wednesday, January 16, 2002 5:35 PM
> > To:     Geib, Ruediger; dick.rr.knight@bt.com
> > Cc:     nsis@ietf.org
> > Subject:        RE: [NSIS] Two kinds of requirements
> >
> > Ruediger,
> >
> > The service needs to be defined anyway. Then there are IMO two
> > possibilities
> > - the provider defines the services and offers them. In 
> this case the
> > provider needs to describe the offers in a machine readable 
> form (most
> > likely with parameter names and values)
> > - the consumer requests a particular service (this means 
> the consumer has
> > to describe the service he wants in a machine readable form)
> >
> > So it seams one has to move around service specifications which are
> > understandable by the other party anyway, what is now your 
> point? Is it
> > that you want to limit/fix as many parameters as possible? 
> Or are you
> > more  think about standardized services everybody understands?
> >
> > Marcus
> >
> > --On Wednesday, January 16, 2002 3:45 PM +0100 "Geib, Ruediger"
> > <Ruediger.Geib@t-systems.com> wrote:
> >
> >> Hello Dick,
> >>
> >> your suggestion is quite reasonable. I also favour an 
> architecture where
> >> a QoS request by and large is predefined in terms of the resources
> >> required from the available transport mechanism. Service specific
> >> parameters to be signaled during reservation should be 
> strictly limited.
> >> The more mapping and evaluation of QoS parameters is 
> required during
> >> reservation, the more complex the service gets. Complex 
> services are
> >> hard  to sell and hard to provide.
> >>
> >> Regards,
> >>
> >> Rüdiger
> >>
> >> Rüdiger Geib
> >> Senior Project Manager
> >> T-Systems Nova GmbH
> >>
> >>> I think that what is needed is a new protocol that can signal the
> >>> requirements of any session and can be satisfied by any QoS
> >>> mechanism, existing or new.
> >>> To be more precise, I am suggesting a new protocol that is
> >>> independent of the underlying transport technology and the QoS
> >>> implemented and is also independent of the session control
> >>> protocol. Such a new protocol would be generic, optionally
> >>> implemented by applications that would benefit from
> >>> end-to-end QoS, and would be complimentary to the QoS
> >>> mechanisms deployed (and of course other mechanisms,
> >>> such as the routing).
> >>>
> >>> I think that this implies a more abstract definition of the
> >>> QoS mechanism and may lend itself to the signalling of
> >>> pre-defined QoS classes rather than parameters.
> >>>
> >>> Dick Knight
> >>
> >>
> >> _______________________________________________
> >> nsis mailing list
> >> nsis@ietf.org
> >> https://www1.ietf.org/mailman/listinfo/nsis
> >>
> >
> >
> > --------------------------------------
> > Dr. Marcus Brunner
> > Network Laboratories
> > NEC Europe Ltd.
> >
> > E-Mail: brunner@ccrle.nec.de
> > WWW:    http://www.ccrle.nec.de/
> > personal home page: http://www.brubers.org/marcus
> >
> >
> > _______________________________________________
> > nsis mailing list
> > nsis@ietf.org
> > https://www1.ietf.org/mailman/listinfo/nsis
> 
> 
> 
> --------------------------------------
> Dr. Marcus Brunner
> Network Laboratories
> NEC Europe Ltd.
> 
> E-Mail: brunner@ccrle.nec.de
> WWW:    http://www.ccrle.nec.de/
> personal home page: http://www.brubers.org/marcus
> 
> 
> 
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis
> 

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



From daemon@optimus.ietf.org  Thu Jan 17 06:09:37 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11658
	for <nsis-archive@odin.ietf.org>; Thu, 17 Jan 2002 06:09:37 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id GAA26289
	for nsis-archive@odin.ietf.org; Thu, 17 Jan 2002 06:09: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 GAA26136;
	Thu, 17 Jan 2002 06:06: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 GAA26105
	for <nsis@optimus.ietf.org>; Thu, 17 Jan 2002 06:06:13 -0500 (EST)
Received: from mail-server.comgates.co.il ([212.150.198.2])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11645
	for <nsis@ietf.org>; Thu, 17 Jan 2002 06:06:08 -0500 (EST)
Received: by mail-server.comgates.co.il with Internet Mail Service (5.5.2653.19)
	id <DC2CZYAY>; Thu, 17 Jan 2002 13:06:35 +0200
Message-ID: <6FEF757325DBD411B7DA000629A8A61E7BAD3D@mail-server.comgates.co.il>
From: Yaron Kahana <ykahana@comgates.co.il>
To: "'brunner@ccrle.nec.de'" <brunner@ccrle.nec.de>,
        Yaron Kahana
	 <ykahana@comgates.co.il>,
        "Geib, Ruediger" <Ruediger.Geib@t-systems.com>, dick.rr.knight@bt.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements
Date: Thu, 17 Jan 2002 13:06:35 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C19F47.06F8FD40"
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_01C19F47.06F8FD40
Content-Type: text/plain;
	charset="windows-1255"

Hi Marcus,

I don't really think that a service provider can generate significant
differentiation in the "tight high quality" area.
I think that most applications/services won't notice a 10ms difference in
delay, and 0.001% in packet loss. 
A crucial element in building of service levels is the differentiation value
- will a customer pay the extra money for the extra quality. In lots of
cases the differentiation is quite artificial, and the users won't feel (and
hence won't pay, and hence the differentiation won't be needed).

Yaron
-----Original Message-----
From: 	Marcus Brunner [mailto:brunner@ccrle.nec.de] 
Sent:	Thursday, January 17, 2002 12:17 PM
To:	Yaron Kahana; Geib, Ruediger; dick.rr.knight@bt.com
Cc:	nsis@ietf.org
Subject:	RE: [NSIS] Two kinds of requirements

Yaron,

Good point, my question is whether the operator more likely opt for a 
simple solution, with little flexibility, which implies no competition in 
the type of services offered, since these are standardized (I assume there 
is still a lot of differentiation possible with weaker service parameters)

Marcus

--On Wednesday, January 16, 2002 11:16 PM +0200 Yaron Kahana 
<ykahana@comgates.co.il> wrote:

>
> Hello Ruediger, Marcus,
>
> I agree with your comments. One of the crucial elements is the
> pre-definition of the provider's policy - admission control decision
> tree, QoS budgeting guides, CDR generation and considerations. Those
> could be done in a practical manner only if there will be a rather small
> number of Service classes (standardized services). I believe that this is
> by far the most practical approach in a multi-providers environment. This
> QoS protocol should be supported not only by the applications, the call
> control elements, and transport routers but by the middleboxes, as well
> as the SLA/QoS verification entities along the way and the billing
> elements.
>
> We should try to keep it simple, even on the expense of full flexibility.
>
> By the way - did anyone considered the problem of a non-cooperative IP
> domain "in the middle" ? for example, Suppose I'm making a call from Los
> Angeles to Munich through 3 domains - LA-NY, NY-London, London-Munich.
> What will happen if the best/cheapest carrier along the NY-London domain
> won't support this new protocol? Will he be condemned/ignored? When will
> he upgrade his infrastructure, before the chicken or after the egg?
>
> Yaron Kahana
> COGITO Project Manager,
> COMGATES
>
>  -----Original Message-----
> From:   Marcus Brunner [mailto:brunner@ccrle.nec.de]
> Sent:   Wednesday, January 16, 2002 5:35 PM
> To:     Geib, Ruediger; dick.rr.knight@bt.com
> Cc:     nsis@ietf.org
> Subject:        RE: [NSIS] Two kinds of requirements
>
> Ruediger,
>
> The service needs to be defined anyway. Then there are IMO two
> possibilities
> - the provider defines the services and offers them. In this case the
> provider needs to describe the offers in a machine readable form (most
> likely with parameter names and values)
> - the consumer requests a particular service (this means the consumer has
> to describe the service he wants in a machine readable form)
>
> So it seams one has to move around service specifications which are
> understandable by the other party anyway, what is now your point? Is it
> that you want to limit/fix as many parameters as possible? Or are you
> more  think about standardized services everybody understands?
>
> Marcus
>
> --On Wednesday, January 16, 2002 3:45 PM +0100 "Geib, Ruediger"
> <Ruediger.Geib@t-systems.com> wrote:
>
>> Hello Dick,
>>
>> your suggestion is quite reasonable. I also favour an architecture where
>> a QoS request by and large is predefined in terms of the resources
>> required from the available transport mechanism. Service specific
>> parameters to be signaled during reservation should be strictly limited.
>> The more mapping and evaluation of QoS parameters is required during
>> reservation, the more complex the service gets. Complex services are
>> hard  to sell and hard to provide.
>>
>> Regards,
>>
>> R?diger
>>
>> R?diger Geib
>> Senior Project Manager
>> T-Systems Nova GmbH
>>
>>> I think that what is needed is a new protocol that can signal the
>>> requirements of any session and can be satisfied by any QoS
>>> mechanism, existing or new.
>>> To be more precise, I am suggesting a new protocol that is
>>> independent of the underlying transport technology and the QoS
>>> implemented and is also independent of the session control
>>> protocol. Such a new protocol would be generic, optionally
>>> implemented by applications that would benefit from
>>> end-to-end QoS, and would be complimentary to the QoS
>>> mechanisms deployed (and of course other mechanisms,
>>> such as the routing).
>>>
>>> I think that this implies a more abstract definition of the
>>> QoS mechanism and may lend itself to the signalling of
>>> pre-defined QoS classes rather than parameters.
>>>
>>> Dick Knight
>>
>>
>> _______________________________________________
>> nsis mailing list
>> nsis@ietf.org
>> https://www1.ietf.org/mailman/listinfo/nsis
>>
>
>
> --------------------------------------
> Dr. Marcus Brunner
> Network Laboratories
> NEC Europe Ltd.
>
> E-Mail: brunner@ccrle.nec.de
> WWW:    http://www.ccrle.nec.de/
> personal home page: http://www.brubers.org/marcus
>
>
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis



--------------------------------------
Dr. Marcus Brunner
Network Laboratories
NEC Europe Ltd.

E-Mail: brunner@ccrle.nec.de
WWW:    http://www.ccrle.nec.de/
personal home page: http://www.brubers.org/marcus


------_=_NextPart_001_01C19F47.06F8FD40
Content-Type: text/html;
	charset="windows-1255"
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=3Dwindows-1255">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>RE: [NSIS] Two kinds of requirements</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Hi Marcus,</FONT>
</P>

<P><FONT SIZE=3D2>I don't really think that a service provider can =
generate significant differentiation in the &quot;tight high =
quality&quot; area.</FONT>
<BR><FONT SIZE=3D2>I think that most applications/services won't notice =
a 10ms difference in delay, and 0.001% in packet loss. </FONT>
<BR><FONT SIZE=3D2>A crucial element in building of service levels is =
the differentiation value - will a customer pay the extra money for the =
extra quality. In lots of cases the differentiation is quite =
artificial, and the users won't feel (and hence won't pay, and hence =
the differentiation won't be needed).</FONT></P>

<P><FONT SIZE=3D2>Yaron</FONT>
<BR><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: &nbsp; Marcus Brunner [<A =
HREF=3D"mailto:brunner@ccrle.nec.de">mailto:brunner@ccrle.nec.de</A>] =
</FONT>
<BR><FONT SIZE=3D2>Sent:&nbsp;&nbsp; Thursday, January 17, 2002 12:17 =
PM</FONT>
<BR><FONT SIZE=3D2>To:&nbsp;&nbsp;&nbsp;&nbsp; Yaron Kahana; Geib, =
Ruediger; dick.rr.knight@bt.com</FONT>
<BR><FONT SIZE=3D2>Cc:&nbsp;&nbsp;&nbsp;&nbsp; nsis@ietf.org</FONT>
<BR><FONT SIZE=3D2>Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
RE: [NSIS] Two kinds of requirements</FONT>
</P>

<P><FONT SIZE=3D2>Yaron,</FONT>
</P>

<P><FONT SIZE=3D2>Good point, my question is whether the operator more =
likely opt for a </FONT>
<BR><FONT SIZE=3D2>simple solution, with little flexibility, which =
implies no competition in </FONT>
<BR><FONT SIZE=3D2>the type of services offered, since these are =
standardized (I assume there </FONT>
<BR><FONT SIZE=3D2>is still a lot of differentiation possible with =
weaker service parameters)</FONT>
</P>

<P><FONT SIZE=3D2>Marcus</FONT>
</P>

<P><FONT SIZE=3D2>--On Wednesday, January 16, 2002 11:16 PM +0200 Yaron =
Kahana </FONT>
<BR><FONT SIZE=3D2>&lt;ykahana@comgates.co.il&gt; wrote:</FONT>
</P>

<P><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; Hello Ruediger, Marcus,</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; I agree with your comments. One of the crucial =
elements is the</FONT>
<BR><FONT SIZE=3D2>&gt; pre-definition of the provider's policy - =
admission control decision</FONT>
<BR><FONT SIZE=3D2>&gt; tree, QoS budgeting guides, CDR generation and =
considerations. Those</FONT>
<BR><FONT SIZE=3D2>&gt; could be done in a practical manner only if =
there will be a rather small</FONT>
<BR><FONT SIZE=3D2>&gt; number of Service classes (standardized =
services). I believe that this is</FONT>
<BR><FONT SIZE=3D2>&gt; by far the most practical approach in a =
multi-providers environment. This</FONT>
<BR><FONT SIZE=3D2>&gt; QoS protocol should be supported not only by =
the applications, the call</FONT>
<BR><FONT SIZE=3D2>&gt; control elements, and transport routers but by =
the middleboxes, as well</FONT>
<BR><FONT SIZE=3D2>&gt; as the SLA/QoS verification entities along the =
way and the billing</FONT>
<BR><FONT SIZE=3D2>&gt; elements.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; We should try to keep it simple, even on the =
expense of full flexibility.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; By the way - did anyone considered the problem =
of a non-cooperative IP</FONT>
<BR><FONT SIZE=3D2>&gt; domain &quot;in the middle&quot; ? for example, =
Suppose I'm making a call from Los</FONT>
<BR><FONT SIZE=3D2>&gt; Angeles to Munich through 3 domains - LA-NY, =
NY-London, London-Munich.</FONT>
<BR><FONT SIZE=3D2>&gt; What will happen if the best/cheapest carrier =
along the NY-London domain</FONT>
<BR><FONT SIZE=3D2>&gt; won't support this new protocol? Will he be =
condemned/ignored? When will</FONT>
<BR><FONT SIZE=3D2>&gt; he upgrade his infrastructure, before the =
chicken or after the egg?</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; Yaron Kahana</FONT>
<BR><FONT SIZE=3D2>&gt; COGITO Project Manager,</FONT>
<BR><FONT SIZE=3D2>&gt; COMGATES</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From:&nbsp;&nbsp; Marcus Brunner [<A =
HREF=3D"mailto:brunner@ccrle.nec.de">mailto:brunner@ccrle.nec.de</A>]</F=
ONT>
<BR><FONT SIZE=3D2>&gt; Sent:&nbsp;&nbsp; Wednesday, January 16, 2002 =
5:35 PM</FONT>
<BR><FONT SIZE=3D2>&gt; To:&nbsp;&nbsp;&nbsp;&nbsp; Geib, Ruediger; =
dick.rr.knight@bt.com</FONT>
<BR><FONT SIZE=3D2>&gt; Cc:&nbsp;&nbsp;&nbsp;&nbsp; =
nsis@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; =
Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; RE: [NSIS] Two kinds =
of requirements</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; Ruediger,</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; The service needs to be defined anyway. Then =
there are IMO two</FONT>
<BR><FONT SIZE=3D2>&gt; possibilities</FONT>
<BR><FONT SIZE=3D2>&gt; - the provider defines the services and offers =
them. In this case the</FONT>
<BR><FONT SIZE=3D2>&gt; provider needs to describe the offers in a =
machine readable form (most</FONT>
<BR><FONT SIZE=3D2>&gt; likely with parameter names and values)</FONT>
<BR><FONT SIZE=3D2>&gt; - the consumer requests a particular service =
(this means the consumer has</FONT>
<BR><FONT SIZE=3D2>&gt; to describe the service he wants in a machine =
readable form)</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; So it seams one has to move around service =
specifications which are</FONT>
<BR><FONT SIZE=3D2>&gt; understandable by the other party anyway, what =
is now your point? Is it</FONT>
<BR><FONT SIZE=3D2>&gt; that you want to limit/fix as many parameters =
as possible? Or are you</FONT>
<BR><FONT SIZE=3D2>&gt; more&nbsp; think about standardized services =
everybody understands?</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; Marcus</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; --On Wednesday, January 16, 2002 3:45 PM +0100 =
&quot;Geib, Ruediger&quot;</FONT>
<BR><FONT SIZE=3D2>&gt; &lt;Ruediger.Geib@t-systems.com&gt; =
wrote:</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; Hello Dick,</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; your suggestion is quite reasonable. I also =
favour an architecture where</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; a QoS request by and large is predefined in =
terms of the resources</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; required from the available transport =
mechanism. Service specific</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; parameters to be signaled during =
reservation should be strictly limited.</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; The more mapping and evaluation of QoS =
parameters is required during</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; reservation, the more complex the service =
gets. Complex services are</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; hard&nbsp; to sell and hard to =
provide.</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; Regards,</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; R&uuml;diger</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; R&uuml;diger Geib</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; Senior Project Manager</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; T-Systems Nova GmbH</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt; I think that what is needed is a new =
protocol that can signal the</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt; requirements of any session and can be =
satisfied by any QoS</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt; mechanism, existing or new.</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt; To be more precise, I am suggesting a =
new protocol that is</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt; independent of the underlying transport =
technology and the QoS</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt; implemented and is also independent of =
the session control</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt; protocol. Such a new protocol would be =
generic, optionally</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt; implemented by applications that would =
benefit from</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt; end-to-end QoS, and would be =
complimentary to the QoS</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt; mechanisms deployed (and of course =
other mechanisms,</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt; such as the routing).</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt; I think that this implies a more =
abstract definition of the</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt; QoS mechanism and may lend itself to =
the signalling of</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt; pre-defined QoS classes rather than =
parameters.</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt; Dick Knight</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; =
_______________________________________________</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; nsis mailing list</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; nsis@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt;&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;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; --------------------------------------</FONT>
<BR><FONT SIZE=3D2>&gt; Dr. Marcus Brunner</FONT>
<BR><FONT SIZE=3D2>&gt; Network Laboratories</FONT>
<BR><FONT SIZE=3D2>&gt; NEC Europe Ltd.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; E-Mail: brunner@ccrle.nec.de</FONT>
<BR><FONT SIZE=3D2>&gt; WWW:&nbsp;&nbsp;&nbsp; <A =
HREF=3D"http://www.ccrle.nec.de/" =
TARGET=3D"_blank">http://www.ccrle.nec.de/</A></FONT>
<BR><FONT SIZE=3D2>&gt; personal home page: <A =
HREF=3D"http://www.brubers.org/marcus" =
TARGET=3D"_blank">http://www.brubers.org/marcus</A></FONT>
<BR><FONT SIZE=3D2>&gt;</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>=

</P>
<BR>
<BR>

<P><FONT SIZE=3D2>--------------------------------------</FONT>
<BR><FONT SIZE=3D2>Dr. Marcus Brunner</FONT>
<BR><FONT SIZE=3D2>Network Laboratories</FONT>
<BR><FONT SIZE=3D2>NEC Europe Ltd.</FONT>
</P>

<P><FONT SIZE=3D2>E-Mail: brunner@ccrle.nec.de</FONT>
<BR><FONT SIZE=3D2>WWW:&nbsp;&nbsp;&nbsp; <A =
HREF=3D"http://www.ccrle.nec.de/" =
TARGET=3D"_blank">http://www.ccrle.nec.de/</A></FONT>
<BR><FONT SIZE=3D2>personal home page: <A =
HREF=3D"http://www.brubers.org/marcus" =
TARGET=3D"_blank">http://www.brubers.org/marcus</A></FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C19F47.06F8FD40--

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



From daemon@optimus.ietf.org  Thu Jan 17 06:10:26 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11680
	for <nsis-archive@odin.ietf.org>; Thu, 17 Jan 2002 06:10:26 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id GAA26313
	for nsis-archive@odin.ietf.org; Thu, 17 Jan 2002 06:10: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 GAA26266;
	Thu, 17 Jan 2002 06:08: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 GAA26195
	for <nsis@optimus.ietf.org>; Thu, 17 Jan 2002 06:08:49 -0500 (EST)
Received: from mail-server.comgates.co.il ([212.150.198.2])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11653
	for <nsis@ietf.org>; Thu, 17 Jan 2002 06:08:44 -0500 (EST)
Received: by mail-server.comgates.co.il with Internet Mail Service (5.5.2653.19)
	id <DC2CZYA5>; Thu, 17 Jan 2002 13:09:11 +0200
Message-ID: <6FEF757325DBD411B7DA000629A8A61E7BAD3E@mail-server.comgates.co.il>
From: Yaron Kahana <ykahana@comgates.co.il>
To: "'Georgios Karagiannis (ELN)'" <Georgios.Karagiannis@eln.ericsson.se>,
        "Geib, Ruediger" <Ruediger.Geib@t-systems.com>,
        "'Freytsis, Ilya'"
	 <ifreytsis@cetacean.com>
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements
Date: Thu, 17 Jan 2002 13:09:11 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C19F47.643517A0"
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_01C19F47.643517A0
Content-Type: text/plain;
	charset="windows-1255"

Hi,

I still don't see how such a toolkit can be useful if a certain domain in
the middle did not deployed a support in it and the Chicken and Egg
syndrome.

Yaron

-----Original Message-----
From: Georgios Karagiannis (ELN)
[mailto:Georgios.Karagiannis@eln.ericsson.se]
Sent: Thursday, January 17, 2002 12:04 PM
To: 'Yaron Kahana'; Geib, Ruediger; 'Freytsis, Ilya'
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements

Hi Yaron, Ilya, Ruediger

Almost all issues that you addressed in your e-mails can be solved (see also
my previous e-mail
addressed to Dick) by first creating a modular QoS signaling toolkit that
will contain mandatory and
optional QoS requirements.
Second, specifying how the protocol functionality should be separated in
building blocks
(NSIS protocol components) and define a minimum set of mandatory reservation
options/features
that should be processed by any network nodes, e.g., end-hosts, proxies,
edges and interior nodes.

Best Regards,
Georgios

-----Original Message-----
From: Yaron Kahana [mailto:ykahana@comgates.co.il]
Sent: woensdag 16 januari 2002 22:16
To: brunner@ccrle.nec.de; Geib, Ruediger; dick.rr.knight@bt.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements



Hello Ruediger, Marcus,

I agree with your comments. One of the crucial elements is the
pre-definition of the provider's policy - admission control decision tree,
QoS budgeting guides, CDR generation and considerations. Those could be done
in a practical manner only if there will be a rather small number of Service
classes (standardized services). I believe that this is by far the most
practical approach in a multi-providers environment. This QoS protocol
should be supported not only by the applications, the call control elements,
and transport routers but by the middleboxes, as well as the SLA/QoS
verification entities along the way and the billing elements.

We should try to keep it simple, even on the expense of full flexibility.

By the way - did anyone considered the problem of a non-cooperative IP
domain "in the middle" ? for example, Suppose I'm making a call from Los
Angeles to Munich through 3 domains - LA-NY, NY-London, London-Munich. What
will happen if the best/cheapest carrier along the NY-London domain won't
support this new protocol? Will he be condemned/ignored? When will he
upgrade his infrastructure, before the chicke

Yaron Kahana
COGITO Project Manager,
COMGATES

 -----Original Message-----
From:   Marcus Brunner [ mailto:brunner@ccrle.nec.de
<mailto:brunner@ccrle.nec.de> ]
Sent:   Wednesday, January 16, 2002 5:35 PM
To:     Geib, Ruediger; dick.rr.knight@bt.com
Cc:     nsis@ietf.org
Subject:        RE: [NSIS] Two kinds of requirements

Ruediger,

The service needs to be defined anyway. Then there are IMO two
possibilities
- the provider defines the services and offers them. In this case the
provider needs to describe the offers in a machine readable form (most
likely with parameter names and values)
- the consumer requests a particular service (this means the consumer has
to describe the service he wants in a machine readable form)

So it seams one has to move around service specifications which are
understandable by the other party anyway, what is now your point? Is it
that you want to limit/fix as many parameters as possible? Or are you more
think about standardized services everybody understands?

Marcus

--On Wednesday, January 16, 2002 3:45 PM +0100 "Geib, Ruediger"
<Ruediger.Geib@t-systems.com> wrote:

> Hello Dick,
>
> your suggestion is quite reasonable. I also favour an architecture where
> a QoS request by and large is predefined in terms of the resources
> required from the available transport mechanism. Service specific
> parameters to be signaled during reservation should be strictly limited.
> The more mapping and evaluation of QoS parameters is required during
> reservation, the more complex the service gets. Complex services are hard
> to sell and hard to provide.
>
> Regards,
>
> R?diger
>
> R?diger Geib
> Senior Project Manager
> T-Systems Nova GmbH
>
>> I think that what is needed is a new protocol that can signal the
>> requirements of any session and can be satisfied by any QoS
>> mechanism, existing or new.
>> To be more precise, I am suggesting a new protocol that is
>> independent of the underlying transport technology and the QoS
>> implemented and is also independent of the session control
>> protocol. Such a new protocol would be generic, optionally
>> implemented by applications that would benefit from
>> end-to-end QoS, and would be complimentary to the QoS
>> mechanisms deployed (and of course other mechanisms,
>> such as the routing).
>>
>> I think that this implies a more abstract definition of the
>> QoS mechanism and may lend itself to the signalling of
>> pre-defined QoS classes rather than parameters.
>>
>> Dick Knight
>
>
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis
<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/ <http://www.ccrle.nec.de/> 
personal home page: http://www.brubers.org/marcus
<http://www.brubers.org/marcus> 



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

------_=_NextPart_001_01C19F47.643517A0
Content-Type: text/html;
	charset="windows-1255"
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=3Dwindows-1255">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>RE: [NSIS] Two kinds of requirements</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Hi,</FONT>
</P>

<P><FONT SIZE=3D2>I still don't see how such a toolkit can be useful if =
a certain domain in the middle did not deployed a support in it and the =
Chicken and Egg syndrome.</FONT></P>

<P><FONT SIZE=3D2>Yaron</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Georgios Karagiannis (ELN) [<A =
HREF=3D"mailto:Georgios.Karagiannis@eln.ericsson.se">mailto:Georgios.Kar=
agiannis@eln.ericsson.se</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Thursday, January 17, 2002 12:04 PM</FONT>
<BR><FONT SIZE=3D2>To: 'Yaron Kahana'; Geib, Ruediger; 'Freytsis, =
Ilya'</FONT>
<BR><FONT SIZE=3D2>Cc: nsis@ietf.org</FONT>
<BR><FONT SIZE=3D2>Subject: RE: [NSIS] Two kinds of requirements</FONT>
</P>

<P><FONT SIZE=3D2>Hi Yaron, Ilya, Ruediger</FONT>
</P>

<P><FONT SIZE=3D2>Almost all issues that you addressed in your e-mails =
can be solved (see also my previous e-mail</FONT>
<BR><FONT SIZE=3D2>addressed to Dick) by first creating a modular QoS =
signaling toolkit that will contain mandatory and</FONT>
<BR><FONT SIZE=3D2>optional QoS requirements.</FONT>
<BR><FONT SIZE=3D2>Second, specifying how the protocol functionality =
should be separated in building blocks</FONT>
<BR><FONT SIZE=3D2>(NSIS protocol components) and define a minimum set =
of mandatory reservation options/features</FONT>
<BR><FONT SIZE=3D2>that should be processed by any network nodes, e.g., =
end-hosts, proxies, edges and interior nodes.</FONT>
</P>

<P><FONT SIZE=3D2>Best Regards,</FONT>
<BR><FONT SIZE=3D2>Georgios</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Yaron Kahana [<A =
HREF=3D"mailto:ykahana@comgates.co.il">mailto:ykahana@comgates.co.il</A>=
]</FONT>
<BR><FONT SIZE=3D2>Sent: woensdag 16 januari 2002 22:16</FONT>
<BR><FONT SIZE=3D2>To: brunner@ccrle.nec.de; Geib, Ruediger; =
dick.rr.knight@bt.com</FONT>
<BR><FONT SIZE=3D2>Cc: nsis@ietf.org</FONT>
<BR><FONT SIZE=3D2>Subject: RE: [NSIS] Two kinds of requirements</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>Hello Ruediger, Marcus,</FONT>
</P>

<P><FONT SIZE=3D2>I agree with your comments. One of the crucial =
elements is the pre-definition of the provider's policy - admission =
control decision tree, QoS budgeting guides, CDR generation and =
considerations. Those could be done in a practical manner only if there =
will be a rather small number of Service classes (standardized =
services). I believe that this is by far the most practical approach in =
a multi-providers environment. This QoS protocol should be supported =
not only by the applications, the call control elements, and transport =
routers but by the middleboxes, as well as the SLA/QoS verification =
entities along the way and the billing elements.</FONT></P>

<P><FONT SIZE=3D2>We should try to keep it simple, even on the expense =
of full flexibility.</FONT>
</P>

<P><FONT SIZE=3D2>By the way - did anyone considered the problem of a =
non-cooperative IP domain &quot;in the middle&quot; ? for example, =
Suppose I'm making a call from Los Angeles to Munich through 3 domains =
- LA-NY, NY-London, London-Munich. What will happen if the =
best/cheapest carrier along the NY-London domain won't support this new =
protocol? Will he be condemned/ignored? When will he upgrade his =
infrastructure, before the chicke</FONT></P>

<P><FONT SIZE=3D2>Yaron Kahana</FONT>
<BR><FONT SIZE=3D2>COGITO Project Manager,</FONT>
<BR><FONT SIZE=3D2>COMGATES</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From:&nbsp;&nbsp; Marcus Brunner [ <A =
HREF=3D"mailto:brunner@ccrle.nec.de">mailto:brunner@ccrle.nec.de</A> =
&lt;<A =
HREF=3D"mailto:brunner@ccrle.nec.de">mailto:brunner@ccrle.nec.de</A>&gt;=
 ]</FONT>
<BR><FONT SIZE=3D2>Sent:&nbsp;&nbsp; Wednesday, January 16, 2002 5:35 =
PM</FONT>
<BR><FONT SIZE=3D2>To:&nbsp;&nbsp;&nbsp;&nbsp; Geib, Ruediger; =
dick.rr.knight@bt.com</FONT>
<BR><FONT SIZE=3D2>Cc:&nbsp;&nbsp;&nbsp;&nbsp; nsis@ietf.org</FONT>
<BR><FONT SIZE=3D2>Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
RE: [NSIS] Two kinds of requirements</FONT>
</P>

<P><FONT SIZE=3D2>Ruediger,</FONT>
</P>

<P><FONT SIZE=3D2>The service needs to be defined anyway. Then there =
are IMO two</FONT>
<BR><FONT SIZE=3D2>possibilities</FONT>
<BR><FONT SIZE=3D2>- the provider defines the services and offers them. =
In this case the</FONT>
<BR><FONT SIZE=3D2>provider needs to describe the offers in a machine =
readable form (most</FONT>
<BR><FONT SIZE=3D2>likely with parameter names and values)</FONT>
<BR><FONT SIZE=3D2>- the consumer requests a particular service (this =
means the consumer has</FONT>
<BR><FONT SIZE=3D2>to describe the service he wants in a machine =
readable form)</FONT>
</P>

<P><FONT SIZE=3D2>So it seams one has to move around service =
specifications which are</FONT>
<BR><FONT SIZE=3D2>understandable by the other party anyway, what is =
now your point? Is it</FONT>
<BR><FONT SIZE=3D2>that you want to limit/fix as many parameters as =
possible? Or are you more</FONT>
<BR><FONT SIZE=3D2>think about standardized services everybody =
understands?</FONT>
</P>

<P><FONT SIZE=3D2>Marcus</FONT>
</P>

<P><FONT SIZE=3D2>--On Wednesday, January 16, 2002 3:45 PM +0100 =
&quot;Geib, Ruediger&quot;</FONT>
<BR><FONT SIZE=3D2>&lt;Ruediger.Geib@t-systems.com&gt; wrote:</FONT>
</P>

<P><FONT SIZE=3D2>&gt; Hello Dick,</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; your suggestion is quite reasonable. I also =
favour an architecture where</FONT>
<BR><FONT SIZE=3D2>&gt; a QoS request by and large is predefined in =
terms of the resources</FONT>
<BR><FONT SIZE=3D2>&gt; required from the available transport =
mechanism. Service specific</FONT>
<BR><FONT SIZE=3D2>&gt; parameters to be signaled during reservation =
should be strictly limited.</FONT>
<BR><FONT SIZE=3D2>&gt; The more mapping and evaluation of QoS =
parameters is required during</FONT>
<BR><FONT SIZE=3D2>&gt; reservation, the more complex the service gets. =
Complex services are hard</FONT>
<BR><FONT SIZE=3D2>&gt; to sell and hard to provide.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; Regards,</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; R?diger</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; R?diger Geib</FONT>
<BR><FONT SIZE=3D2>&gt; Senior Project Manager</FONT>
<BR><FONT SIZE=3D2>&gt; T-Systems Nova GmbH</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; I think that what is needed is a new =
protocol that can signal the</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; requirements of any session and can be =
satisfied by any QoS</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; mechanism, existing or new.</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; To be more precise, I am suggesting a new =
protocol that is</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; independent of the underlying transport =
technology and the QoS</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; implemented and is also independent of the =
session control</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; protocol. Such a new protocol would be =
generic, optionally</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; implemented by applications that would =
benefit from</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; end-to-end QoS, and would be complimentary =
to the QoS</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; mechanisms deployed (and of course other =
mechanisms,</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; such as the routing).</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; I think that this implies a more abstract =
definition of the</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; QoS mechanism and may lend itself to the =
signalling of</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; pre-defined QoS classes rather than =
parameters.</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; Dick Knight</FONT>
<BR><FONT SIZE=3D2>&gt;</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> =
&lt;<A HREF=3D"https://www1.ietf.org/mailman/listinfo/nsis" =
TARGET=3D"_blank">https://www1.ietf.org/mailman/listinfo/nsis</A>&gt; =
</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>--------------------------------------</FONT>
<BR><FONT SIZE=3D2>Dr. Marcus Brunner</FONT>
<BR><FONT SIZE=3D2>Network Laboratories</FONT>
<BR><FONT SIZE=3D2>NEC Europe Ltd.</FONT>
</P>

<P><FONT SIZE=3D2>E-Mail: brunner@ccrle.nec.de</FONT>
<BR><FONT SIZE=3D2>WWW:&nbsp;&nbsp;&nbsp; <A =
HREF=3D"http://www.ccrle.nec.de/" =
TARGET=3D"_blank">http://www.ccrle.nec.de/</A> &lt;<A =
HREF=3D"http://www.ccrle.nec.de/" =
TARGET=3D"_blank">http://www.ccrle.nec.de/</A>&gt; </FONT>
<BR><FONT SIZE=3D2>personal home page: <A =
HREF=3D"http://www.brubers.org/marcus" =
TARGET=3D"_blank">http://www.brubers.org/marcus</A> &lt;<A =
HREF=3D"http://www.brubers.org/marcus" =
TARGET=3D"_blank">http://www.brubers.org/marcus</A>&gt; </FONT>
</P>
<BR>
<BR>

<P><FONT =
SIZE=3D2>_______________________________________________</FONT>
<BR><FONT SIZE=3D2>nsis mailing list</FONT>
<BR><FONT SIZE=3D2>nsis@ietf.org</FONT>
<BR><FONT SIZE=3D2><A =
HREF=3D"https://www1.ietf.org/mailman/listinfo/nsis" =
TARGET=3D"_blank">https://www1.ietf.org/mailman/listinfo/nsis</A> =
&lt;<A HREF=3D"https://www1.ietf.org/mailman/listinfo/nsis" =
TARGET=3D"_blank">https://www1.ietf.org/mailman/listinfo/nsis</A>&gt; =
</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C19F47.643517A0--

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



From daemon@optimus.ietf.org  Thu Jan 17 06:16: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 GAA11742
	for <nsis-archive@odin.ietf.org>; Thu, 17 Jan 2002 06:16:44 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id GAA26493
	for nsis-archive@odin.ietf.org; Thu, 17 Jan 2002 06:16: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 GAA26469;
	Thu, 17 Jan 2002 06:15: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 GAA26440
	for <nsis@optimus.ietf.org>; Thu, 17 Jan 2002 06:15:44 -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 GAA11733
	for <nsis@ietf.org>; Thu, 17 Jan 2002 06:15:40 -0500 (EST)
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 g0HBFQu00849
	for <nsis@ietf.org>; Thu, 17 Jan 2002 13:15:26 +0200 (EET)
Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T5880ff5ec3ac158f2515f@esvir05nok.ntc.nokia.com>;
 Thu, 17 Jan 2002 13:15:41 +0200
Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779);
	 Thu, 17 Jan 2002 13:15:40 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [NSIS] Two kinds of requirements
Date: Thu, 17 Jan 2002 13:15:40 +0200
Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF09BC56@esebe004.NOE.Nokia.com>
Thread-Topic: [NSIS] Two kinds of requirements
Thread-Index: AcGfPrTaKBE6biYZRaiyVSStfQUV9AACMRTw
From: "Loughney John (NRC/Helsinki)" <john.loughney@nokia.com>
To: <brunner@ccrle.nec.de>, "Yaron Kahana" <ykahana@comgates.co.il>,
        "Geib, Ruediger" <Ruediger.Geib@t-systems.com>,
        <dick.rr.knight@bt.com>
Cc: <nsis@ietf.org>
X-OriginalArrivalTime: 17 Jan 2002 11:15:40.0616 (UTC) FILETIME=[4C179480:01C19F48]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id GAA26441
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,

> Good point, my question is whether the operator more likely opt for a 
> simple solution, with little flexibility, which implies no 
> competition in the type of services offered, since these are
standardized 
> (I assume there is still a lot of differentiation possible with weaker

> service parameters)

I've been wondering if this is a spurious argument.  I cannot think of 
how service providers could use QoS as a service.  What I have been 
hearing from service providers is that they would like to be able
to provide certain QoS levels for customers, but they would like
to be free to deploy / allocate resources as they see fit.  

With the PSTN, there SHOULD be only one quality, but in practice,
when calling overseas, I tend to get quite variable quality - of course
I still pay the same price ...

Additionally, I think we need to start somewhere, and I think that we 
need to be able to set some base line for signaling QoS. This does not
mean that we cannot allow more to be done / offered, but we want
to start with a minimum.  One option could be that we allow a simple
solution that supports optional extras.  These extras could be used
by service providers for enhanced services, but we don't specify 
them.

best regards,
John

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



From daemon@optimus.ietf.org  Thu Jan 17 06:20: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 GAA11798
	for <nsis-archive@odin.ietf.org>; Thu, 17 Jan 2002 06:20:47 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id GAA26690
	for nsis-archive@odin.ietf.org; Thu, 17 Jan 2002 06:20: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 GAA26644;
	Thu, 17 Jan 2002 06:19: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 GAA26606
	for <nsis@optimus.ietf.org>; Thu, 17 Jan 2002 06:19:26 -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 GAA11769
	for <nsis@ietf.org>; Thu, 17 Jan 2002 06:19:21 -0500 (EST)
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 g0HBJVk04887
	for <nsis@ietf.org>; Thu, 17 Jan 2002 13:19:31 +0200 (EET)
Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T588102beeeac158f2111e@esvir01nok.ntc.nokia.com>;
 Thu, 17 Jan 2002 13:19:22 +0200
Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779);
	 Thu, 17 Jan 2002 13:19:22 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="windows-1255"
Subject: RE: [NSIS] Two kinds of requirements
Date: Thu, 17 Jan 2002 13:19:22 +0200
Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF5D9377@esebe004.NOE.Nokia.com>
Thread-Topic: [NSIS] Two kinds of requirements
Thread-Index: AcGfPkrZMa805BHwT3ee/JiVJXOS2QACh9JA
From: "Loughney John (NRC/Helsinki)" <john.loughney@nokia.com>
To: "'ext Georgios Karagiannis (ELN)'" <Georgios.Karagiannis@eln.ericsson.se>,
        "'Yaron Kahana'" <ykahana@comgates.co.il>,
        "Geib, Ruediger" <Ruediger.Geib@t-systems.com>,
        "'Freytsis, Ilya'" <ifreytsis@cetacean.com>
Cc: <nsis@ietf.org>
X-OriginalArrivalTime: 17 Jan 2002 11:19:22.0872 (UTC) FILETIME=[D0912780:01C19F48]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id GAA26608
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,
 
> Almost all issues that you addressed in your e-mails can be 
> solved (see also my previous e-mail addressed to Dick) by first 
> creating a modular QoS signaling toolkit that will contain mandatory 
> and optional QoS requirements.

I think the current discussion is not contradicting your suggestion,
but you are already working on a framework, while most of the discussion
has been trying to get a handle on the scope.  In otherwords, once
we feel we have a good handle on the scope, we can arrange the
scope into boxes (i.e. - your modular toolkit).

> Second, specifying how the protocol functionality should be 
> separated in building blocks (NSIS protocol components) and define a 
> minimum set of mandatory reservation options/features that should be 
> processed by any network nodes, e.g., end-hosts, proxies, edges and 
> interior nodes.

Yes, this will be addressed in the framework deliverable.

John

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



From daemon@optimus.ietf.org  Thu Jan 17 06:25: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 GAA11830
	for <nsis-archive@odin.ietf.org>; Thu, 17 Jan 2002 06:25:10 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id GAA26853
	for nsis-archive@odin.ietf.org; Thu, 17 Jan 2002 06:25: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 GAA26407;
	Thu, 17 Jan 2002 06:14: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 GAA26382
	for <nsis@optimus.ietf.org>; Thu, 17 Jan 2002 06:14: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 GAA11727
	for <nsis@ietf.org>; Thu, 17 Jan 2002 06:14: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 g0HBDdH57029;
	Thu, 17 Jan 2002 12:13:39 +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 08C71C052; Thu, 17 Jan 2002 12:13:10 +0100 (CET)
Date: Thu, 17 Jan 2002 12:24:44 +0100
From: Marcus Brunner <brunner@ccrle.nec.de>
Reply-To: brunner@ccrle.nec.de
To: "Geib, Ruediger" <Ruediger.Geib@t-systems.com>,
        Yaron Kahana <ykahana@comgates.co.il>
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements
Message-ID: <7488517.1011270284@[192.168.102.79]>
In-Reply-To: <DFD875E85664D3118FA6080006277DE70362C825@U8PN2>
References:  <DFD875E85664D3118FA6080006277DE70362C825@U8PN2>
X-Mailer: Mulberry/2.1.0 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1; format=flowed
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id GAA26383
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, Yaron,

So you say from the service providers point of view a set of pre-defined 
services with a known performance is what is your choice?

Marcus

--On Thursday, January 17, 2002 11:32 AM +0100 "Geib, Ruediger" 
<Ruediger.Geib@t-systems.com> wrote:

> Hello Marcus,
>
> if the QoS signalling supports a service description as follows:
>
> - Service ID (say 32 bits)
> - Service descriptor (0 to whatever length)
>
> you could operate globally defined services as well as private services.
> The globally defined ones should be pre-determined in terms of
> performance parameters to the largest possible extent. This would allow
> providers/suppliers to map the global service to a network/system and to
> develop some admission control prior to operation/sale.
>
> The service descriptor and its length are not mandatory per se. Both are
> service specific parameters (i.e. to a specifc service belongs a specific
> service descriptor). Obviously, a globally defined service requires both,
> ID and descriptor, to be formally standardized. Private services don't
> and may be "flexible" (which, to my experience, means complex if
> referring to QoS).
>
> I didn't check exactly whether and how RSVP supports this mechanism.
>
> Regards, Rüdiger
>
>
>> -----Original Message-----
>> From: Marcus Brunner [mailto:brunner@ccrle.nec.de]
>> Sent: Thursday, January 17, 2002 11:17 AM
>> To: Yaron Kahana; Geib, Ruediger; dick.rr.knight@bt.com
>> Cc: nsis@ietf.org
>> Subject: RE: [NSIS] Two kinds of requirements
>>
>>
>> Yaron,
>>
>> Good point, my question is whether the operator more likely opt for a
>> simple solution, with little flexibility, which implies no
>> competition in the type of services offered, since these are
>> standardized (I assume there is still a lot of differentiation
>> possible with weaker service parameters)
>>
>> Marcus
>>
>> --On Wednesday, January 16, 2002 11:16 PM +0200 Yaron Kahana
>> <ykahana@comgates.co.il> wrote:
>>
>> >
>> > Hello Ruediger, Marcus,
>> >
>> > I agree with your comments. One of the crucial elements is the
>> > pre-definition of the provider's policy - admission control decision
>> > tree, QoS budgeting guides, CDR generation and considerations. Those
>> > could be done in a practical manner only if there will be a
>> rather small
>> > number of Service classes (standardized services). I
>> believe that this is
>> > by far the most practical approach in a multi-providers
>> environment. This
>> > QoS protocol should be supported not only by the
>> applications, the call
>> > control elements, and transport routers but by the
>> middleboxes, as well
>> > as the SLA/QoS verification entities along the way and the billing
>> > elements.
>> >
>> > We should try to keep it simple, even on the expense of
>> full flexibility.
>> >
>> > By the way - did anyone considered the problem of a
>> non-cooperative IP
>> > domain "in the middle" ? for example, Suppose I'm making a
>> call from Los
>> > Angeles to Munich through 3 domains - LA-NY, NY-London,
>> London-Munich.
>> > What will happen if the best/cheapest carrier along the
>> NY-London domain
>> > won't support this new protocol? Will he be
>> condemned/ignored? When will
>> > he upgrade his infrastructure, before the chicken or after the egg?
>> >
>> > Yaron Kahana
>> > COGITO Project Manager,
>> > COMGATES
>> >
>> >  -----Original Message-----
>> > From:   Marcus Brunner [mailto:brunner@ccrle.nec.de]
>> > Sent:   Wednesday, January 16, 2002 5:35 PM
>> > To:     Geib, Ruediger; dick.rr.knight@bt.com
>> > Cc:     nsis@ietf.org
>> > Subject:        RE: [NSIS] Two kinds of requirements
>> >
>> > Ruediger,
>> >
>> > The service needs to be defined anyway. Then there are IMO two
>> > possibilities
>> > - the provider defines the services and offers them. In
>> this case the
>> > provider needs to describe the offers in a machine readable
>> form (most
>> > likely with parameter names and values)
>> > - the consumer requests a particular service (this means
>> the consumer has
>> > to describe the service he wants in a machine readable form)
>> >
>> > So it seams one has to move around service specifications which are
>> > understandable by the other party anyway, what is now your
>> point? Is it
>> > that you want to limit/fix as many parameters as possible?
>> Or are you
>> > more  think about standardized services everybody understands?
>> >
>> > Marcus
>> >
>> > --On Wednesday, January 16, 2002 3:45 PM +0100 "Geib, Ruediger"
>> > <Ruediger.Geib@t-systems.com> wrote:
>> >
>> >> Hello Dick,
>> >>
>> >> your suggestion is quite reasonable. I also favour an
>> architecture where
>> >> a QoS request by and large is predefined in terms of the resources
>> >> required from the available transport mechanism. Service specific
>> >> parameters to be signaled during reservation should be
>> strictly limited.
>> >> The more mapping and evaluation of QoS parameters is
>> required during
>> >> reservation, the more complex the service gets. Complex
>> services are
>> >> hard  to sell and hard to provide.
>> >>
>> >> Regards,
>> >>
>> >> Rüdiger
>> >>
>> >> Rüdiger Geib
>> >> Senior Project Manager
>> >> T-Systems Nova GmbH
>> >>
>> >>> I think that what is needed is a new protocol that can signal the
>> >>> requirements of any session and can be satisfied by any QoS
>> >>> mechanism, existing or new.
>> >>> To be more precise, I am suggesting a new protocol that is
>> >>> independent of the underlying transport technology and the QoS
>> >>> implemented and is also independent of the session control
>> >>> protocol. Such a new protocol would be generic, optionally
>> >>> implemented by applications that would benefit from
>> >>> end-to-end QoS, and would be complimentary to the QoS
>> >>> mechanisms deployed (and of course other mechanisms,
>> >>> such as the routing).
>> >>>
>> >>> I think that this implies a more abstract definition of the
>> >>> QoS mechanism and may lend itself to the signalling of
>> >>> pre-defined QoS classes rather than parameters.
>> >>>
>> >>> Dick Knight
>> >>
>> >>
>> >> _______________________________________________
>> >> nsis mailing list
>> >> nsis@ietf.org
>> >> https://www1.ietf.org/mailman/listinfo/nsis
>> >>
>> >
>> >
>> > --------------------------------------
>> > Dr. Marcus Brunner
>> > Network Laboratories
>> > NEC Europe Ltd.
>> >
>> > E-Mail: brunner@ccrle.nec.de
>> > WWW:    http://www.ccrle.nec.de/
>> > personal home page: http://www.brubers.org/marcus
>> >
>> >
>> > _______________________________________________
>> > nsis mailing list
>> > nsis@ietf.org
>> > https://www1.ietf.org/mailman/listinfo/nsis
>>
>>
>>
>> --------------------------------------
>> Dr. Marcus Brunner
>> Network Laboratories
>> NEC Europe Ltd.
>>
>> E-Mail: brunner@ccrle.nec.de
>> WWW:    http://www.ccrle.nec.de/
>> personal home page: http://www.brubers.org/marcus
>>
>>
>>
>> _______________________________________________
>> nsis mailing list
>> nsis@ietf.org
>> https://www1.ietf.org/mailman/listinfo/nsis
>>
>



--------------------------------------
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 Jan 17 06:25: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 GAA11858
	for <nsis-archive@odin.ietf.org>; Thu, 17 Jan 2002 06:25:32 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id GAA26909
	for nsis-archive@odin.ietf.org; Thu, 17 Jan 2002 06:25: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 GAA26817;
	Thu, 17 Jan 2002 06:23: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 GAA26747
	for <nsis@optimus.ietf.org>; Thu, 17 Jan 2002 06:23:38 -0500 (EST)
Received: from mail-server.comgates.co.il ([212.150.198.2])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11820
	for <nsis@ietf.org>; Thu, 17 Jan 2002 06:23:34 -0500 (EST)
Received: by mail-server.comgates.co.il with Internet Mail Service (5.5.2653.19)
	id <DC2CZYBX>; Thu, 17 Jan 2002 13:23:57 +0200
Message-ID: <6FEF757325DBD411B7DA000629A8A61E7BAD40@mail-server.comgates.co.il>
From: Yaron Kahana <ykahana@comgates.co.il>
To: "'brunner@ccrle.nec.de'" <brunner@ccrle.nec.de>,
        "'Georgios Karagiannis (ELN)'" <Georgios.Karagiannis@eln.ericsson.se>,
        "Geib, Ruediger" <Ruediger.Geib@t-systems.com>
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements
Date: Thu, 17 Jan 2002 13:23:56 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C19F49.73BA1B10"
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_01C19F49.73BA1B10
Content-Type: text/plain;
	charset="windows-1255"

It may be a teasing opinion, but in my opinion, one must consider it in the
current slow days. 

Yaron

 -----Original Message-----
From: 	Marcus Brunner [mailto:brunner@ccrle.nec.de] 
Sent:	Thursday, January 17, 2002 1:28 PM
To:	Yaron Kahana; 'Georgios Karagiannis (ELN)'; Geib, Ruediger;
'Freytsis, Ilya'
Cc:	nsis@ietf.org
Subject:	RE: [NSIS] Two kinds of requirements

IMO, there is no solution to a chicken and egg problem in the introduction 
of new Technologies. The deployment is pretty market driven.

Marcus

--On Thursday, January 17, 2002 1:09 PM +0200 Yaron Kahana 
<ykahana@comgates.co.il> wrote:

>
> Hi,
>
> I still don't see how such a toolkit can be useful if a certain domain in
> the middle did not deployed a support in it and the Chicken and Egg
> syndrome.
>
> Yaron
>
> -----Original Message-----
> From: Georgios Karagiannis (ELN)
> [mailto:Georgios.Karagiannis@eln.ericsson.se]  Sent: Thursday, January
> 17, 2002 12:04 PM
> To: 'Yaron Kahana'; Geib, Ruediger; 'Freytsis, Ilya'
> Cc: nsis@ietf.org
> Subject: RE: [NSIS] Two kinds of requirements
>
> Hi Yaron, Ilya, Ruediger
>
> Almost all issues that you addressed in your e-mails can be solved (see
> also my previous e-mail  addressed to Dick) by first creating a modular
> QoS signaling toolkit that will contain mandatory and  optional QoS
> requirements.
> Second, specifying how the protocol functionality should be separated in
> building blocks  (NSIS protocol components) and define a minimum set of
> mandatory reservation options/features  that should be processed by any
> network nodes, e.g., end-hosts, proxies, edges and interior nodes.
>
> Best Regards,
> Georgios
>
> -----Original Message-----
> From: Yaron Kahana [mailto:ykahana@comgates.co.il]
> Sent: woensdag 16 januari 2002 22:16
> To: brunner@ccrle.nec.de; Geib, Ruediger; dick.rr.knight@bt.com
> Cc: nsis@ietf.org
> Subject: RE: [NSIS] Two kinds of requirements
>
>
> Hello Ruediger, Marcus,
>
> I agree with your comments. One of the crucial elements is the
> pre-definition of the provider's policy - admission control decision
> tree, QoS budgeting guides, CDR generation and considerations. Those
> could be done in a practical manner only if there will be a rather small
> number of Service classes (standardized services). I believe that this is
> by far the most practical approach in a multi-providers environment. This
> QoS protocol should be supported not only by the applications, the call
> control elements, and transport routers but by the middleboxes, as well
> as the SLA/QoS verification entities along the way and the billing
> elements.
>
> We should try to keep it simple, even on the expense of full flexibility.
>
> By the way - did anyone considered the problem of a non-cooperative IP
> domain "in the middle" ? for example, Suppose I'm making a call from Los
> Angeles to Munich through 3 domains - LA-NY, NY-London, London-Munich.
> What will happen if the best/cheapest carrier along the NY-London domain
> won't support this new protocol? Will he be condemned/ignored? When will
> he upgrade his infrastructure, before the chicke
>
> Yaron Kahana
> COGITO Project Manager,
> COMGATES
>
>  -----Original Message-----
> From:   Marcus Brunner [ mailto:brunner@ccrle.nec.de
> <mailto:brunner@ccrle.nec.de> ]  Sent:   Wednesday, January 16, 2002 5:35
> PM
> To:     Geib, Ruediger; dick.rr.knight@bt.com
> Cc:     nsis@ietf.org
> Subject:        RE: [NSIS] Two kinds of requirements
>
> Ruediger,
>
> The service needs to be defined anyway. Then there are IMO two
> possibilities
> - the provider defines the services and offers them. In this case the
> provider needs to describe the offers in a machine readable form (most
> likely with parameter names and values)
> - the consumer requests a particular service (this means the consumer has
> to describe the service he wants in a machine readable form)
>
> So it seams one has to move around service specifications which are
> understandable by the other party anyway, what is now your point? Is it
> that you want to limit/fix as many parameters as possible? Or are you
> more  think about standardized services everybody understands?
>
> Marcus
>
> --On Wednesday, January 16, 2002 3:45 PM +0100 "Geib, Ruediger"
> <Ruediger.Geib@t-systems.com> wrote:
>
>> Hello Dick,
>>
>> your suggestion is quite reasonable. I also favour an architecture where
>> a QoS request by and large is predefined in terms of the resources
>> required from the available transport mechanism. Service specific
>> parameters to be signaled during reservation should be strictly limited.
>> The more mapping and evaluation of QoS parameters is required during
>> reservation, the more complex the service gets. Complex services are
>> hard  to sell and hard to provide.
>>
>> Regards,
>>
>> R?diger
>>
>> R?diger Geib
>> Senior Project Manager
>> T-Systems Nova GmbH
>>
>>> I think that what is needed is a new protocol that can signal the
>>> requirements of any session and can be satisfied by any QoS
>>> mechanism, existing or new.
>>> To be more precise, I am suggesting a new protocol that is
>>> independent of the underlying transport technology and the QoS
>>> implemented and is also independent of the session control
>>> protocol. Such a new protocol would be generic, optionally
>>> implemented by applications that would benefit from
>>> end-to-end QoS, and would be complimentary to the QoS
>>> mechanisms deployed (and of course other mechanisms,
>>> such as the routing).
>>>
>>> I think that this implies a more abstract definition of the
>>> QoS mechanism and may lend itself to the signalling of
>>> pre-defined QoS classes rather than parameters.
>>>
>>> Dick Knight
>>
>>
>> _______________________________________________
>> nsis mailing list
>> nsis@ietf.org
>> https://www1.ietf.org/mailman/listinfo/nsis
>> <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/ <http://www.ccrle.nec.de/>
> personal home page: http://www.brubers.org/marcus
> <http://www.brubers.org/marcus>
>
>
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis
> <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


------_=_NextPart_001_01C19F49.73BA1B10
Content-Type: text/html;
	charset="windows-1255"
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=3Dwindows-1255">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>RE: [NSIS] Two kinds of requirements</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>It may be a teasing opinion, but in my opinion, one =
must consider it in the current slow days. </FONT>
</P>

<P><FONT SIZE=3D2>Yaron</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: &nbsp; Marcus Brunner [<A =
HREF=3D"mailto:brunner@ccrle.nec.de">mailto:brunner@ccrle.nec.de</A>] =
</FONT>
<BR><FONT SIZE=3D2>Sent:&nbsp;&nbsp; Thursday, January 17, 2002 1:28 =
PM</FONT>
<BR><FONT SIZE=3D2>To:&nbsp;&nbsp;&nbsp;&nbsp; Yaron Kahana; 'Georgios =
Karagiannis (ELN)'; Geib, Ruediger; 'Freytsis, Ilya'</FONT>
<BR><FONT SIZE=3D2>Cc:&nbsp;&nbsp;&nbsp;&nbsp; nsis@ietf.org</FONT>
<BR><FONT SIZE=3D2>Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
RE: [NSIS] Two kinds of requirements</FONT>
</P>

<P><FONT SIZE=3D2>IMO, there is no solution to a chicken and egg =
problem in the introduction </FONT>
<BR><FONT SIZE=3D2>of new Technologies. The deployment is pretty market =
driven.</FONT>
</P>

<P><FONT SIZE=3D2>Marcus</FONT>
</P>

<P><FONT SIZE=3D2>--On Thursday, January 17, 2002 1:09 PM +0200 Yaron =
Kahana </FONT>
<BR><FONT SIZE=3D2>&lt;ykahana@comgates.co.il&gt; wrote:</FONT>
</P>

<P><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; Hi,</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; I still don't see how such a toolkit can be =
useful if a certain domain in</FONT>
<BR><FONT SIZE=3D2>&gt; the middle did not deployed a support in it and =
the Chicken and Egg</FONT>
<BR><FONT SIZE=3D2>&gt; syndrome.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; Yaron</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Georgios Karagiannis (ELN)</FONT>
<BR><FONT SIZE=3D2>&gt; [<A =
HREF=3D"mailto:Georgios.Karagiannis@eln.ericsson.se">mailto:Georgios.Kar=
agiannis@eln.ericsson.se</A>]&nbsp; Sent: Thursday, January</FONT>
<BR><FONT SIZE=3D2>&gt; 17, 2002 12:04 PM</FONT>
<BR><FONT SIZE=3D2>&gt; To: 'Yaron Kahana'; Geib, Ruediger; 'Freytsis, =
Ilya'</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: nsis@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: RE: [NSIS] Two kinds of =
requirements</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; Hi Yaron, Ilya, Ruediger</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; Almost all issues that you addressed in your =
e-mails can be solved (see</FONT>
<BR><FONT SIZE=3D2>&gt; also my previous e-mail&nbsp; addressed to =
Dick) by first creating a modular</FONT>
<BR><FONT SIZE=3D2>&gt; QoS signaling toolkit that will contain =
mandatory and&nbsp; optional QoS</FONT>
<BR><FONT SIZE=3D2>&gt; requirements.</FONT>
<BR><FONT SIZE=3D2>&gt; Second, specifying how the protocol =
functionality should be separated in</FONT>
<BR><FONT SIZE=3D2>&gt; building blocks&nbsp; (NSIS protocol =
components) and define a minimum set of</FONT>
<BR><FONT SIZE=3D2>&gt; mandatory reservation options/features&nbsp; =
that should be processed by any</FONT>
<BR><FONT SIZE=3D2>&gt; network nodes, e.g., end-hosts, proxies, edges =
and interior nodes.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; Best Regards,</FONT>
<BR><FONT SIZE=3D2>&gt; Georgios</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Yaron Kahana [<A =
HREF=3D"mailto:ykahana@comgates.co.il">mailto:ykahana@comgates.co.il</A>=
]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: woensdag 16 januari 2002 22:16</FONT>
<BR><FONT SIZE=3D2>&gt; To: brunner@ccrle.nec.de; Geib, Ruediger; =
dick.rr.knight@bt.com</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: nsis@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: RE: [NSIS] Two kinds of =
requirements</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; Hello Ruediger, Marcus,</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; I agree with your comments. One of the crucial =
elements is the</FONT>
<BR><FONT SIZE=3D2>&gt; pre-definition of the provider's policy - =
admission control decision</FONT>
<BR><FONT SIZE=3D2>&gt; tree, QoS budgeting guides, CDR generation and =
considerations. Those</FONT>
<BR><FONT SIZE=3D2>&gt; could be done in a practical manner only if =
there will be a rather small</FONT>
<BR><FONT SIZE=3D2>&gt; number of Service classes (standardized =
services). I believe that this is</FONT>
<BR><FONT SIZE=3D2>&gt; by far the most practical approach in a =
multi-providers environment. This</FONT>
<BR><FONT SIZE=3D2>&gt; QoS protocol should be supported not only by =
the applications, the call</FONT>
<BR><FONT SIZE=3D2>&gt; control elements, and transport routers but by =
the middleboxes, as well</FONT>
<BR><FONT SIZE=3D2>&gt; as the SLA/QoS verification entities along the =
way and the billing</FONT>
<BR><FONT SIZE=3D2>&gt; elements.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; We should try to keep it simple, even on the =
expense of full flexibility.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; By the way - did anyone considered the problem =
of a non-cooperative IP</FONT>
<BR><FONT SIZE=3D2>&gt; domain &quot;in the middle&quot; ? for example, =
Suppose I'm making a call from Los</FONT>
<BR><FONT SIZE=3D2>&gt; Angeles to Munich through 3 domains - LA-NY, =
NY-London, London-Munich.</FONT>
<BR><FONT SIZE=3D2>&gt; What will happen if the best/cheapest carrier =
along the NY-London domain</FONT>
<BR><FONT SIZE=3D2>&gt; won't support this new protocol? Will he be =
condemned/ignored? When will</FONT>
<BR><FONT SIZE=3D2>&gt; he upgrade his infrastructure, before the =
chicke</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; Yaron Kahana</FONT>
<BR><FONT SIZE=3D2>&gt; COGITO Project Manager,</FONT>
<BR><FONT SIZE=3D2>&gt; COMGATES</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From:&nbsp;&nbsp; Marcus Brunner [ <A =
HREF=3D"mailto:brunner@ccrle.nec.de">mailto:brunner@ccrle.nec.de</A></FO=
NT>
<BR><FONT SIZE=3D2>&gt; &lt;<A =
HREF=3D"mailto:brunner@ccrle.nec.de">mailto:brunner@ccrle.nec.de</A>&gt;=
 ]&nbsp; Sent:&nbsp;&nbsp; Wednesday, January 16, 2002 5:35</FONT>
<BR><FONT SIZE=3D2>&gt; PM</FONT>
<BR><FONT SIZE=3D2>&gt; To:&nbsp;&nbsp;&nbsp;&nbsp; Geib, Ruediger; =
dick.rr.knight@bt.com</FONT>
<BR><FONT SIZE=3D2>&gt; Cc:&nbsp;&nbsp;&nbsp;&nbsp; =
nsis@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; =
Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; RE: [NSIS] Two kinds =
of requirements</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; Ruediger,</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; The service needs to be defined anyway. Then =
there are IMO two</FONT>
<BR><FONT SIZE=3D2>&gt; possibilities</FONT>
<BR><FONT SIZE=3D2>&gt; - the provider defines the services and offers =
them. In this case the</FONT>
<BR><FONT SIZE=3D2>&gt; provider needs to describe the offers in a =
machine readable form (most</FONT>
<BR><FONT SIZE=3D2>&gt; likely with parameter names and values)</FONT>
<BR><FONT SIZE=3D2>&gt; - the consumer requests a particular service =
(this means the consumer has</FONT>
<BR><FONT SIZE=3D2>&gt; to describe the service he wants in a machine =
readable form)</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; So it seams one has to move around service =
specifications which are</FONT>
<BR><FONT SIZE=3D2>&gt; understandable by the other party anyway, what =
is now your point? Is it</FONT>
<BR><FONT SIZE=3D2>&gt; that you want to limit/fix as many parameters =
as possible? Or are you</FONT>
<BR><FONT SIZE=3D2>&gt; more&nbsp; think about standardized services =
everybody understands?</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; Marcus</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; --On Wednesday, January 16, 2002 3:45 PM +0100 =
&quot;Geib, Ruediger&quot;</FONT>
<BR><FONT SIZE=3D2>&gt; &lt;Ruediger.Geib@t-systems.com&gt; =
wrote:</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; Hello Dick,</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; your suggestion is quite reasonable. I also =
favour an architecture where</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; a QoS request by and large is predefined in =
terms of the resources</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; required from the available transport =
mechanism. Service specific</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; parameters to be signaled during =
reservation should be strictly limited.</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; The more mapping and evaluation of QoS =
parameters is required during</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; reservation, the more complex the service =
gets. Complex services are</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; hard&nbsp; to sell and hard to =
provide.</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; Regards,</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; R?diger</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; R?diger Geib</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; Senior Project Manager</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; T-Systems Nova GmbH</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt; I think that what is needed is a new =
protocol that can signal the</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt; requirements of any session and can be =
satisfied by any QoS</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt; mechanism, existing or new.</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt; To be more precise, I am suggesting a =
new protocol that is</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt; independent of the underlying transport =
technology and the QoS</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt; implemented and is also independent of =
the session control</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt; protocol. Such a new protocol would be =
generic, optionally</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt; implemented by applications that would =
benefit from</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt; end-to-end QoS, and would be =
complimentary to the QoS</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt; mechanisms deployed (and of course =
other mechanisms,</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt; such as the routing).</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt; I think that this implies a more =
abstract definition of the</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt; QoS mechanism and may lend itself to =
the signalling of</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt; pre-defined QoS classes rather than =
parameters.</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&gt; Dick Knight</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; =
_______________________________________________</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; nsis mailing list</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; nsis@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt;&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;&gt; &lt;<A =
HREF=3D"https://www1.ietf.org/mailman/listinfo/nsis" =
TARGET=3D"_blank">https://www1.ietf.org/mailman/listinfo/nsis</A>&gt;</F=
ONT>
<BR><FONT SIZE=3D2>&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; --------------------------------------</FONT>
<BR><FONT SIZE=3D2>&gt; Dr. Marcus Brunner</FONT>
<BR><FONT SIZE=3D2>&gt; Network Laboratories</FONT>
<BR><FONT SIZE=3D2>&gt; NEC Europe Ltd.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; E-Mail: brunner@ccrle.nec.de</FONT>
<BR><FONT SIZE=3D2>&gt; WWW:&nbsp;&nbsp;&nbsp; <A =
HREF=3D"http://www.ccrle.nec.de/" =
TARGET=3D"_blank">http://www.ccrle.nec.de/</A> &lt;<A =
HREF=3D"http://www.ccrle.nec.de/" =
TARGET=3D"_blank">http://www.ccrle.nec.de/</A>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; personal home page: <A =
HREF=3D"http://www.brubers.org/marcus" =
TARGET=3D"_blank">http://www.brubers.org/marcus</A></FONT>
<BR><FONT SIZE=3D2>&gt; &lt;<A HREF=3D"http://www.brubers.org/marcus" =
TARGET=3D"_blank">http://www.brubers.org/marcus</A>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;</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; &lt;<A =
HREF=3D"https://www1.ietf.org/mailman/listinfo/nsis" =
TARGET=3D"_blank">https://www1.ietf.org/mailman/listinfo/nsis</A>&gt;</F=
ONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>--------------------------------------</FONT>
<BR><FONT SIZE=3D2>Dr. Marcus Brunner</FONT>
<BR><FONT SIZE=3D2>Network Laboratories</FONT>
<BR><FONT SIZE=3D2>NEC Europe Ltd.</FONT>
</P>

<P><FONT SIZE=3D2>E-Mail: brunner@ccrle.nec.de</FONT>
<BR><FONT SIZE=3D2>WWW:&nbsp;&nbsp;&nbsp; <A =
HREF=3D"http://www.ccrle.nec.de/" =
TARGET=3D"_blank">http://www.ccrle.nec.de/</A></FONT>
<BR><FONT SIZE=3D2>personal home page: <A =
HREF=3D"http://www.brubers.org/marcus" =
TARGET=3D"_blank">http://www.brubers.org/marcus</A></FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C19F49.73BA1B10--

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



From daemon@optimus.ietf.org  Thu Jan 17 06:26:16 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11873
	for <nsis-archive@odin.ietf.org>; Thu, 17 Jan 2002 06:26:16 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id GAA26927
	for nsis-archive@odin.ietf.org; Thu, 17 Jan 2002 06:26: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 GAA26896;
	Thu, 17 Jan 2002 06:25: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 GAA26865
	for <nsis@optimus.ietf.org>; Thu, 17 Jan 2002 06:25:16 -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 GAA11842
	for <nsis@ietf.org>; Thu, 17 Jan 2002 06:25:14 -0500 (EST)
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 g0HBOpu05376
	for <nsis@ietf.org>; Thu, 17 Jan 2002 13:24:51 +0200 (EET)
Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T588107fdafac158f2515f@esvir05nok.ntc.nokia.com>;
 Thu, 17 Jan 2002 13:25:06 +0200
Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779);
	 Thu, 17 Jan 2002 13:25:06 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [NSIS] Two kinds of requirements
Date: Thu, 17 Jan 2002 13:25:06 +0200
Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF5D9378@esebe004.NOE.Nokia.com>
Thread-Topic: [NSIS] Two kinds of requirements
Thread-Index: AcGfOwWr0DISgPV2S2e1GHa3meWrHgADe4Yw
From: "Loughney John (NRC/Helsinki)" <john.loughney@nokia.com>
To: "'ext Georgios Karagiannis (ELN)'" <Georgios.Karagiannis@eln.ericsson.se>,
        <dick.rr.knight@bt.com>
Cc: <nsis@ietf.org>
X-OriginalArrivalTime: 17 Jan 2002 11:25:06.0700 (UTC) FILETIME=[9D8124C0:01C19F49]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id GAA26866
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,

One thing that struck me from the mail below is:

> A way of achieving this is by first creating a modular QoS 
> signaling toolkit that will contain mandatory and optional QoS 
> requirements;

What is an optional requirement?  My dictionary says that
requirement means:

	a : something wanted or needed : NECESSITY 
 
	b : something essential to the existence or 
          occurrence of something else : 

My strong suggestion is that we drop discussion of all
optional requirements, since it is an oxymoron.  Any
solution we work on can do more than what we list in
the requirements work, but the requirements draft
SHOULD be a pithy read (in other words, a short
document).

best regards,
John

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



From daemon@optimus.ietf.org  Thu Jan 17 06:27: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 GAA11899
	for <nsis-archive@odin.ietf.org>; Thu, 17 Jan 2002 06:27:42 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id GAA26995
	for nsis-archive@odin.ietf.org; Thu, 17 Jan 2002 06:27: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 GAA26551;
	Thu, 17 Jan 2002 06:17: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 GAA26516
	for <nsis@optimus.ietf.org>; Thu, 17 Jan 2002 06:17:50 -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 GAA11762
	for <nsis@ietf.org>; Thu, 17 Jan 2002 06:17:46 -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 g0HBH5H57066;
	Thu, 17 Jan 2002 12:17:05 +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 5DBA9C052; Thu, 17 Jan 2002 12:16:36 +0100 (CET)
Date: Thu, 17 Jan 2002 12:28:10 +0100
From: Marcus Brunner <brunner@ccrle.nec.de>
Reply-To: brunner@ccrle.nec.de
To: Yaron Kahana <ykahana@comgates.co.il>,
        "'Georgios Karagiannis (ELN)'" <Georgios.Karagiannis@eln.ericsson.se>,
        "Geib, Ruediger" <Ruediger.Geib@t-systems.com>,
        "'Freytsis, Ilya'" <ifreytsis@cetacean.com>
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements
Message-ID: <7694904.1011270490@[192.168.102.79]>
In-Reply-To: <6FEF757325DBD411B7DA000629A8A61E7BAD3E@mail-server.comgates.co.il>
References:  <6FEF757325DBD411B7DA000629A8A61E7BAD3E@mail-server.comgates.co.
 il>
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

IMO, there is no solution to a chicken and egg problem in the introduction 
of new Technologies. The deployment is pretty market driven.

Marcus

--On Thursday, January 17, 2002 1:09 PM +0200 Yaron Kahana 
<ykahana@comgates.co.il> wrote:

>
> Hi,
>
> I still don't see how such a toolkit can be useful if a certain domain in
> the middle did not deployed a support in it and the Chicken and Egg
> syndrome.
>
> Yaron
>
> -----Original Message-----
> From: Georgios Karagiannis (ELN)
> [mailto:Georgios.Karagiannis@eln.ericsson.se]  Sent: Thursday, January
> 17, 2002 12:04 PM
> To: 'Yaron Kahana'; Geib, Ruediger; 'Freytsis, Ilya'
> Cc: nsis@ietf.org
> Subject: RE: [NSIS] Two kinds of requirements
>
> Hi Yaron, Ilya, Ruediger
>
> Almost all issues that you addressed in your e-mails can be solved (see
> also my previous e-mail  addressed to Dick) by first creating a modular
> QoS signaling toolkit that will contain mandatory and  optional QoS
> requirements.
> Second, specifying how the protocol functionality should be separated in
> building blocks  (NSIS protocol components) and define a minimum set of
> mandatory reservation options/features  that should be processed by any
> network nodes, e.g., end-hosts, proxies, edges and interior nodes.
>
> Best Regards,
> Georgios
>
> -----Original Message-----
> From: Yaron Kahana [mailto:ykahana@comgates.co.il]
> Sent: woensdag 16 januari 2002 22:16
> To: brunner@ccrle.nec.de; Geib, Ruediger; dick.rr.knight@bt.com
> Cc: nsis@ietf.org
> Subject: RE: [NSIS] Two kinds of requirements
>
>
> Hello Ruediger, Marcus,
>
> I agree with your comments. One of the crucial elements is the
> pre-definition of the provider's policy - admission control decision
> tree, QoS budgeting guides, CDR generation and considerations. Those
> could be done in a practical manner only if there will be a rather small
> number of Service classes (standardized services). I believe that this is
> by far the most practical approach in a multi-providers environment. This
> QoS protocol should be supported not only by the applications, the call
> control elements, and transport routers but by the middleboxes, as well
> as the SLA/QoS verification entities along the way and the billing
> elements.
>
> We should try to keep it simple, even on the expense of full flexibility.
>
> By the way - did anyone considered the problem of a non-cooperative IP
> domain "in the middle" ? for example, Suppose I'm making a call from Los
> Angeles to Munich through 3 domains - LA-NY, NY-London, London-Munich.
> What will happen if the best/cheapest carrier along the NY-London domain
> won't support this new protocol? Will he be condemned/ignored? When will
> he upgrade his infrastructure, before the chicke
>
> Yaron Kahana
> COGITO Project Manager,
> COMGATES
>
>  -----Original Message-----
> From:   Marcus Brunner [ mailto:brunner@ccrle.nec.de
> <mailto:brunner@ccrle.nec.de> ]  Sent:   Wednesday, January 16, 2002 5:35
> PM
> To:     Geib, Ruediger; dick.rr.knight@bt.com
> Cc:     nsis@ietf.org
> Subject:        RE: [NSIS] Two kinds of requirements
>
> Ruediger,
>
> The service needs to be defined anyway. Then there are IMO two
> possibilities
> - the provider defines the services and offers them. In this case the
> provider needs to describe the offers in a machine readable form (most
> likely with parameter names and values)
> - the consumer requests a particular service (this means the consumer has
> to describe the service he wants in a machine readable form)
>
> So it seams one has to move around service specifications which are
> understandable by the other party anyway, what is now your point? Is it
> that you want to limit/fix as many parameters as possible? Or are you
> more  think about standardized services everybody understands?
>
> Marcus
>
> --On Wednesday, January 16, 2002 3:45 PM +0100 "Geib, Ruediger"
> <Ruediger.Geib@t-systems.com> wrote:
>
>> Hello Dick,
>>
>> your suggestion is quite reasonable. I also favour an architecture where
>> a QoS request by and large is predefined in terms of the resources
>> required from the available transport mechanism. Service specific
>> parameters to be signaled during reservation should be strictly limited.
>> The more mapping and evaluation of QoS parameters is required during
>> reservation, the more complex the service gets. Complex services are
>> hard  to sell and hard to provide.
>>
>> Regards,
>>
>> R?diger
>>
>> R?diger Geib
>> Senior Project Manager
>> T-Systems Nova GmbH
>>
>>> I think that what is needed is a new protocol that can signal the
>>> requirements of any session and can be satisfied by any QoS
>>> mechanism, existing or new.
>>> To be more precise, I am suggesting a new protocol that is
>>> independent of the underlying transport technology and the QoS
>>> implemented and is also independent of the session control
>>> protocol. Such a new protocol would be generic, optionally
>>> implemented by applications that would benefit from
>>> end-to-end QoS, and would be complimentary to the QoS
>>> mechanisms deployed (and of course other mechanisms,
>>> such as the routing).
>>>
>>> I think that this implies a more abstract definition of the
>>> QoS mechanism and may lend itself to the signalling of
>>> pre-defined QoS classes rather than parameters.
>>>
>>> Dick Knight
>>
>>
>> _______________________________________________
>> nsis mailing list
>> nsis@ietf.org
>> https://www1.ietf.org/mailman/listinfo/nsis
>> <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/ <http://www.ccrle.nec.de/>
> personal home page: http://www.brubers.org/marcus
> <http://www.brubers.org/marcus>
>
>
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis
> <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 Jan 17 06:36: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 GAA12002
	for <nsis-archive@odin.ietf.org>; Thu, 17 Jan 2002 06:36:50 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id GAA27552
	for nsis-archive@odin.ietf.org; Thu, 17 Jan 2002 06:36: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 GAA26974;
	Thu, 17 Jan 2002 06:26:58 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA26944
	for <nsis@optimus.ietf.org>; Thu, 17 Jan 2002 06:26:56 -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 GAA11894
	for <nsis@ietf.org>; Thu, 17 Jan 2002 06:26:54 -0500 (EST)
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 g0HBQu912176
	for <nsis@ietf.org>; Thu, 17 Jan 2002 13:26:57 +0200 (EET)
Received: from esebh002.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T5881099fd5ac158f220c8@esvir02nok.ntc.nokia.com>;
 Thu, 17 Jan 2002 13:26:53 +0200
Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779);
	 Thu, 17 Jan 2002 13:26:53 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [NSIS] Two kinds of requirements
Date: Thu, 17 Jan 2002 13:26:52 +0200
Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF5D9379@esebe004.NOE.Nokia.com>
Thread-Topic: [NSIS] Two kinds of requirements
Thread-Index: AcGfQJOVeFHPwbliT5iEMc99cOOK8gACRrmg
From: "Loughney John (NRC/Helsinki)" <john.loughney@nokia.com>
To: "'ext Georgios Karagiannis (ELN)'" <Georgios.Karagiannis@eln.ericsson.se>
Cc: <nsis@ietf.org>
X-OriginalArrivalTime: 17 Jan 2002 11:26:53.0273 (UTC) FILETIME=[DD06E490:01C19F49]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id GAA26945
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,

> In the "analysis draft" located at the following URL, 
> a "brief" analysis, in the context of NSIS, of RFC2998
> is made.

Brief is correct.  My suggest was that we should look
at 2998 and see if we can apply RSVP to more than
just DiffServ / Intserv.  That is one of the primary 
tasks of this working group.

John

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



From daemon@optimus.ietf.org  Thu Jan 17 06: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 GAA12094
	for <nsis-archive@odin.ietf.org>; Thu, 17 Jan 2002 06:42:51 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id GAA27825
	for nsis-archive@odin.ietf.org; Thu, 17 Jan 2002 06:42: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 GAA27789;
	Thu, 17 Jan 2002 06:41: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 GAA27759
	for <nsis@optimus.ietf.org>; Thu, 17 Jan 2002 06:41:28 -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 GAA12049
	for <nsis@ietf.org>; Thu, 17 Jan 2002 06:41:24 -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 g0HBeiH57348;
	Thu, 17 Jan 2002 12:40:44 +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 8E438C052; Thu, 17 Jan 2002 12:40:15 +0100 (CET)
Date: Thu, 17 Jan 2002 12:51:50 +0100
From: Marcus Brunner <brunner@ccrle.nec.de>
Reply-To: brunner@ccrle.nec.de
To: "Loughney John (NRC/Helsinki)" <john.loughney@nokia.com>,
        Yaron Kahana <ykahana@comgates.co.il>,
        "Geib, Ruediger" <Ruediger.Geib@t-systems.com>, dick.rr.knight@bt.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements
Message-ID: <9114215.1011271910@[192.168.102.79]>
In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEF09BC56@esebe004.NOE.Nokia.com>
References:  <0C1353ABB1DEB74DB067ADFF749C4EEF09BC56@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

John,

[...]

> I've been wondering if this is a spurious argument.  I cannot think of
> how service providers could use QoS as a service.  What I have been
> hearing from service providers is that they would like to be able
> to provide certain QoS levels for customers, but they would like
> to be free to deploy / allocate resources as they see fit.
>

As soon as you signal QoS from the host into the network, you ask for an IP 
transport service with certain guarantees. IMO, this MUST be independent of 
the ressource allocation, technology etc. within the providers network.

> With the PSTN, there SHOULD be only one quality, but in practice,
> when calling overseas, I tend to get quite variable quality - of course
> I still pay the same price ...
>

In the PSTN case you signal even on a higher level. You ask for a voice 
communication from A to B, where A and B might be persons not even network 
end-points. So, signalling for QoS, ressource allocation, session 
initiation  is integrated.

In IP, you can only signal for a transport service without specifying what 
is transported.

Marcus

> Additionally, I think we need to start somewhere, and I think that we
> need to be able to set some base line for signaling QoS. This does not
> mean that we cannot allow more to be done / offered, but we want
> to start with a minimum.  One option could be that we allow a simple
> solution that supports optional extras.  These extras could be used
> by service providers for enhanced services, but we don't specify
> them.
>
> best regards,
> John
>



--------------------------------------
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 Jan 17 07:55: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 HAA13666
	for <nsis-archive@odin.ietf.org>; Thu, 17 Jan 2002 07:55:30 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id HAA00156
	for nsis-archive@odin.ietf.org; Thu, 17 Jan 2002 07:55: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 HAA00135;
	Thu, 17 Jan 2002 07:54: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 HAA00106
	for <nsis@optimus.ietf.org>; Thu, 17 Jan 2002 07:54: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 HAA13638
	for <nsis@ietf.org>; Thu, 17 Jan 2002 07:54:07 -0500 (EST)
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 g0HCsA908019
	for <nsis@ietf.org>; Thu, 17 Jan 2002 14:54:10 +0200 (EET)
Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T5881597ce0ac158f240c7@esvir04nok.ntc.nokia.com>;
 Thu, 17 Jan 2002 14:54:07 +0200
Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779);
	 Thu, 17 Jan 2002 14:54:06 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [NSIS] Two kinds of requirements
Date: Thu, 17 Jan 2002 14:54:05 +0200
Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF5D937D@esebe004.NOE.Nokia.com>
Thread-Topic: [NSIS] Two kinds of requirements
Thread-Index: AcGfVeE9Lhs51xIxSBKveD8nPe3wGgAAAn9Q
From: "Loughney John (NRC/Helsinki)" <john.loughney@nokia.com>
To: "'ext Kappler Cornelia'" <Cornelia.Kappler@icn.siemens.de>,
        "'ext Georgios Karagiannis (ELN)'" <Georgios.Karagiannis@eln.ericsson.se>
Cc: <nsis@ietf.org>
X-OriginalArrivalTime: 17 Jan 2002 12:54:06.0528 (UTC) FILETIME=[0C4A3C00:01C19F56]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id HAA00107
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 Cornelia,

> to my understanding the very idea of the modular / toolkit 
> approach is providing basic "MUST" functionality, but at the 
> same time _leaving open_ the possiblity of later adding "MAY" 
> functionality. 
> 
> This means we should try designing the protocol such that 
> later "MAY" functionality can be added in a modular fashion. 

Yes, I agree with you & Georgios, however, with respect to
the Requirements Document - I think we should only place
MUSTs in such a document.

John

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



From daemon@optimus.ietf.org  Thu Jan 17 07:56:11 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13682
	for <nsis-archive@odin.ietf.org>; Thu, 17 Jan 2002 07:56:11 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id HAA00179
	for nsis-archive@odin.ietf.org; Thu, 17 Jan 2002 07:56: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 HAA29796;
	Thu, 17 Jan 2002 07:43: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 HAA29769
	for <nsis@optimus.ietf.org>; Thu, 17 Jan 2002 07:43:52 -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 HAA13423
	for <nsis@ietf.org>; Thu, 17 Jan 2002 07:43:48 -0500 (EST)
Received: from esealnt409.al.sw.ericsson.se (ESEALNT409.al.sw.ericsson.se [153.88.251.32])
	by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g0HChmK11063
	for <nsis@ietf.org>; Thu, 17 Jan 2002 13:43:48 +0100 (MET)
Received: FROM esealnt747.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Thu Jan 17 13:43:39 2002 +0100
Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <YHKTKN37>; Thu, 17 Jan 2002 13:43:23 +0100
Message-ID: <E244E44D6AB85E40AEEF7EAABE3545FA823369@enleent104.nl.eu.ericsson.se>
From: "Georgios Karagiannis (ELN)" <Georgios.Karagiannis@eln.ericsson.se>
To: "'Loughney John (NRC/Helsinki)'" <john.loughney@nokia.com>
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements
Date: Thu, 17 Jan 2002 13:43:38 +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

By mandatory, I mean, requirements that MUST be supported 
(used) by a node and optional are requirements that 
MAY be supported by a node!


Best Regards,
Georgios


-----Original Message-----
From: Loughney John (NRC/Helsinki) [mailto:john.loughney@nokia.com]
Sent: donderdag 17 januari 2002 12:25
To: 'ext Georgios Karagiannis (ELN)'; dick.rr.knight@bt.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


Hi Georgios,

One thing that struck me from the mail below is:

> A way of achieving this is by first creating a modular QoS 
> signaling toolkit that will contain mandatory and optional QoS 
> requirements;

What is an optional requirement?  My dictionary says that
requirement means:

	a : something wanted or needed : NECESSITY 
 
	b : something essential to the existence or 
          occurrence of something else : 

My strong suggestion is that we drop discussion of all
optional requirements, since it is an oxymoron.  Any
solution we work on can do more than what we list in
the requirements work, but the requirements draft
SHOULD be a pithy read (in other words, a short
document).

best regards,
John

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



From daemon@optimus.ietf.org  Thu Jan 17 07:58:31 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13746
	for <nsis-archive@odin.ietf.org>; Thu, 17 Jan 2002 07:58:31 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id HAA00209
	for nsis-archive@odin.ietf.org; Thu, 17 Jan 2002 07:58: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 HAA29904;
	Thu, 17 Jan 2002 07:45: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 HAA29873
	for <nsis@optimus.ietf.org>; Thu, 17 Jan 2002 07:45:26 -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 HAA13439
	for <nsis@ietf.org>; Thu, 17 Jan 2002 07:45:07 -0500 (EST)
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 g0HCinu12698
	for <nsis@ietf.org>; Thu, 17 Jan 2002 14:44:49 +0200 (EET)
Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T5881512c8cac158f2515f@esvir05nok.ntc.nokia.com>;
 Thu, 17 Jan 2002 14:45:02 +0200
Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779);
	 Thu, 17 Jan 2002 14:45:02 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [NSIS] Two kinds of requirements
Date: Thu, 17 Jan 2002 14:45:02 +0200
Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF5D937C@esebe004.NOE.Nokia.com>
Thread-Topic: [NSIS] Two kinds of requirements
Thread-Index: AcGfVJ+tSNww45l3QqG0UIFlrV+EvwAABSOw
From: "Loughney John (NRC/Helsinki)" <john.loughney@nokia.com>
To: "'ext Georgios Karagiannis (ELN)'" <Georgios.Karagiannis@eln.ericsson.se>
Cc: <nsis@ietf.org>
X-OriginalArrivalTime: 17 Jan 2002 12:45:02.0689 (UTC) FILETIME=[C822FD10:01C19F54]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id HAA29874
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,

> By mandatory, I mean, requirements that MUST be supported 
> (used) by a node and optional are requirements that 
> MAY be supported by a node!

If it is optional, then it is not required.

John

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



From daemon@optimus.ietf.org  Thu Jan 17 08:02: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 IAA13860
	for <nsis-archive@odin.ietf.org>; Thu, 17 Jan 2002 08:02:15 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id IAA00750
	for nsis-archive@odin.ietf.org; Thu, 17 Jan 2002 08:02: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 HAA29656;
	Thu, 17 Jan 2002 07:35: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 HAA29629
	for <nsis@optimus.ietf.org>; Thu, 17 Jan 2002 07:35:27 -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 HAA13259
	for <nsis@ietf.org>; Thu, 17 Jan 2002 07:35:24 -0500 (EST)
Received: from esealnt409.al.sw.ericsson.se (ESEALNT409.al.sw.ericsson.se [153.88.251.32])
	by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g0HCZOK02089
	for <nsis@ietf.org>; Thu, 17 Jan 2002 13:35:24 +0100 (MET)
Received: FROM esealnt747.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Thu Jan 17 13:35:23 2002 +0100
Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <YHKTKNMQ>; Thu, 17 Jan 2002 13:35:07 +0100
Message-ID: <E244E44D6AB85E40AEEF7EAABE3545FA823368@enleent104.nl.eu.ericsson.se>
From: "Georgios Karagiannis (ELN)" <Georgios.Karagiannis@eln.ericsson.se>
To: "'Yaron Kahana'" <ykahana@comgates.co.il>
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements
Date: Thu, 17 Jan 2002 13:35:23 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="windows-1255"
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 Yaron
 
Assuming that the domain in the middle supports over-provisioning the end -to end QoS provisioning
could be satisfied.
 
Best Regards,
Georgios

-----Original Message-----
From: Yaron Kahana [mailto:ykahana@comgates.co.il]
Sent: donderdag 17 januari 2002 12:09
To: 'Georgios Karagiannis (ELN)'; Geib, Ruediger; 'Freytsis, Ilya'
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements



Hi, 

I still don't see how such a toolkit can be useful if a certain domain in the middle did not deployed a support in it and the Chicken and Egg syndrome.

Yaron 

-----Original Message----- 
From: Georgios Karagiannis (ELN) [ mailto:Georgios.Karagiannis@eln.ericsson.se <mailto:Georgios.Karagiannis@eln.ericsson.se> ] 
Sent: Thursday, January 17, 2002 12:04 PM 
To: 'Yaron Kahana'; Geib, Ruediger; 'Freytsis, Ilya' 
Cc: nsis@ietf.org 
Subject: RE: [NSIS] Two kinds of requirements 

Hi Yaron, Ilya, Ruediger 

Almost all issues that you addressed in your e-mails can be solved (see also my previous e-mail 
addressed to Dick) by first creating a modular QoS signaling toolkit that will contain mandatory and 
optional QoS requirements. 
Second, specifying how the protocol functionality should be separated in building blocks 
(NSIS protocol components) and define a minimum set of mandatory reservation options/features 
that should be processed by any network nodes, e.g., end-hosts, proxies, edges and interior nodes. 

Best Regards, 
Georgios 

-----Original Message----- 
From: Yaron Kahana [ mailto:ykahana@comgates.co.il <mailto:ykahana@comgates.co.il> ] 
Sent: woensdag 16 januari 2002 22:16 
To: brunner@ccrle.nec.de; Geib, Ruediger; dick.rr.knight@bt.com 
Cc: nsis@ietf.org 
Subject: RE: [NSIS] Two kinds of requirements 



Hello Ruediger, Marcus, 

I agree with your comments. One of the crucial elements is th

We should try to keep it simple, even on the expense of full flexibility. 

By the way - did anyone considered the problem of a non-cooperative IP domain "in the middle" ? for example, Suppose I'm making a call from Los Angeles to Munich through 3 domains - LA-NY, NY-London, London-Munich. What will happen if the best/cheapest carrier along the NY-London domain won't support this new protocol? Will he be condemned/ignored? When will he upgrade his infrastructure, before the chicke

Yaron Kahana 
COGITO Project Manager, 
COMGATES 

 -----Original Message----- 
From:   Marcus Brunner [ mailto:brunner@ccrle.nec.de <mailto:brunner@ccrle.nec.de>  < mailto:brunner@ccrle.nec.de <mailto:brunner@ccrle.nec.de> > ] 
Sent:   Wednesday, January 16, 2002 5:35 PM 
To:     Geib, Ruediger; dick.rr.knight@bt.com 
Cc:     nsis@ietf.org 
Subject:        RE: [NSIS] Two kinds of requirements 

Ruediger, 

The service needs to be defined anyway. Then there are IMO two 
possibilities 
- the provider defines the services and offers them. In this case the 
provider needs to describe the offers in a machine readable form (most 
likely with parameter names and values) 
- the consumer requests a particular service (this means the consumer has 
to describe the service he wants in a machine readable form) 

So it seams one has to move around service specifications which are 
understandable by the other party anyway, what is now your point? Is it 
that you want to limit/fix as many parameters as possible? Or are you more 
think about standardized services everybody understands? 

Marcus 

--On Wednesday, January 16, 2002 3:45 PM +0100 "Geib, Ruediger" 
<Ruediger.Geib@t-systems.com> wrote: 

> Hello Dick, 
> 
> your suggestion is quite reasonable. I also favour an architecture where 
> a QoS request by and large is predefined in terms of the resources 
> required from the available transport mechanism. Service specific 
> parameters to be signaled during reservation should be strictly limited. 
> The more mapping and evaluation of QoS parameters is required during 
> reservation, the more complex the service gets. Complex services are hard 
> to sell and hard to provide. 
> 
> Regards, 
> 
> R?diger 
> 
> R?diger Geib 
> Senior Project Manager 
> T-Systems Nova GmbH 
> 
>> I think that what is needed is a new protocol that can signal the 
>> requirements of any session and can be satisfied by any QoS 
>> mechanism, existing or new. 
>> To be more precise, I am suggesting a new protocol that is 
>> independent of the underlying transport technology and the QoS 
>> implemented and is also independent of the session control 
>> protocol. Such a new protocol would be generic, optionally 
>> implemented by applications that would benefit from 
>> end-to-end QoS, and would be complimentary to the QoS 
>> mechanisms deployed (and of course other mechanisms, 
>> such as the routing). 
>> 
>> I think that this implies a more abstract definition of the 
>> QoS mechanism and may lend itself to the signalling of 
>> pre-defined QoS classes rather than parameters. 
>> 
>> Dick Knight 



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



From daemon@optimus.ietf.org  Thu Jan 17 08: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 IAA13974
	for <nsis-archive@odin.ietf.org>; Thu, 17 Jan 2002 08:05:16 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id IAA00811
	for nsis-archive@odin.ietf.org; Thu, 17 Jan 2002 08:05: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 HAA29964;
	Thu, 17 Jan 2002 07:46: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 HAA29931
	for <nsis@optimus.ietf.org>; Thu, 17 Jan 2002 07:46:24 -0500 (EST)
Received: from mail-server.comgates.co.il ([212.150.198.2])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13461
	for <nsis@ietf.org>; Thu, 17 Jan 2002 07:46:18 -0500 (EST)
Received: by mail-server.comgates.co.il with Internet Mail Service (5.5.2653.19)
	id <DC2CZYDH>; Thu, 17 Jan 2002 14:46:43 +0200
Message-ID: <6FEF757325DBD411B7DA000629A8A61E7BAD41@mail-server.comgates.co.il>
From: Yaron Kahana <ykahana@comgates.co.il>
To: "'Georgios Karagiannis (ELN)'" <Georgios.Karagiannis@eln.ericsson.se>
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements
Date: Thu, 17 Jan 2002 14:46:42 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C19F55.03DC72A0"
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_01C19F55.03DC72A0
Content-Type: text/plain;
	charset="windows-1255"

Hi Georgios,

From what you are saying I understand that this toolkit request are "passing
through" any domain. Will it be the case over ATM/FR/IPv4/IPv6?

Best Regards
Yaron

-----Original Message-----
From: Georgios Karagiannis (ELN)
[mailto:Georgios.Karagiannis@eln.ericsson.se]
Sent: Thursday, January 17, 2002 2:35 PM
To: 'Yaron Kahana'
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements

Hi Yaron

Assuming that the domain in the middle supports over-provisioning the end
-to end QoS provisioning
could be satisfied.

Best Regards,
Georgios

-----Original Message-----
From: Yaron Kahana [mailto:ykahana@comgates.co.il]
Sent: donderdag 17 januari 2002 12:09
To: 'Georgios Karagiannis (ELN)'; Geib, Ruediger; 'Freytsis, Ilya'
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements



Hi,

I still don't see how such a toolkit can be useful if a certain domain in
the middle did not deployed a support in it and the Chicken and Egg
syndrome.

Yaron

-----Original Message-----
From: Georgios Karagiannis (ELN) [
mailto:Georgios.Karagiannis@eln.ericsson.se
<mailto:Georgios.Karagiannis@eln.ericsson.se> ]
Sent: Thursday, January 17, 2002 12:04 PM
To: 'Yaron Kahana'; Geib, Ruediger; 'Freytsis, Ilya'
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements

Hi Yaron, Ilya, Ruediger

Almost all issues that you addressed in your e-mails can be solved (see also
my previous e-mail
addressed to Dick) by first creating a modular QoS signaling toolkit that
will contain mandatory and
optional QoS requirements.
Second, specifying how the protocol functionality should be separated in
building blocks
(NSIS protocol components) and define a minimum set of mandatory reservation
options/features
that should be processed by any network nodes, e.g., end-hosts, proxies,
edges and interior nodes.

Best Regards,
Georgios

-----Original Message-----
From: Yaron Kahana [ mailto:ykahana@comgates.co.il
<mailto:ykahana@comgates.co.il> ]
Sent: woensdag 16 januari 2002 22:16
To: brunner@ccrle.nec.de; Geib, Ruediger; dick.rr.knight@bt.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements



Hello Ruediger, Marcus,

I agree with your comments. One of the crucial elements is th

We should try to keep it simple, even on the expense of full flexibility.

By the way - did anyone considered the problem of a non-cooperative IP
domain "in the middle" ? for example, Suppose I'm making a call from Los
Angeles to Munich through 3 domains - LA-NY, NY-London, London-Munich. What
will happen if the best/cheapest carrier along the NY-London domain won't
support this new protocol? Will he be condemned/ignored? When will he
upgrade his infrastructure, before the chicke

Yaron Kahana
COGITO Project Manager,
COMGATES

 -----Original Message-----
From:   Marcus Brunner [ mailto:brunner@ccrle.nec.de
<mailto:brunner@ccrle.nec.de>  < mailto:brunner@ccrle.nec.de
<mailto:brunner@ccrle.nec.de> > ]
Sent:   Wednesday, January 16, 2002 5:35 PM
To:     Geib, Ruediger; dick.rr.knight@bt.com
Cc:     nsis@ietf.org
Subject:        RE: [NSIS] Two kinds of requirements

Ruediger,

The service needs to be defined anyway. Then there are IMO two
possibilities
- the provider defines the services and offers them. In this case the
provider needs to describe the offers in a machine readable form (most
likely with parameter names and values)
- the consumer requests a particular service (this means the consumer has
to describe the service he wants in a machine readable form)

So it seams one has to move around service specifications which are
understandable by the other party anyway, what is now your point? Is it
that you want to limit/fix as many parameters as possible? Or are you more
think about standardized services everybody understands?

Marcus

--On Wednesday, January 16, 2002 3:45 PM +0100 "Geib, Ruediger"
<Ruediger.Geib@t-systems.com> wrote:

> Hello Dick,
>
> your suggestion is quite reasonable. I also favour an architecture where
> a QoS request by and large is predefined in terms of the resources
> required from the available transport mechanism. Service specific
> parameters to be signaled during reservation should be strictly limited.
> The more mapping and evaluation of QoS parameters is required during
> reservation, the more complex the service gets. Complex services are hard
> to sell and hard to provide.
>
> Regards,
>
> R?diger
>
> R?diger Geib
> Senior Project Manager
> T-Systems Nova GmbH
>
>> I think that what is needed is a new protocol that can signal the
>> requirements of any session and can be satisfied by any QoS
>> mechanism, existing or new.
>> To be more precise, I am suggesting a new protocol that is
>> independent of the underlying transport technology and the QoS
>> implemented and is also independent of the session control
>> protocol. Such a new protocol would be generic, optionally
>> implemented by applications that would benefit from
>> end-to-end QoS, and would be complimentary to the QoS
>> mechanisms deployed (and of course other mechanisms,
>> such as the routing).
>>
>> I think that this implies a more abstract definition of the
>> QoS mechanism and may lend itself to the signalling of
>> pre-defined QoS classes rather than parameters.
>>
>> Dick Knight

------_=_NextPart_001_01C19F55.03DC72A0
Content-Type: text/html;
	charset="windows-1255"
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=3Dwindows-1255">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>RE: [NSIS] Two kinds of requirements</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Hi Georgios,</FONT>
</P>

<P><FONT SIZE=3D2>From what you are saying I understand that this =
toolkit request are &quot;passing through&quot; any domain. Will it be =
the case over ATM/FR/IPv4/IPv6?</FONT></P>

<P><FONT SIZE=3D2>Best Regards</FONT>
<BR><FONT SIZE=3D2>Yaron</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Georgios Karagiannis (ELN) [<A =
HREF=3D"mailto:Georgios.Karagiannis@eln.ericsson.se">mailto:Georgios.Kar=
agiannis@eln.ericsson.se</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Thursday, January 17, 2002 2:35 PM</FONT>
<BR><FONT SIZE=3D2>To: 'Yaron Kahana'</FONT>
<BR><FONT SIZE=3D2>Cc: nsis@ietf.org</FONT>
<BR><FONT SIZE=3D2>Subject: RE: [NSIS] Two kinds of requirements</FONT>
</P>

<P><FONT SIZE=3D2>Hi Yaron</FONT>
</P>

<P><FONT SIZE=3D2>Assuming that the domain in the middle supports =
over-provisioning the end -to end QoS provisioning</FONT>
<BR><FONT SIZE=3D2>could be satisfied.</FONT>
</P>

<P><FONT SIZE=3D2>Best Regards,</FONT>
<BR><FONT SIZE=3D2>Georgios</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Yaron Kahana [<A =
HREF=3D"mailto:ykahana@comgates.co.il">mailto:ykahana@comgates.co.il</A>=
]</FONT>
<BR><FONT SIZE=3D2>Sent: donderdag 17 januari 2002 12:09</FONT>
<BR><FONT SIZE=3D2>To: 'Georgios Karagiannis (ELN)'; Geib, Ruediger; =
'Freytsis, Ilya'</FONT>
<BR><FONT SIZE=3D2>Cc: nsis@ietf.org</FONT>
<BR><FONT SIZE=3D2>Subject: RE: [NSIS] Two kinds of requirements</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>Hi,</FONT>
</P>

<P><FONT SIZE=3D2>I still don't see how such a toolkit can be useful if =
a certain domain in the middle did not deployed a support in it and the =
Chicken and Egg syndrome.</FONT></P>

<P><FONT SIZE=3D2>Yaron</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Georgios Karagiannis (ELN) [ <A =
HREF=3D"mailto:Georgios.Karagiannis@eln.ericsson.se">mailto:Georgios.Kar=
agiannis@eln.ericsson.se</A> &lt;<A =
HREF=3D"mailto:Georgios.Karagiannis@eln.ericsson.se">mailto:Georgios.Kar=
agiannis@eln.ericsson.se</A>&gt; ]</FONT></P>

<P><FONT SIZE=3D2>Sent: Thursday, January 17, 2002 12:04 PM</FONT>
<BR><FONT SIZE=3D2>To: 'Yaron Kahana'; Geib, Ruediger; 'Freytsis, =
Ilya'</FONT>
<BR><FONT SIZE=3D2>Cc: nsis@ietf.org</FONT>
<BR><FONT SIZE=3D2>Subject: RE: [NSIS] Two kinds of requirements</FONT>
</P>

<P><FONT SIZE=3D2>Hi Yaron, Ilya, Ruediger</FONT>
</P>

<P><FONT SIZE=3D2>Almost all issues that you addressed in your e-mails =
can be solved (see also my previous e-mail</FONT>
<BR><FONT SIZE=3D2>addressed to Dick) by first creating a modular QoS =
signaling toolkit that will contain mandatory and</FONT>
<BR><FONT SIZE=3D2>optional QoS requirements.</FONT>
<BR><FONT SIZE=3D2>Second, specifying how the protocol functionality =
should be separated in building blocks</FONT>
<BR><FONT SIZE=3D2>(NSIS protocol components) and define a minimum set =
of mandatory reservation options/features</FONT>
<BR><FONT SIZE=3D2>that should be processed by any network nodes, e.g., =
end-hosts, proxies, edges and interior nodes.</FONT>
</P>

<P><FONT SIZE=3D2>Best Regards,</FONT>
<BR><FONT SIZE=3D2>Georgios</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Yaron Kahana [ <A =
HREF=3D"mailto:ykahana@comgates.co.il">mailto:ykahana@comgates.co.il</A>=
 &lt;<A =
HREF=3D"mailto:ykahana@comgates.co.il">mailto:ykahana@comgates.co.il</A>=
&gt; ]</FONT>
<BR><FONT SIZE=3D2>Sent: woensdag 16 januari 2002 22:16</FONT>
<BR><FONT SIZE=3D2>To: brunner@ccrle.nec.de; Geib, Ruediger; =
dick.rr.knight@bt.com</FONT>
<BR><FONT SIZE=3D2>Cc: nsis@ietf.org</FONT>
<BR><FONT SIZE=3D2>Subject: RE: [NSIS] Two kinds of requirements</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>Hello Ruediger, Marcus,</FONT>
</P>

<P><FONT SIZE=3D2>I agree with your comments. One of the crucial =
elements is th</FONT>
</P>

<P><FONT SIZE=3D2>We should try to keep it simple, even on the expense =
of full flexibility.</FONT>
</P>

<P><FONT SIZE=3D2>By the way - did anyone considered the problem of a =
non-cooperative IP domain &quot;in the middle&quot; ? for example, =
Suppose I'm making a call from Los Angeles to Munich through 3 domains =
- LA-NY, NY-London, London-Munich. What will happen if the =
best/cheapest carrier along the NY-London domain won't support this new =
protocol? Will he be condemned/ignored? When will he upgrade his =
infrastructure, before the chicke</FONT></P>

<P><FONT SIZE=3D2>Yaron Kahana</FONT>
<BR><FONT SIZE=3D2>COGITO Project Manager,</FONT>
<BR><FONT SIZE=3D2>COMGATES</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From:&nbsp;&nbsp; Marcus Brunner [ <A =
HREF=3D"mailto:brunner@ccrle.nec.de">mailto:brunner@ccrle.nec.de</A> =
&lt;<A =
HREF=3D"mailto:brunner@ccrle.nec.de">mailto:brunner@ccrle.nec.de</A>&gt;=
&nbsp; &lt; <A =
HREF=3D"mailto:brunner@ccrle.nec.de">mailto:brunner@ccrle.nec.de</A> =
&lt;<A =
HREF=3D"mailto:brunner@ccrle.nec.de">mailto:brunner@ccrle.nec.de</A>&gt;=
 &gt; ]</FONT></P>

<P><FONT SIZE=3D2>Sent:&nbsp;&nbsp; Wednesday, January 16, 2002 5:35 =
PM</FONT>
<BR><FONT SIZE=3D2>To:&nbsp;&nbsp;&nbsp;&nbsp; Geib, Ruediger; =
dick.rr.knight@bt.com</FONT>
<BR><FONT SIZE=3D2>Cc:&nbsp;&nbsp;&nbsp;&nbsp; nsis@ietf.org</FONT>
<BR><FONT SIZE=3D2>Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
RE: [NSIS] Two kinds of requirements</FONT>
</P>

<P><FONT SIZE=3D2>Ruediger,</FONT>
</P>

<P><FONT SIZE=3D2>The service needs to be defined anyway. Then there =
are IMO two</FONT>
<BR><FONT SIZE=3D2>possibilities</FONT>
<BR><FONT SIZE=3D2>- the provider defines the services and offers them. =
In this case the</FONT>
<BR><FONT SIZE=3D2>provider needs to describe the offers in a machine =
readable form (most</FONT>
<BR><FONT SIZE=3D2>likely with parameter names and values)</FONT>
<BR><FONT SIZE=3D2>- the consumer requests a particular service (this =
means the consumer has</FONT>
<BR><FONT SIZE=3D2>to describe the service he wants in a machine =
readable form)</FONT>
</P>

<P><FONT SIZE=3D2>So it seams one has to move around service =
specifications which are</FONT>
<BR><FONT SIZE=3D2>understandable by the other party anyway, what is =
now your point? Is it</FONT>
<BR><FONT SIZE=3D2>that you want to limit/fix as many parameters as =
possible? Or are you more</FONT>
<BR><FONT SIZE=3D2>think about standardized services everybody =
understands?</FONT>
</P>

<P><FONT SIZE=3D2>Marcus</FONT>
</P>

<P><FONT SIZE=3D2>--On Wednesday, January 16, 2002 3:45 PM +0100 =
&quot;Geib, Ruediger&quot;</FONT>
<BR><FONT SIZE=3D2>&lt;Ruediger.Geib@t-systems.com&gt; wrote:</FONT>
</P>

<P><FONT SIZE=3D2>&gt; Hello Dick,</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; your suggestion is quite reasonable. I also =
favour an architecture where</FONT>
<BR><FONT SIZE=3D2>&gt; a QoS request by and large is predefined in =
terms of the resources</FONT>
<BR><FONT SIZE=3D2>&gt; required from the available transport =
mechanism. Service specific</FONT>
<BR><FONT SIZE=3D2>&gt; parameters to be signaled during reservation =
should be strictly limited.</FONT>
<BR><FONT SIZE=3D2>&gt; The more mapping and evaluation of QoS =
parameters is required during</FONT>
<BR><FONT SIZE=3D2>&gt; reservation, the more complex the service gets. =
Complex services are hard</FONT>
<BR><FONT SIZE=3D2>&gt; to sell and hard to provide.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; Regards,</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; R?diger</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; R?diger Geib</FONT>
<BR><FONT SIZE=3D2>&gt; Senior Project Manager</FONT>
<BR><FONT SIZE=3D2>&gt; T-Systems Nova GmbH</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; I think that what is needed is a new =
protocol that can signal the</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; requirements of any session and can be =
satisfied by any QoS</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; mechanism, existing or new.</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; To be more precise, I am suggesting a new =
protocol that is</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; independent of the underlying transport =
technology and the QoS</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; implemented and is also independent of the =
session control</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; protocol. Such a new protocol would be =
generic, optionally</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; implemented by applications that would =
benefit from</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; end-to-end QoS, and would be complimentary =
to the QoS</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; mechanisms deployed (and of course other =
mechanisms,</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; such as the routing).</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; I think that this implies a more abstract =
definition of the</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; QoS mechanism and may lend itself to the =
signalling of</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; pre-defined QoS classes rather than =
parameters.</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; Dick Knight</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C19F55.03DC72A0--

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



From daemon@optimus.ietf.org  Thu Jan 17 08:05: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 IAA13990
	for <nsis-archive@odin.ietf.org>; Thu, 17 Jan 2002 08:05:23 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id IAA00825
	for nsis-archive@odin.ietf.org; Thu, 17 Jan 2002 08:05:26 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA00075;
	Thu, 17 Jan 2002 07:52:42 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA00044
	for <nsis@optimus.ietf.org>; Thu, 17 Jan 2002 07:52:40 -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 HAA13610
	for <nsis@ietf.org>; Thu, 17 Jan 2002 07:52: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 NAA12133;
	Thu, 17 Jan 2002 13:52:31 +0100 (MET)
Received: from mchh247e.demchh201e.icn.siemens.de ([139.21.200.57])
	by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id NAA22872;
	Thu, 17 Jan 2002 13:52:30 +0100 (MET)
Received: by MCHH247E with Internet Mail Service (5.5.2653.19)
	id <XD3ZXQRA>; Thu, 17 Jan 2002 13:52:27 +0100
Message-ID: <4D486782CA36D4118A530000D11EA42A012654C3@blns204e.bln.icn.siemens.de>
From: Kappler Cornelia <Cornelia.Kappler@icn.siemens.de>
To: "'Loughney John (NRC/Helsinki)'" <john.loughney@nokia.com>,
        "'ext Georgios Karagiannis (ELN)'" <Georgios.Karagiannis@eln.ericsson.se>
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements
Date: Thu, 17 Jan 2002 13:52:08 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: nsis-admin@ietf.org
Errors-To: nsis-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Next Steps in Signaling <nsis.ietf.org>
X-BeenThere: nsis@ietf.org

Hi John, Georgios,

to my understanding the very idea of the modular / toolkit approach is providing basic "MUST" functionality, but at the same time _leaving open_ the possiblity of later adding "MAY" functionality. 

This means we should try designing the protocol such that later "MAY" functionality can be added in a modular fashion. 

Cornelia

> -----Original Message-----
> From:	Loughney John (NRC/Helsinki) [SMTP:john.loughney@nokia.com]
> Sent:	Thursday, January 17, 2002 1:45 PM
> To:	'ext Georgios Karagiannis (ELN)'
> Cc:	nsis@ietf.org
> Subject:	RE: [NSIS] Two kinds of requirements
> 
> Hi Georgios,
> 
> > By mandatory, I mean, requirements that MUST be supported 
> > (used) by a node and optional are requirements that 
> > MAY be supported by a node!
> 
> If it is optional, then it is not required.
> 
> John
> 
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis

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



From daemon@optimus.ietf.org  Thu Jan 17 08:06: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 IAA14035
	for <nsis-archive@odin.ietf.org>; Thu, 17 Jan 2002 08:06:55 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id IAA00895
	for nsis-archive@odin.ietf.org; Thu, 17 Jan 2002 08:06: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 IAA00869;
	Thu, 17 Jan 2002 08:05: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 IAA00838
	for <nsis@optimus.ietf.org>; Thu, 17 Jan 2002 08:05:50 -0500 (EST)
Received: from mail-server.comgates.co.il ([212.150.198.2])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14002
	for <nsis@ietf.org>; Thu, 17 Jan 2002 08:05:45 -0500 (EST)
Received: by mail-server.comgates.co.il with Internet Mail Service (5.5.2653.19)
	id <DC2CZYD6>; Thu, 17 Jan 2002 15:06:12 +0200
Message-ID: <6FEF757325DBD411B7DA000629A8A61E7BAD43@mail-server.comgates.co.il>
From: Yaron Kahana <ykahana@comgates.co.il>
To: "'Georgios Karagiannis (ELN)'" <Georgios.Karagiannis@eln.ericsson.se>
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements
Date: Thu, 17 Jan 2002 15:06:11 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C19F57.BC78D090"
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_01C19F57.BC78D090
Content-Type: text/plain;
	charset="windows-1255"

Hi,

Great. This however leads to the question of QoS metrics budgeting (like
what should be the required delay in domain A, B, and C, when B is not
supporting/processing the QoS signalling request).

Yaron
 .

-----Original Message-----
From: Georgios Karagiannis (ELN)
[mailto:Georgios.Karagiannis@eln.ericsson.se]
Sent: Thursday, January 17, 2002 3:00 PM
To: 'Yaron Kahana'
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements

Hi Yaron

The toolkit is a method of specifying which QoS requirements will impact
a certain node in an IP based network, not in an ATM or other kind of
networks.
If an IP domain supports overprovisioning then it would probably be useless
to process (check and use) the (future)  NSIS protocol within this domain.
I think that it should be allowed that nodes bypass (without checking and
using)
the NSIS protocol messages if required.

Best Regards,
Georgios




-----Original Message-----
From: Yaron Kahana [mailto:ykahana@comgates.co.il]
Sent: donderdag 17 januari 2002 13:47
To: 'Georgios Karagiannis (ELN)'
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements



Hi Georgios,

From what you are saying I understand that this toolkit request are "passing
through" any domain. Will it be the case over ATM/FR/IPv4/IPv6?

Best Regards
Yaron

-----Original Message-----
From: Georgios Karagiannis (ELN) [
mailto:Georgios.Karagiannis@eln.ericsson.se
<mailto:Georgios.Karagiannis@eln.ericsson.se> ]
Sent: Thursday, January 17, 2002 2:35 PM
To: 'Yaron Kahana'
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements

Hi Yaron

Assuming that the domain in the middle supports over-provisioning the end
-to end QoS provisioning
could be satisfied.

Best Regards,
Georgios

-----Original Message-----
From: Yaro mailto:ykahana@comgates.co.il <mailto:ykahana@comgates.co.il> ]
Sent: donderdag 17 januari 2002 12:09
To: 'Georgios Karagiannis (ELN)'; Geib, Ruediger; 'Freytsis, Ilya'
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements



Hi,

I still don't see how such a toolkit can be useful if a certain domain in
the middle did not deployed a support in it and the Chicken and Egg
syndrome.

Yaron

-----Original Message-----
From: Georgios Karagiannis (ELN) [
mailto:Georgios.Karagiannis@eln.ericsson.se
<mailto:Georgios.Karagiannis@eln.ericsson.se>  <
mailto:Georgios.Karagiannis@eln.ericsson.se
<mailto:Georgios.Karagiannis@eln.ericsson.se> > ]

Sent: Thursday, January 17, 2002 12:04 PM
To: 'Yaron Kahana'; Geib, Ruediger; 'Freytsis, Ilya'
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements

Hi Yaron, Ilya, Ruediger

Almost all issues that you addressed in your e-mails can be solved (see also
my previous e-mail
addressed to Dick) by first creating a modular QoS signaling toolkit that
will contain mandatory and
optional QoS requirements.
Second, specifying how the protocol functionality should be separated in
building blocks
(NSIS protocol components) and define a minimum set of mandatory reservation
options/features
that should be processed by any network nodes, e.g., end-hosts, proxies,
edges and interior nodes.

Best Regards,
Georgios

-----Original Message-----
From: Yaron Kahana [ mailto:ykahana@comgates.co.il
<mailto:ykahana@comgates.co.il>  < mailto:ykahana@comgates.co.il
<mailto:ykahana@comgates.co.il> > ]
Sent: woensdag 16 januari 2002 22:16
To: brunner@ccrle.nec.de; Geib, Ruediger; dick.rr.knight@bt.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements



Hello Ruediger, Marcus,

I agree with your comments. One of the crucial elements is th

We should try to keep it simple, even on the expense of full flexibility.

By the way - did anyone considered the problem of a non-cooperative IP
domain "in the middle" ? for example, Suppose I'm making a call from Los
Angeles to Munich through 3 domains - LA-NY, NY-London, London-Munich. What
will happen if the best/cheapest carrier along the NY-London domain won't
support this new protocol? Will he be condemned/ignored? When will he
upgrade his infrastructure, before the chicke

Yaron Kahana
COGITO Project Manager,
COMGATES

 -----Original Message-----
From:   Marcus Brunner [ mailto:brunner@ccrle.nec.de
<mailto:brunner@ccrle.nec.de>  < mailto:brunner@ccrle.nec.de
<mailto:brunner@ccrle.nec.de> >  < mailto:brunner@ccrle.nec.de
<mailto:brunner@ccrle.nec.de>  < mailto:brunner@ccrle.nec.de
<mailto:brunner@ccrle.nec.de> > > ]

Sent:   Wednesday, January 16, 2002 5:35 PM
To:     Geib, Ruediger; dick.rr.knight@bt.com
Cc:     nsis@ietf.org
Subject:        RE: [NSIS] Two kinds of requirements

Ruediger,

The service needs to be defined anyway. Then there are IMO two
possibilities
- the provider defines the services and offers them. In this case the
provider needs to describe the offers in a machine readable form (most
likely with parameter names and values)
- the consumer requests a particular service (this means the consumer has
to describe the service he wants in a machine readable form)

So it seams one has to move around service specifications which are
understandable by the other party anyway, what is now your point? Is it
that you want to limit/fix as many parameters as possible? Or are you more
think about standardized services everybody understands?

Marcus

--On Wednesday, January 16, 2002 3:45 PM +0100 "Geib, Ruediger"
<Ruediger.Geib@t-systems.com> wrote:

> Hello Dick,
>
> your suggestion is quite reasonable. I also favour an architecture where
> a QoS request by and large is predefined in terms of the resources
> required from the available transport mechanism. Service specific
> parameters to be signaled during reservation should be strictly limited.
> The more mapping and evaluation of QoS parameters is required during
> reservation, the more complex the service gets. Complex services are hard
> to sell and hard to provide.
>
> Regards,
>
> R?diger
>
> R?diger Geib
> Senior Project Manager
> T-Systems Nova GmbH
>
>> I think that what is needed is a new protocol that can signal the

------_=_NextPart_001_01C19F57.BC78D090
Content-Type: text/html;
	charset="windows-1255"
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=3Dwindows-1255">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>RE: [NSIS] Two kinds of requirements</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Hi,</FONT>
</P>

<P><FONT SIZE=3D2>Great. This however leads to the question of QoS =
metrics budgeting (like what should be the required delay in domain A, =
B, and C, when B is not supporting/processing the QoS signalling =
request).</FONT></P>

<P><FONT SIZE=3D2>Yaron</FONT>
<BR><FONT SIZE=3D2>.</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Georgios Karagiannis (ELN) [<A =
HREF=3D"mailto:Georgios.Karagiannis@eln.ericsson.se">mailto:Georgios.Kar=
agiannis@eln.ericsson.se</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Thursday, January 17, 2002 3:00 PM</FONT>
<BR><FONT SIZE=3D2>To: 'Yaron Kahana'</FONT>
<BR><FONT SIZE=3D2>Cc: nsis@ietf.org</FONT>
<BR><FONT SIZE=3D2>Subject: RE: [NSIS] Two kinds of requirements</FONT>
</P>

<P><FONT SIZE=3D2>Hi Yaron</FONT>
</P>

<P><FONT SIZE=3D2>The toolkit is a method of specifying which QoS =
requirements will impact</FONT>
<BR><FONT SIZE=3D2>a certain node in an IP based network, not in an ATM =
or other kind of networks.</FONT>
<BR><FONT SIZE=3D2>If an IP domain supports overprovisioning then it =
would probably be useless</FONT>
<BR><FONT SIZE=3D2>to process (check and use) the (future)&nbsp; NSIS =
protocol within this domain.</FONT>
<BR><FONT SIZE=3D2>I think that it should be allowed that nodes bypass =
(without checking and using)</FONT>
<BR><FONT SIZE=3D2>the NSIS protocol messages if required.</FONT>
</P>

<P><FONT SIZE=3D2>Best Regards,</FONT>
<BR><FONT SIZE=3D2>Georgios</FONT>
</P>
<BR>
<BR>
<BR>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Yaron Kahana [<A =
HREF=3D"mailto:ykahana@comgates.co.il">mailto:ykahana@comgates.co.il</A>=
]</FONT>
<BR><FONT SIZE=3D2>Sent: donderdag 17 januari 2002 13:47</FONT>
<BR><FONT SIZE=3D2>To: 'Georgios Karagiannis (ELN)'</FONT>
<BR><FONT SIZE=3D2>Cc: nsis@ietf.org</FONT>
<BR><FONT SIZE=3D2>Subject: RE: [NSIS] Two kinds of requirements</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>Hi Georgios,</FONT>
</P>

<P><FONT SIZE=3D2>From what you are saying I understand that this =
toolkit request are &quot;passing through&quot; any domain. Will it be =
the case over ATM/FR/IPv4/IPv6?</FONT></P>

<P><FONT SIZE=3D2>Best Regards</FONT>
<BR><FONT SIZE=3D2>Yaron</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Georgios Karagiannis (ELN) [ <A =
HREF=3D"mailto:Georgios.Karagiannis@eln.ericsson.se">mailto:Georgios.Kar=
agiannis@eln.ericsson.se</A> &lt;<A =
HREF=3D"mailto:Georgios.Karagiannis@eln.ericsson.se">mailto:Georgios.Kar=
agiannis@eln.ericsson.se</A>&gt; ]</FONT></P>

<P><FONT SIZE=3D2>Sent: Thursday, January 17, 2002 2:35 PM</FONT>
<BR><FONT SIZE=3D2>To: 'Yaron Kahana'</FONT>
<BR><FONT SIZE=3D2>Cc: nsis@ietf.org</FONT>
<BR><FONT SIZE=3D2>Subject: RE: [NSIS] Two kinds of requirements</FONT>
</P>

<P><FONT SIZE=3D2>Hi Yaron</FONT>
</P>

<P><FONT SIZE=3D2>Assuming that the domain in the middle supports =
over-provisioning the end -to end QoS provisioning</FONT>
<BR><FONT SIZE=3D2>could be satisfied.</FONT>
</P>

<P><FONT SIZE=3D2>Best Regards,</FONT>
<BR><FONT SIZE=3D2>Georgios</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Yaro <A =
HREF=3D"mailto:ykahana@comgates.co.il">mailto:ykahana@comgates.co.il</A>=
 &lt;<A =
HREF=3D"mailto:ykahana@comgates.co.il">mailto:ykahana@comgates.co.il</A>=
&gt; ]</FONT>
<BR><FONT SIZE=3D2>Sent: donderdag 17 januari 2002 12:09</FONT>
<BR><FONT SIZE=3D2>To: 'Georgios Karagiannis (ELN)'; Geib, Ruediger; =
'Freytsis, Ilya'</FONT>
<BR><FONT SIZE=3D2>Cc: nsis@ietf.org</FONT>
<BR><FONT SIZE=3D2>Subject: RE: [NSIS] Two kinds of requirements</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>Hi,</FONT>
</P>

<P><FONT SIZE=3D2>I still don't see how such a toolkit can be useful if =
a certain domain in the middle did not deployed a support in it and the =
Chicken and Egg syndrome.</FONT></P>

<P><FONT SIZE=3D2>Yaron</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Georgios Karagiannis (ELN) [ <A =
HREF=3D"mailto:Georgios.Karagiannis@eln.ericsson.se">mailto:Georgios.Kar=
agiannis@eln.ericsson.se</A> &lt;<A =
HREF=3D"mailto:Georgios.Karagiannis@eln.ericsson.se">mailto:Georgios.Kar=
agiannis@eln.ericsson.se</A>&gt;&nbsp; &lt; <A =
HREF=3D"mailto:Georgios.Karagiannis@eln.ericsson.se">mailto:Georgios.Kar=
agiannis@eln.ericsson.se</A> &lt;<A =
HREF=3D"mailto:Georgios.Karagiannis@eln.ericsson.se">mailto:Georgios.Kar=
agiannis@eln.ericsson.se</A>&gt; &gt; ]</FONT></P>

<P><FONT SIZE=3D2>Sent: Thursday, January 17, 2002 12:04 PM</FONT>
<BR><FONT SIZE=3D2>To: 'Yaron Kahana'; Geib, Ruediger; 'Freytsis, =
Ilya'</FONT>
<BR><FONT SIZE=3D2>Cc: nsis@ietf.org</FONT>
<BR><FONT SIZE=3D2>Subject: RE: [NSIS] Two kinds of requirements</FONT>
</P>

<P><FONT SIZE=3D2>Hi Yaron, Ilya, Ruediger</FONT>
</P>

<P><FONT SIZE=3D2>Almost all issues that you addressed in your e-mails =
can be solved (see also my previous e-mail</FONT>
<BR><FONT SIZE=3D2>addressed to Dick) by first creating a modular QoS =
signaling toolkit that will contain mandatory and</FONT>
<BR><FONT SIZE=3D2>optional QoS requirements.</FONT>
<BR><FONT SIZE=3D2>Second, specifying how the protocol functionality =
should be separated in building blocks</FONT>
<BR><FONT SIZE=3D2>(NSIS protocol components) and define a minimum set =
of mandatory reservation options/features</FONT>
<BR><FONT SIZE=3D2>that should be processed by any network nodes, e.g., =
end-hosts, proxies, edges and interior nodes.</FONT>
</P>

<P><FONT SIZE=3D2>Best Regards,</FONT>
<BR><FONT SIZE=3D2>Georgios</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Yaron Kahana [ <A =
HREF=3D"mailto:ykahana@comgates.co.il">mailto:ykahana@comgates.co.il</A>=
 &lt;<A =
HREF=3D"mailto:ykahana@comgates.co.il">mailto:ykahana@comgates.co.il</A>=
&gt;&nbsp; &lt; <A =
HREF=3D"mailto:ykahana@comgates.co.il">mailto:ykahana@comgates.co.il</A>=
 &lt;<A =
HREF=3D"mailto:ykahana@comgates.co.il">mailto:ykahana@comgates.co.il</A>=
&gt; &gt; ]</FONT></P>

<P><FONT SIZE=3D2>Sent: woensdag 16 januari 2002 22:16</FONT>
<BR><FONT SIZE=3D2>To: brunner@ccrle.nec.de; Geib, Ruediger; =
dick.rr.knight@bt.com</FONT>
<BR><FONT SIZE=3D2>Cc: nsis@ietf.org</FONT>
<BR><FONT SIZE=3D2>Subject: RE: [NSIS] Two kinds of requirements</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>Hello Ruediger, Marcus,</FONT>
</P>

<P><FONT SIZE=3D2>I agree with your comments. One of the crucial =
elements is th</FONT>
</P>

<P><FONT SIZE=3D2>We should try to keep it simple, even on the expense =
of full flexibility.</FONT>
</P>

<P><FONT SIZE=3D2>By the way - did anyone considered the problem of a =
non-cooperative IP domain &quot;in the middle&quot; ? for example, =
Suppose I'm making a call from Los Angeles to Munich through 3 domains =
- LA-NY, NY-London, London-Munich. What will happen if the =
best/cheapest carrier along the NY-London domain won't support this new =
protocol? Will he be condemned/ignored? When will he upgrade his =
infrastructure, before the chicke</FONT></P>

<P><FONT SIZE=3D2>Yaron Kahana</FONT>
<BR><FONT SIZE=3D2>COGITO Project Manager,</FONT>
<BR><FONT SIZE=3D2>COMGATES</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From:&nbsp;&nbsp; Marcus Brunner [ <A =
HREF=3D"mailto:brunner@ccrle.nec.de">mailto:brunner@ccrle.nec.de</A> =
&lt;<A =
HREF=3D"mailto:brunner@ccrle.nec.de">mailto:brunner@ccrle.nec.de</A>&gt;=
&nbsp; &lt; <A =
HREF=3D"mailto:brunner@ccrle.nec.de">mailto:brunner@ccrle.nec.de</A> =
&lt;<A =
HREF=3D"mailto:brunner@ccrle.nec.de">mailto:brunner@ccrle.nec.de</A>&gt;=
 &gt;&nbsp; &lt; <A =
HREF=3D"mailto:brunner@ccrle.nec.de">mailto:brunner@ccrle.nec.de</A> =
&lt;<A HREF=3D"mailto:brunner@ccrle.nec.de">mailto:brunner@ccrle.nec.de<=
/A>&gt;&nbsp; &lt; <A =
HREF=3D"mailto:brunner@ccrle.nec.de">mailto:brunner@ccrle.nec.de</A> =
&lt;<A =
HREF=3D"mailto:brunner@ccrle.nec.de">mailto:brunner@ccrle.nec.de</A>&gt;=
 &gt; &gt; ]</FONT></P>

<P><FONT SIZE=3D2>Sent:&nbsp;&nbsp; Wednesday, January 16, 2002 5:35 =
PM</FONT>
<BR><FONT SIZE=3D2>To:&nbsp;&nbsp;&nbsp;&nbsp; Geib, Ruediger; =
dick.rr.knight@bt.com</FONT>
<BR><FONT SIZE=3D2>Cc:&nbsp;&nbsp;&nbsp;&nbsp; nsis@ietf.org</FONT>
<BR><FONT SIZE=3D2>Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
RE: [NSIS] Two kinds of requirements</FONT>
</P>

<P><FONT SIZE=3D2>Ruediger,</FONT>
</P>

<P><FONT SIZE=3D2>The service needs to be defined anyway. Then there =
are IMO two</FONT>
<BR><FONT SIZE=3D2>possibilities</FONT>
<BR><FONT SIZE=3D2>- the provider defines the services and offers them. =
In this case the</FONT>
<BR><FONT SIZE=3D2>provider needs to describe the offers in a machine =
readable form (most</FONT>
<BR><FONT SIZE=3D2>likely with parameter names and values)</FONT>
<BR><FONT SIZE=3D2>- the consumer requests a particular service (this =
means the consumer has</FONT>
<BR><FONT SIZE=3D2>to describe the service he wants in a machine =
readable form)</FONT>
</P>

<P><FONT SIZE=3D2>So it seams one has to move around service =
specifications which are</FONT>
<BR><FONT SIZE=3D2>understandable by the other party anyway, what is =
now your point? Is it</FONT>
<BR><FONT SIZE=3D2>that you want to limit/fix as many parameters as =
possible? Or are you more</FONT>
<BR><FONT SIZE=3D2>think about standardized services everybody =
understands?</FONT>
</P>

<P><FONT SIZE=3D2>Marcus</FONT>
</P>

<P><FONT SIZE=3D2>--On Wednesday, January 16, 2002 3:45 PM +0100 =
&quot;Geib, Ruediger&quot;</FONT>
<BR><FONT SIZE=3D2>&lt;Ruediger.Geib@t-systems.com&gt; wrote:</FONT>
</P>

<P><FONT SIZE=3D2>&gt; Hello Dick,</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; your suggestion is quite reasonable. I also =
favour an architecture where</FONT>
<BR><FONT SIZE=3D2>&gt; a QoS request by and large is predefined in =
terms of the resources</FONT>
<BR><FONT SIZE=3D2>&gt; required from the available transport =
mechanism. Service specific</FONT>
<BR><FONT SIZE=3D2>&gt; parameters to be signaled during reservation =
should be strictly limited.</FONT>
<BR><FONT SIZE=3D2>&gt; The more mapping and evaluation of QoS =
parameters is required during</FONT>
<BR><FONT SIZE=3D2>&gt; reservation, the more complex the service gets. =
Complex services are hard</FONT>
<BR><FONT SIZE=3D2>&gt; to sell and hard to provide.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; Regards,</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; R?diger</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; R?diger Geib</FONT>
<BR><FONT SIZE=3D2>&gt; Senior Project Manager</FONT>
<BR><FONT SIZE=3D2>&gt; T-Systems Nova GmbH</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; I think that what is needed is a new =
protocol that can signal the</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C19F57.BC78D090--

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



From daemon@optimus.ietf.org  Thu Jan 17 08:09:26 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14073
	for <nsis-archive@odin.ietf.org>; Thu, 17 Jan 2002 08:09:26 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id IAA00925
	for nsis-archive@odin.ietf.org; Thu, 17 Jan 2002 08:09: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 HAA00297;
	Thu, 17 Jan 2002 07:59: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 HAA00239
	for <nsis@optimus.ietf.org>; Thu, 17 Jan 2002 07:59:44 -0500 (EST)
Received: from albatross-ext.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 HAA13787
	for <nsis@ietf.org>; Thu, 17 Jan 2002 07:59:41 -0500 (EST)
Received: from esealnt409.al.sw.ericsson.se (ESEALNT409.al.sw.ericsson.se [153.88.251.32])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g0HCxfJ15073
	for <nsis@ietf.org>; Thu, 17 Jan 2002 13:59:41 +0100 (MET)
Received: FROM esealnt746.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Thu Jan 17 13:59:41 2002 +0100
Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <YHLJLHXS>; Thu, 17 Jan 2002 13:59:40 +0100
Message-ID: <E244E44D6AB85E40AEEF7EAABE3545FA82336A@enleent104.nl.eu.ericsson.se>
From: "Georgios Karagiannis (ELN)" <Georgios.Karagiannis@eln.ericsson.se>
To: "'Yaron Kahana'" <ykahana@comgates.co.il>
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements
Date: Thu, 17 Jan 2002 13:59:37 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="windows-1255"
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 Yaron
 
The toolkit is a method of specifying which QoS requirements will impact 
a certain node in an IP based network, not in an ATM or other kind of networks.
If an IP domain supports overprovisioning then it would probably be useless 
to process (check and use) the (future)  NSIS protocol within this domain.
I think that it should be allowed that nodes bypass (without checking and using) 
the NSIS protocol messages if required.
 
Best Regards,
Georgios
 
 
 

-----Original Message-----
From: Yaron Kahana [mailto:ykahana@comgates.co.il]
Sent: donderdag 17 januari 2002 13:47
To: 'Georgios Karagiannis (ELN)'
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements



Hi Georgios, 

From what you are saying I understand that this toolkit request are "passing through" any domain. Will it be the case over ATM/FR/IPv4/IPv6?

Best Regards 
Yaron 

-----Original Message----- 
From: Georgios Karagiannis (ELN) [ mailto:Georgios.Karagiannis@eln.ericsson.se <mailto:Georgios.Karagiannis@eln.ericsson.se> ] 
Sent: Thursday, January 17, 2002 2:35 PM 
To: 'Yaron Kahana' 
Cc: nsis@ietf.org 
Subject: RE: [NSIS] Two kinds of requirements 

Hi Yaron 

Assuming that the domain in the middle supports over-provisioning the end -to end QoS provisioning 
could be satisfied. 

Best Regards, 
Georgios 

-----Original Message----- 
From: Yaro mailto:ykahana@comgates.co.il <mailto:ykahana@comgates.co.il> ] 
Sent: donderdag 17 januari 2002 12:09 
To: 'Georgios Karagiannis (ELN)'; Geib, Ruediger; 'Freytsis, Ilya' 
Cc: nsis@ietf.org 
Subject: RE: [NSIS] Two kinds of requirements 



Hi, 

I still don't see how such a toolkit can be useful if a certain domain in the middle did not deployed a support in it and the Chicken and Egg syndrome.

Yaron 

-----Original Message----- 
From: Georgios Karagiannis (ELN) [ mailto:Georgios.Karagiannis@eln.ericsson.se <mailto:Georgios.Karagiannis@eln.ericsson.se>  < mailto:Georgios.Karagiannis@eln.ericsson.se <mailto:Georgios.Karagiannis@eln.ericsson.se> > ]

Sent: Thursday, January 17, 2002 12:04 PM 
To: 'Yaron Kahana'; Geib, Ruediger; 'Freytsis, Ilya' 
Cc: nsis@ietf.org 
Subject: RE: [NSIS] Two kinds of requirements 

Hi Yaron, Ilya, Ruediger 

Almost all issues that you addressed in your e-mails can be solved (see also my previous e-mail 
addressed to Dick) by first creating a modular QoS signaling toolkit that will contain mandatory and 
optional QoS requirements. 
Second, specifying how the protocol functionality should be separated in building blocks 
(NSIS protocol components) and define a minimum set of mandatory reservation options/features 
that should be processed by any network nodes, e.g., end-hosts, proxies, edges and interior nodes. 

Best Regards, 
Georgios 

-----Original Message----- 
From: Yaron Kahana [ mailto:ykahana@comgates.co.il <mailto:ykahana@comgates.co.il>  < mailto:ykahana@comgates.co.il <mailto:ykahana@comgates.co.il> > ] 
Sent: woensdag 16 januari 2002 22:16 
To: brunner@ccrle.nec.de; Geib, Ruediger; dick.rr.knight@bt.com 
Cc: nsis@ietf.org 
Subject: RE: [NSIS] Two kinds of requirements 



Hello Ruediger, Marcus, 

I agree with your comments. One of the crucial elements is th 

We should try to keep it simple, even on the expense of full flexibility. 

By the way - did anyone considered the problem of a non-cooperative IP domain "in the middle" ? for example, Suppose I'm making a call from Los Angeles to Munich through 3 domains - LA-NY, NY-London, London-Munich. What will happen if the best/cheapest carrier along the NY-London domain won't support this new protocol? Will he be condemned/ignored? When will he upgrade his infrastructure, before the chicke

Yaron Kahana 
COGITO Project Manager, 
COMGATES 

 -----Original Message----- 
From:   Marcus Brunner [ mailto:brunner@ccrle.nec.de <mailto:brunner@ccrle.nec.de>  < mailto:brunner@ccrle.nec.de <mailto:brunner@ccrle.nec.de> >  < mailto:brunner@ccrle.nec.de <mailto:brunner@ccrle.nec.de>  < mailto:brunner@ccrle.nec.de <mailto:brunner@ccrle.nec.de> > > ]

Sent:   Wednesday, January 16, 2002 5:35 PM 
To:     Geib, Ruediger; dick.rr.knight@bt.com 
Cc:     nsis@ietf.org 
Subject:        RE: [NSIS] Two kinds of requirements 

Ruediger, 

The service needs to be defined anyway. Then there are IMO two 
possibilities 
- the provider defines the services and offers them. In this case the 
provider needs to describe the offers in a machine readable form (most 
likely with parameter names and values) 
- the consumer requests a particular service (this means the consumer has 
to describe the service he wants in a machine readable form) 

So it seams one has to move around service specifications which are 
understandable by the other party anyway, what is now your point? Is it 
that you want to limit/fix as many parameters as possible? Or are you more 
think about standardized services everybody understands? 

Marcus 

--On Wednesday, January 16, 2002 3:45 PM +0100 "Geib, Ruediger" 
<Ruediger.Geib@t-systems.com> wrote: 

> Hello Dick, 
> 
> your suggestion is quite reasonable. I also favour an architecture where 
> a QoS request by and large is predefined in terms of the resources 
> required from the available transport mechanism. Service specific 
> parameters to be signaled during reservation should be strictly limited. 
> The more mapping and evaluation of QoS parameters is required during 
> reservation, the more complex the service gets. Complex services are hard 
> to sell and hard to provide. 
> 
> Regards, 
> 
> R?diger 
> 
> R?diger Geib 
> Senior Project Manager 
> T-Systems Nova GmbH 
> 
>> I think that what is needed is a new protocol that can signal the


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



From daemon@optimus.ietf.org  Thu Jan 17 08:11:09 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14126
	for <nsis-archive@odin.ietf.org>; Thu, 17 Jan 2002 08:11:09 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id IAA01004
	for nsis-archive@odin.ietf.org; Thu, 17 Jan 2002 08:11: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 IAA00977;
	Thu, 17 Jan 2002 08:10:05 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA00942
	for <nsis@optimus.ietf.org>; Thu, 17 Jan 2002 08:10:03 -0500 (EST)
Received: from albatross-ext.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 IAA14096
	for <nsis@ietf.org>; Thu, 17 Jan 2002 08:09:59 -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.11.0/8.11.0/WIREfire-1.3) with SMTP id g0HD9xJ24856
	for <nsis@ietf.org>; Thu, 17 Jan 2002 14:09:59 +0100 (MET)
Received: FROM esealnt747.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Thu Jan 17 14:09:58 2002 +0100
Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <YHKTKNWM>; Thu, 17 Jan 2002 14:09:42 +0100
Message-ID: <E244E44D6AB85E40AEEF7EAABE3545FA82336B@enleent104.nl.eu.ericsson.se>
From: "Georgios Karagiannis (ELN)" <Georgios.Karagiannis@eln.ericsson.se>
To: "'Loughney John (NRC/Helsinki)'" <john.loughney@nokia.com>,
        "'ext Kappler Cornelia'" <Cornelia.Kappler@icn.siemens.de>
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements
Date: Thu, 17 Jan 2002 14:09:57 +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 and Cornelia

I think that one of the requirements that should be included 
in the NSIS WG requirements document is that the NSIS protocol
should be modular. Modular in the context of having 
a toolkit from which one can choose the applicable tools 
in order to manage QoS in a particular networking environment.

Best Regards,
Georgios



-----Original Message-----
From: Loughney John (NRC/Helsinki) [mailto:john.loughney@nokia.com]
Sent: donderdag 17 januari 2002 13:54
To: 'ext Kappler Cornelia'; 'ext Georgios Karagiannis (ELN)'
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


Hi Cornelia,

> to my understanding the very idea of the modular / toolkit 
> approach is providing basic "MUST" functionality, but at the 
> same time _leaving open_ the possiblity of later adding "MAY" 
> functionality. 
> 
> This means we should try designing the protocol such that 
> later "MAY" functionality can be added in a modular fashion. 

Yes, I agree with you & Georgios, however, with respect to
the Requirements Document - I think we should only place
MUSTs in such a document.

John

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

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



From daemon@optimus.ietf.org  Thu Jan 17 08:12:31 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14162
	for <nsis-archive@odin.ietf.org>; Thu, 17 Jan 2002 08:12:31 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id IAA01073
	for nsis-archive@odin.ietf.org; Thu, 17 Jan 2002 08:12: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 IAA01059;
	Thu, 17 Jan 2002 08:11: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 IAA01023
	for <nsis@optimus.ietf.org>; Thu, 17 Jan 2002 08:11:41 -0500 (EST)
Received: from albatross-ext.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 IAA14155
	for <nsis@ietf.org>; Thu, 17 Jan 2002 08:11:38 -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.11.0/8.11.0/WIREfire-1.3) with SMTP id g0HDBcJ26380
	for <nsis@ietf.org>; Thu, 17 Jan 2002 14:11:38 +0100 (MET)
Received: FROM esealnt746.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Thu Jan 17 14:11:37 2002 +0100
Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <YHLJLH54>; Thu, 17 Jan 2002 14:11:38 +0100
Message-ID: <E244E44D6AB85E40AEEF7EAABE3545FA82336C@enleent104.nl.eu.ericsson.se>
From: "Georgios Karagiannis (ELN)" <Georgios.Karagiannis@eln.ericsson.se>
To: "'Yaron Kahana'" <ykahana@comgates.co.il>
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements
Date: Thu, 17 Jan 2002 14:11:36 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="windows-1255"
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 Yaron
 
In an over-provisioned network one can assume that the QoS metrics are satisfied!
If the middle domain is not over-provisioned then yes, there will be 
a problem in satisfying the end to end QoS request. 
 
 
Best Regards,
Georgios

-----Original Message-----
From: Yaron Kahana [mailto:ykahana@comgates.co.il]
Sent: donderdag 17 januari 2002 14:06
To: 'Georgios Karagiannis (ELN)'
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements



Hi, 

Great. This however leads to the question of QoS metrics budgeting (like what should be the required delay in domain A, B, and C, when B is not supporting/processing the QoS signalling request).

Yaron 
. 

-----Original Message----- 
From: Georgios Karagiannis (ELN) [ mailto:Georgios.Karagiannis@eln.ericsson.se <mailto:Georgios.Karagiannis@eln.ericsson.se> ] 
Sent: Thursday, January 17, 2002 3:00 PM 
To: 'Yaron Kahana' 
Cc: nsis@ietf.org 
Subject: RE: [NSIS] Two kinds of requirements 

Hi Yaron 

The toolkit is a method of specifying which QoS requirements will impact 
a certain node in an IP based network, not in an ATM or other kind of networks. 
If an IP domain supports overprovisioning then it would probably be useless 
to process (check and use) the (future)  NSIS protocol within this domain. 
I think that it should be allowed that nodes bypass (without checking and using) 
the NSIS protocol messages if required. 

Best Regards, 
Georgios 




-----Original Message----- 
From: Yaron Kahana [ mailto:ykahana@comgates.co.il <mailto:ykahana@comgates.co.il> ] 
Sent: donderdag 17 januari 2002 13:47 
To: 'Georgios Karagiannis (ELN)' 
Cc: nsis@ietf.org 
Subject: RE: [NSIS] Two kinds of requirements 



Hi Georgios, 


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



From daemon@optimus.ietf.org  Thu Jan 17 08:15: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 IAA14268
	for <nsis-archive@odin.ietf.org>; Thu, 17 Jan 2002 08:15:57 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id IAA01320
	for nsis-archive@odin.ietf.org; Thu, 17 Jan 2002 08:15: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 IAA01244;
	Thu, 17 Jan 2002 08:14: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 IAA01177
	for <nsis@optimus.ietf.org>; Thu, 17 Jan 2002 08:14: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 IAA14238
	for <nsis@ietf.org>; Thu, 17 Jan 2002 08:14:15 -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 g0HDCn528330;
	Thu, 17 Jan 2002 14:12:49 +0100 (MET)
Subject: RE: [NSIS] Two kinds of requirements
To: Yaron Kahana <ykahana@comgates.co.il>
Cc: "'Georgios Karagiannis (ELN)'" <Georgios.Karagiannis@eln.ericsson.se>,
        nsis@ietf.org
X-Mailer: Lotus Notes Release 5.0.5  September 22, 2000
Message-ID: <OF195B10E7.4A5FF4E4-ONC1256B44.00484422@net.alcatel.be>
Date: Thu, 17 Jan 2002 14:12:47 +0100
X-MIMETrack: Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at
 01/17/2002 14:12:48
MIME-Version: 1.0
Content-type: multipart/mixed; 
	Boundary="0__=C1256B44004844228f9e8a93df938690918cC1256B4400484422"
Content-Disposition: inline
Sender: nsis-admin@ietf.org
Errors-To: nsis-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Next Steps in Signaling <nsis.ietf.org>
X-BeenThere: nsis@ietf.org

--0__=C1256B44004844228f9e8a93df938690918cC1256B4400484422
Content-type: text/plain; charset=us-ascii

Hi,

I don't think it is feasible in this case to aim for the solution that just
fits within the constraint. Every section will have to do the best it can
and cannot afford to "live off the others' sacrifices". I think this is
even the case for all but the last section in a setup procedure where all
sections support the QoS signalling request.

Sven.





Yaron Kahana <ykahana@comgates.co.il> on 17/01/2002 14:06:11
                                                              
                                                              
                                                              
  To:          "'Georgios Karagiannis (ELN)'"                 
               <Georgios.Karagiannis@eln.ericsson.se>         
                                                              
  cc:          nsis@ietf.org(bcc: Sven VAN DEN                
               BOSCH/BE/ALCATEL)                              
                                                              
                                                              
                                                              
  Subject      RE: [NSIS] Two kinds of requirements           
  :                                                           
                                                              





Hi,

Great. This however leads to the question of QoS metrics budgeting (like
what should be the required delay in domain A, B, and C, when B is not
supporting/processing the QoS signalling request).

Yaron
 .

-----Original Message-----
From: Georgios Karagiannis (ELN)
[mailto:Georgios.Karagiannis@eln.ericsson.se]
Sent: Thursday, January 17, 2002 3:00 PM
To: 'Yaron Kahana'
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements

Hi Yaron

The toolkit is a method of specifying which QoS requirements will impact
a certain node in an IP based network, not in an ATM or other kind of
networks.
If an IP domain supports overprovisioning then it would probably be useless
to process (check and use) the (future)  NSIS protocol within this domain.
I think that it should be allowed that nodes bypass (without checking and
using)
the NSIS protocol messages if required.

Best Regards,
Georgios




-----Original Message-----
From: Yaron Kahana [mailto:ykahana@comgates.co.il]
Sent: donderdag 17 januari 2002 13:47
To: 'Georgios Karagiannis (ELN)'
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements



Hi Georgios,

From what you are saying I understand that this toolkit request are
"passing
through" any domain. Will it be the case over ATM/FR/IPv4/IPv6?

Best Regards
Yaron

-----Original Message-----
From: Georgios Karagiannis (ELN) [
mailto:Georgios.Karagiannis@eln.ericsson.se
<mailto:Georgios.Karagiannis@eln.ericsson.se> ]
Sent: Thursday, January 17, 2002 2:35 PM
To: 'Yaron Kahana'
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements

Hi Yaron

Assuming that the domain in the middle supports over-provisioning the end
-to end QoS provisioning
could be satisfied.

Best Regards,
Georgios

-----Original Message-----
From: Yaro mailto:ykahana@comgates.co.il <mailto:ykahana@comgates.co.il> ]
Sent: donderdag 17 januari 2002 12:09
To: 'Georgios Karagiannis (ELN)'; Geib, Ruediger; 'Freytsis, Ilya'
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements



Hi,

I still don't see how such a toolkit can be useful if a certain domain in
the middle did not deployed a support in it and the Chicken and Egg
syndrome.

Yaron

-----Original Message-----
From: Georgios Karagiannis (ELN) [
mailto:Georgios.Karagiannis@eln.ericsson.se
<mailto:Georgios.Karagiannis@eln.ericsson.se>  <
mailto:Georgios.Karagiannis@eln.ericsson.se
<mailto:Georgios.Karagiannis@eln.ericsson.se> > ]

Sent: Thursday, January 17, 2002 12:04 PM
To: 'Yaron Kahana'; Geib, Ruediger; 'Freytsis, Ilya'
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements

Hi Yaron, Ilya, Ruediger

Almost all issues that you addressed in your e-mails can be solved (see
also
my previous e-mail
addressed to Dick) by first creating a modular QoS signaling toolkit that
will contain mandatory and
optional QoS requirements.
Second, specifying how the protocol functionality should be separated in
building blocks
(NSIS protocol components) and define a minimum set of mandatory
reservation
options/features
that should be processed by any network nodes, e.g., end-hosts, proxies,
edges and interior nodes.

Best Regards,
Georgios

-----Original Message-----
From: Yaron Kahana [ mailto:ykahana@comgates.co.il
<mailto:ykahana@comgates.co.il>  < mailto:ykahana@comgates.co.il
<mailto:ykahana@comgates.co.il> > ]
Sent: woensdag 16 januari 2002 22:16
To: brunner@ccrle.nec.de; Geib, Ruediger; dick.rr.knight@bt.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements



Hello Ruediger, Marcus,

I agree with your comments. One of the crucial elements is th

We should try to keep it simple, even on the expense of full flexibility.

By the way - did anyone considered the problem of a non-cooperative IP
domain "in the middle" ? for example, Suppose I'm making a call from Los
Angeles to Munich through 3 domains - LA-NY, NY-London, London-Munich. What
will happen if the best/cheapest carrier along the NY-London domain won't
support this new protocol? Will he be condemned/ignored? When will he
upgrade his infrastructure, before the chicke

Yaron Kahana
COGITO Project Manager,
COMGATES

 -----Original Message-----
From:   Marcus Brunner [ mailto:brunner@ccrle.nec.de
<mailto:brunner@ccrle.nec.de>  < mailto:brunner@ccrle.nec.de
<mailto:brunner@ccrle.nec.de> >  < mailto:brunner@ccrle.nec.de
<mailto:brunner@ccrle.nec.de>  < mailto:brunner@ccrle.nec.de
<mailto:brunner@ccrle.nec.de> > > ]

Sent:   Wednesday, January 16, 2002 5:35 PM
To:     Geib, Ruediger; dick.rr.knight@bt.com
Cc:     nsis@ietf.org
Subject:        RE: [NSIS] Two kinds of requirements

Ruediger,

The service needs to be defined anyway. Then there are IMO two
possibilities
- the provider defines the services and offers them. In this case the
provider needs to describe the offers in a machine readable form (most
likely with parameter names and values)
- the consumer requests a particular service (this means the consumer has
to describe the service he wants in a machine readable form)

So it seams one has to move around service specifications which are
understandable by the other party anyway, what is now your point? Is it
that you want to limit/fix as many parameters as possible? Or are you more
think about standardized services everybody understands?

Marcus

--On Wednesday, January 16, 2002 3:45 PM +0100 "Geib, Ruediger"
<Ruediger.Geib@t-systems.com> wrote:

> Hello Dick,
>
> your suggestion is quite reasonable. I also favour an architecture where
> a QoS request by and large is predefined in terms of the resources
> required from the available transport mechanism. Service specific
> parameters to be signaled during reservation should be strictly limited.
> The more mapping and evaluation of QoS parameters is required during
> reservation, the more complex the service gets. Complex services are hard
> to sell and hard to provide.
>
> Regards,
>
> R?diger
>
> R?diger Geib
> Senior Project Manager
> T-Systems Nova GmbH
>
>> I think that what is needed is a new protocol that can signal the

(See attached file: att1.htm)


--0__=C1256B44004844228f9e8a93df938690918cC1256B4400484422
Content-type: text/html; 
	name="att1.htm"
Content-Disposition: attachment; filename="att1.htm"
Content-Transfer-Encoding: base64

PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPEhUTUw+
DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9o
dG1sOyBjaGFyc2V0PXdpbmRvd3MtMTI1NSI+DQo8TUVUQSBOQU1FPSJHZW5lcmF0b3IiIENPTlRF
TlQ9Ik1TIEV4Y2hhbmdlIFNlcnZlciB2ZXJzaW9uIDUuNS4yNjUzLjEyIj4NCjxUSVRMRT5SRTog
W05TSVNdIFR3byBraW5kcyBvZiByZXF1aXJlbWVudHM8L1RJVExFPg0KPC9IRUFEPg0KPEJPRFk+
DQoNCjxQPjxGT05UIFNJWkU9Mj5IaSw8L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj5H
cmVhdC4gVGhpcyBob3dldmVyIGxlYWRzIHRvIHRoZSBxdWVzdGlvbiBvZiBRb1MgbWV0cmljcyBi
dWRnZXRpbmcgKGxpa2Ugd2hhdCBzaG91bGQgYmUgdGhlIHJlcXVpcmVkIGRlbGF5IGluIGRvbWFp
biBBLCBCLCBhbmQgQywgd2hlbiBCIGlzIG5vdCBzdXBwb3J0aW5nL3Byb2Nlc3NpbmcgdGhlIFFv
UyBzaWduYWxsaW5nIHJlcXVlc3QpLjwvRk9OVD48L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj5ZYXJv
bjwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+LjwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0la
RT0yPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5G
cm9tOiBHZW9yZ2lvcyBLYXJhZ2lhbm5pcyAoRUxOKSBbPEEgSFJFRj0ibWFpbHRvOkdlb3JnaW9z
LkthcmFnaWFubmlzQGVsbi5lcmljc3Nvbi5zZSI+bWFpbHRvOkdlb3JnaW9zLkthcmFnaWFubmlz
QGVsbi5lcmljc3Nvbi5zZTwvQT5dPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5TZW50OiBUaHVy
c2RheSwgSmFudWFyeSAxNywgMjAwMiAzOjAwIFBNPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5U
bzogJ1lhcm9uIEthaGFuYSc8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPkNjOiBuc2lzQGlldGYu
b3JnPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5TdWJqZWN0OiBSRTogW05TSVNdIFR3byBraW5k
cyBvZiByZXF1aXJlbWVudHM8L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj5IaSBZYXJv
bjwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yPlRoZSB0b29sa2l0IGlzIGEgbWV0aG9k
IG9mIHNwZWNpZnlpbmcgd2hpY2ggUW9TIHJlcXVpcmVtZW50cyB3aWxsIGltcGFjdDwvRk9OVD4N
CjxCUj48Rk9OVCBTSVpFPTI+YSBjZXJ0YWluIG5vZGUgaW4gYW4gSVAgYmFzZWQgbmV0d29yaywg
bm90IGluIGFuIEFUTSBvciBvdGhlciBraW5kIG9mIG5ldHdvcmtzLjwvRk9OVD4NCjxCUj48Rk9O
VCBTSVpFPTI+SWYgYW4gSVAgZG9tYWluIHN1cHBvcnRzIG92ZXJwcm92aXNpb25pbmcgdGhlbiBp
dCB3b3VsZCBwcm9iYWJseSBiZSB1c2VsZXNzPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj50byBw
cm9jZXNzIChjaGVjayBhbmQgdXNlKSB0aGUgKGZ1dHVyZSkmbmJzcDsgTlNJUyBwcm90b2NvbCB3
aXRoaW4gdGhpcyBkb21haW4uPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5JIHRoaW5rIHRoYXQg
aXQgc2hvdWxkIGJlIGFsbG93ZWQgdGhhdCBub2RlcyBieXBhc3MgKHdpdGhvdXQgY2hlY2tpbmcg
YW5kIHVzaW5nKTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+dGhlIE5TSVMgcHJvdG9jb2wgbWVz
c2FnZXMgaWYgcmVxdWlyZWQuPC9GT05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+QmVzdCBS
ZWdhcmRzLDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+R2Vvcmdpb3M8L0ZPTlQ+DQo8L1A+DQo8
QlI+DQo8QlI+DQo8QlI+DQoNCjxQPjxGT05UIFNJWkU9Mj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut
LS0tLTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+RnJvbTogWWFyb24gS2FoYW5hIFs8QSBIUkVG
PSJtYWlsdG86eWthaGFuYUBjb21nYXRlcy5jby5pbCI+bWFpbHRvOnlrYWhhbmFAY29tZ2F0ZXMu
Y28uaWw8L0E+XTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+U2VudDogZG9uZGVyZGFnIDE3IGph
bnVhcmkgMjAwMiAxMzo0NzwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+VG86ICdHZW9yZ2lvcyBL
YXJhZ2lhbm5pcyAoRUxOKSc8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPkNjOiBuc2lzQGlldGYu
b3JnPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5TdWJqZWN0OiBSRTogW05TSVNdIFR3byBraW5k
cyBvZiByZXF1aXJlbWVudHM8L0ZPTlQ+DQo8L1A+DQo8QlI+DQo8QlI+DQoNCjxQPjxGT05UIFNJ
WkU9Mj5IaSBHZW9yZ2lvcyw8L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj5Gcm9tIHdo
YXQgeW91IGFyZSBzYXlpbmcgSSB1bmRlcnN0YW5kIHRoYXQgdGhpcyB0b29sa2l0IHJlcXVlc3Qg
YXJlICZxdW90O3Bhc3NpbmcgdGhyb3VnaCZxdW90OyBhbnkgZG9tYWluLiBXaWxsIGl0IGJlIHRo
ZSBjYXNlIG92ZXIgQVRNL0ZSL0lQdjQvSVB2Nj88L0ZPTlQ+PC9QPg0KDQo8UD48Rk9OVCBTSVpF
PTI+QmVzdCBSZWdhcmRzPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5ZYXJvbjwvRk9OVD4NCjwv
UD4NCg0KPFA+PEZPTlQgU0laRT0yPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPC9GT05UPg0K
PEJSPjxGT05UIFNJWkU9Mj5Gcm9tOiBHZW9yZ2lvcyBLYXJhZ2lhbm5pcyAoRUxOKSBbIDxBIEhS
RUY9Im1haWx0bzpHZW9yZ2lvcy5LYXJhZ2lhbm5pc0BlbG4uZXJpY3Nzb24uc2UiPm1haWx0bzpH
ZW9yZ2lvcy5LYXJhZ2lhbm5pc0BlbG4uZXJpY3Nzb24uc2U8L0E+ICZsdDs8QSBIUkVGPSJtYWls
dG86R2Vvcmdpb3MuS2FyYWdpYW5uaXNAZWxuLmVyaWNzc29uLnNlIj5tYWlsdG86R2Vvcmdpb3Mu
S2FyYWdpYW5uaXNAZWxuLmVyaWNzc29uLnNlPC9BPiZndDsgXTwvRk9OVD48L1A+DQoNCjxQPjxG
T05UIFNJWkU9Mj5TZW50OiBUaHVyc2RheSwgSmFudWFyeSAxNywgMjAwMiAyOjM1IFBNPC9GT05U
Pg0KPEJSPjxGT05UIFNJWkU9Mj5UbzogJ1lhcm9uIEthaGFuYSc8L0ZPTlQ+DQo8QlI+PEZPTlQg
U0laRT0yPkNjOiBuc2lzQGlldGYub3JnPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5TdWJqZWN0
OiBSRTogW05TSVNdIFR3byBraW5kcyBvZiByZXF1aXJlbWVudHM8L0ZPTlQ+DQo8L1A+DQoNCjxQ
PjxGT05UIFNJWkU9Mj5IaSBZYXJvbjwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yPkFz
c3VtaW5nIHRoYXQgdGhlIGRvbWFpbiBpbiB0aGUgbWlkZGxlIHN1cHBvcnRzIG92ZXItcHJvdmlz
aW9uaW5nIHRoZSBlbmQgLXRvIGVuZCBRb1MgcHJvdmlzaW9uaW5nPC9GT05UPg0KPEJSPjxGT05U
IFNJWkU9Mj5jb3VsZCBiZSBzYXRpc2ZpZWQuPC9GT05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpF
PTI+QmVzdCBSZWdhcmRzLDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+R2Vvcmdpb3M8L0ZPTlQ+
DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTwvRk9O
VD4NCjxCUj48Rk9OVCBTSVpFPTI+RnJvbTogWWFybyA8QSBIUkVGPSJtYWlsdG86eWthaGFuYUBj
b21nYXRlcy5jby5pbCI+bWFpbHRvOnlrYWhhbmFAY29tZ2F0ZXMuY28uaWw8L0E+ICZsdDs8QSBI
UkVGPSJtYWlsdG86eWthaGFuYUBjb21nYXRlcy5jby5pbCI+bWFpbHRvOnlrYWhhbmFAY29tZ2F0
ZXMuY28uaWw8L0E+Jmd0OyBdPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5TZW50OiBkb25kZXJk
YWcgMTcgamFudWFyaSAyMDAyIDEyOjA5PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5UbzogJ0dl
b3JnaW9zIEthcmFnaWFubmlzIChFTE4pJzsgR2VpYiwgUnVlZGlnZXI7ICdGcmV5dHNpcywgSWx5
YSc8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPkNjOiBuc2lzQGlldGYub3JnPC9GT05UPg0KPEJS
PjxGT05UIFNJWkU9Mj5TdWJqZWN0OiBSRTogW05TSVNdIFR3byBraW5kcyBvZiByZXF1aXJlbWVu
dHM8L0ZPTlQ+DQo8L1A+DQo8QlI+DQo8QlI+DQoNCjxQPjxGT05UIFNJWkU9Mj5IaSw8L0ZPTlQ+
DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj5JIHN0aWxsIGRvbid0IHNlZSBob3cgc3VjaCBhIHRv
b2xraXQgY2FuIGJlIHVzZWZ1bCBpZiBhIGNlcnRhaW4gZG9tYWluIGluIHRoZSBtaWRkbGUgZGlk
IG5vdCBkZXBsb3llZCBhIHN1cHBvcnQgaW4gaXQgYW5kIHRoZSBDaGlja2VuIGFuZCBFZ2cgc3lu
ZHJvbWUuPC9GT05UPjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yPllhcm9uPC9GT05UPg0KPC9QPg0K
DQo8UD48Rk9OVCBTSVpFPTI+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08L0ZPTlQ+DQo8QlI+
PEZPTlQgU0laRT0yPkZyb206IEdlb3JnaW9zIEthcmFnaWFubmlzIChFTE4pIFsgPEEgSFJFRj0i
bWFpbHRvOkdlb3JnaW9zLkthcmFnaWFubmlzQGVsbi5lcmljc3Nvbi5zZSI+bWFpbHRvOkdlb3Jn
aW9zLkthcmFnaWFubmlzQGVsbi5lcmljc3Nvbi5zZTwvQT4gJmx0OzxBIEhSRUY9Im1haWx0bzpH
ZW9yZ2lvcy5LYXJhZ2lhbm5pc0BlbG4uZXJpY3Nzb24uc2UiPm1haWx0bzpHZW9yZ2lvcy5LYXJh
Z2lhbm5pc0BlbG4uZXJpY3Nzb24uc2U8L0E+Jmd0OyZuYnNwOyAmbHQ7IDxBIEhSRUY9Im1haWx0
bzpHZW9yZ2lvcy5LYXJhZ2lhbm5pc0BlbG4uZXJpY3Nzb24uc2UiPm1haWx0bzpHZW9yZ2lvcy5L
YXJhZ2lhbm5pc0BlbG4uZXJpY3Nzb24uc2U8L0E+ICZsdDs8QSBIUkVGPSJtYWlsdG86R2Vvcmdp
b3MuS2FyYWdpYW5uaXNAZWxuLmVyaWNzc29uLnNlIj5tYWlsdG86R2Vvcmdpb3MuS2FyYWdpYW5u
aXNAZWxuLmVyaWNzc29uLnNlPC9BPiZndDsgJmd0OyBdPC9GT05UPjwvUD4NCg0KPFA+PEZPTlQg
U0laRT0yPlNlbnQ6IFRodXJzZGF5LCBKYW51YXJ5IDE3LCAyMDAyIDEyOjA0IFBNPC9GT05UPg0K
PEJSPjxGT05UIFNJWkU9Mj5UbzogJ1lhcm9uIEthaGFuYSc7IEdlaWIsIFJ1ZWRpZ2VyOyAnRnJl
eXRzaXMsIElseWEnPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5DYzogbnNpc0BpZXRmLm9yZzwv
Rk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+U3ViamVjdDogUkU6IFtOU0lTXSBUd28ga2luZHMgb2Yg
cmVxdWlyZW1lbnRzPC9GT05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+SGkgWWFyb24sIEls
eWEsIFJ1ZWRpZ2VyPC9GT05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+QWxtb3N0IGFsbCBp
c3N1ZXMgdGhhdCB5b3UgYWRkcmVzc2VkIGluIHlvdXIgZS1tYWlscyBjYW4gYmUgc29sdmVkIChz
ZWUgYWxzbyBteSBwcmV2aW91cyBlLW1haWw8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPmFkZHJl
c3NlZCB0byBEaWNrKSBieSBmaXJzdCBjcmVhdGluZyBhIG1vZHVsYXIgUW9TIHNpZ25hbGluZyB0
b29sa2l0IHRoYXQgd2lsbCBjb250YWluIG1hbmRhdG9yeSBhbmQ8L0ZPTlQ+DQo8QlI+PEZPTlQg
U0laRT0yPm9wdGlvbmFsIFFvUyByZXF1aXJlbWVudHMuPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9
Mj5TZWNvbmQsIHNwZWNpZnlpbmcgaG93IHRoZSBwcm90b2NvbCBmdW5jdGlvbmFsaXR5IHNob3Vs
ZCBiZSBzZXBhcmF0ZWQgaW4gYnVpbGRpbmcgYmxvY2tzPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9
Mj4oTlNJUyBwcm90b2NvbCBjb21wb25lbnRzKSBhbmQgZGVmaW5lIGEgbWluaW11bSBzZXQgb2Yg
bWFuZGF0b3J5IHJlc2VydmF0aW9uIG9wdGlvbnMvZmVhdHVyZXM8L0ZPTlQ+DQo8QlI+PEZPTlQg
U0laRT0yPnRoYXQgc2hvdWxkIGJlIHByb2Nlc3NlZCBieSBhbnkgbmV0d29yayBub2RlcywgZS5n
LiwgZW5kLWhvc3RzLCBwcm94aWVzLCBlZGdlcyBhbmQgaW50ZXJpb3Igbm9kZXMuPC9GT05UPg0K
PC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+QmVzdCBSZWdhcmRzLDwvRk9OVD4NCjxCUj48Rk9OVCBT
SVpFPTI+R2Vvcmdpb3M8L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj4tLS0tLU9yaWdp
bmFsIE1lc3NhZ2UtLS0tLTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+RnJvbTogWWFyb24gS2Fo
YW5hIFsgPEEgSFJFRj0ibWFpbHRvOnlrYWhhbmFAY29tZ2F0ZXMuY28uaWwiPm1haWx0bzp5a2Fo
YW5hQGNvbWdhdGVzLmNvLmlsPC9BPiAmbHQ7PEEgSFJFRj0ibWFpbHRvOnlrYWhhbmFAY29tZ2F0
ZXMuY28uaWwiPm1haWx0bzp5a2FoYW5hQGNvbWdhdGVzLmNvLmlsPC9BPiZndDsmbmJzcDsgJmx0
OyA8QSBIUkVGPSJtYWlsdG86eWthaGFuYUBjb21nYXRlcy5jby5pbCI+bWFpbHRvOnlrYWhhbmFA
Y29tZ2F0ZXMuY28uaWw8L0E+ICZsdDs8QSBIUkVGPSJtYWlsdG86eWthaGFuYUBjb21nYXRlcy5j
by5pbCI+bWFpbHRvOnlrYWhhbmFAY29tZ2F0ZXMuY28uaWw8L0E+Jmd0OyAmZ3Q7IF08L0ZPTlQ+
PC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+U2VudDogd29lbnNkYWcgMTYgamFudWFyaSAyMDAyIDIy
OjE2PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5UbzogYnJ1bm5lckBjY3JsZS5uZWMuZGU7IEdl
aWIsIFJ1ZWRpZ2VyOyBkaWNrLnJyLmtuaWdodEBidC5jb208L0ZPTlQ+DQo8QlI+PEZPTlQgU0la
RT0yPkNjOiBuc2lzQGlldGYub3JnPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5TdWJqZWN0OiBS
RTogW05TSVNdIFR3byBraW5kcyBvZiByZXF1aXJlbWVudHM8L0ZPTlQ+DQo8L1A+DQo8QlI+DQo8
QlI+DQoNCjxQPjxGT05UIFNJWkU9Mj5IZWxsbyBSdWVkaWdlciwgTWFyY3VzLDwvRk9OVD4NCjwv
UD4NCg0KPFA+PEZPTlQgU0laRT0yPkkgYWdyZWUgd2l0aCB5b3VyIGNvbW1lbnRzLiBPbmUgb2Yg
dGhlIGNydWNpYWwgZWxlbWVudHMgaXMgdGg8L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9
Mj5XZSBzaG91bGQgdHJ5IHRvIGtlZXAgaXQgc2ltcGxlLCBldmVuIG9uIHRoZSBleHBlbnNlIG9m
IGZ1bGwgZmxleGliaWxpdHkuPC9GT05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+QnkgdGhl
IHdheSAtIGRpZCBhbnlvbmUgY29uc2lkZXJlZCB0aGUgcHJvYmxlbSBvZiBhIG5vbi1jb29wZXJh
dGl2ZSBJUCBkb21haW4gJnF1b3Q7aW4gdGhlIG1pZGRsZSZxdW90OyA/IGZvciBleGFtcGxlLCBT
dXBwb3NlIEknbSBtYWtpbmcgYSBjYWxsIGZyb20gTG9zIEFuZ2VsZXMgdG8gTXVuaWNoIHRocm91
Z2ggMyBkb21haW5zIC0gTEEtTlksIE5ZLUxvbmRvbiwgTG9uZG9uLU11bmljaC4gV2hhdCB3aWxs
IGhhcHBlbiBpZiB0aGUgYmVzdC9jaGVhcGVzdCBjYXJyaWVyIGFsb25nIHRoZSBOWS1Mb25kb24g
ZG9tYWluIHdvbid0IHN1cHBvcnQgdGhpcyBuZXcgcHJvdG9jb2w/IFdpbGwgaGUgYmUgY29uZGVt
bmVkL2lnbm9yZWQ/IFdoZW4gd2lsbCBoZSB1cGdyYWRlIGhpcyBpbmZyYXN0cnVjdHVyZSwgYmVm
b3JlIHRoZSBjaGlja2U8L0ZPTlQ+PC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+WWFyb24gS2FoYW5h
PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5DT0dJVE8gUHJvamVjdCBNYW5hZ2VyLDwvRk9OVD4N
CjxCUj48Rk9OVCBTSVpFPTI+Q09NR0FURVM8L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9
Mj4mbmJzcDstLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpF
PTI+RnJvbTombmJzcDsmbmJzcDsgTWFyY3VzIEJydW5uZXIgWyA8QSBIUkVGPSJtYWlsdG86YnJ1
bm5lckBjY3JsZS5uZWMuZGUiPm1haWx0bzpicnVubmVyQGNjcmxlLm5lYy5kZTwvQT4gJmx0OzxB
IEhSRUY9Im1haWx0bzpicnVubmVyQGNjcmxlLm5lYy5kZSI+bWFpbHRvOmJydW5uZXJAY2NybGUu
bmVjLmRlPC9BPiZndDsmbmJzcDsgJmx0OyA8QSBIUkVGPSJtYWlsdG86YnJ1bm5lckBjY3JsZS5u
ZWMuZGUiPm1haWx0bzpicnVubmVyQGNjcmxlLm5lYy5kZTwvQT4gJmx0OzxBIEhSRUY9Im1haWx0
bzpicnVubmVyQGNjcmxlLm5lYy5kZSI+bWFpbHRvOmJydW5uZXJAY2NybGUubmVjLmRlPC9BPiZn
dDsgJmd0OyZuYnNwOyAmbHQ7IDxBIEhSRUY9Im1haWx0bzpicnVubmVyQGNjcmxlLm5lYy5kZSI+
bWFpbHRvOmJydW5uZXJAY2NybGUubmVjLmRlPC9BPiAmbHQ7PEEgSFJFRj0ibWFpbHRvOmJydW5u
ZXJAY2NybGUubmVjLmRlIj5tYWlsdG86YnJ1bm5lckBjY3JsZS5uZWMuZGU8L0E+Jmd0OyZuYnNw
OyAmbHQ7IDxBIEhSRUY9Im1haWx0bzpicnVubmVyQGNjcmxlLm5lYy5kZSI+bWFpbHRvOmJydW5u
ZXJAY2NybGUubmVjLmRlPC9BPiAmbHQ7PEEgSFJFRj0ibWFpbHRvOmJydW5uZXJAY2NybGUubmVj
LmRlIj5tYWlsdG86YnJ1bm5lckBjY3JsZS5uZWMuZGU8L0E+Jmd0OyAmZ3Q7ICZndDsgXTwvRk9O
VD48L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj5TZW50OiZuYnNwOyZuYnNwOyBXZWRuZXNkYXksIEph
bnVhcnkgMTYsIDIwMDIgNTozNSBQTTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+VG86Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7IEdlaWIsIFJ1ZWRpZ2VyOyBkaWNrLnJyLmtuaWdodEBidC5jb208
L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPkNjOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBuc2lz
QGlldGYub3JnPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5TdWJqZWN0OiZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBSRTogW05TSVNdIFR3byBraW5kcyBvZiByZXF1
aXJlbWVudHM8L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj5SdWVkaWdlciw8L0ZPTlQ+
DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj5UaGUgc2VydmljZSBuZWVkcyB0byBiZSBkZWZpbmVk
IGFueXdheS4gVGhlbiB0aGVyZSBhcmUgSU1PIHR3bzwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+
cG9zc2liaWxpdGllczwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+LSB0aGUgcHJvdmlkZXIgZGVm
aW5lcyB0aGUgc2VydmljZXMgYW5kIG9mZmVycyB0aGVtLiBJbiB0aGlzIGNhc2UgdGhlPC9GT05U
Pg0KPEJSPjxGT05UIFNJWkU9Mj5wcm92aWRlciBuZWVkcyB0byBkZXNjcmliZSB0aGUgb2ZmZXJz
IGluIGEgbWFjaGluZSByZWFkYWJsZSBmb3JtIChtb3N0PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9
Mj5saWtlbHkgd2l0aCBwYXJhbWV0ZXIgbmFtZXMgYW5kIHZhbHVlcyk8L0ZPTlQ+DQo8QlI+PEZP
TlQgU0laRT0yPi0gdGhlIGNvbnN1bWVyIHJlcXVlc3RzIGEgcGFydGljdWxhciBzZXJ2aWNlICh0
aGlzIG1lYW5zIHRoZSBjb25zdW1lciBoYXM8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPnRvIGRl
c2NyaWJlIHRoZSBzZXJ2aWNlIGhlIHdhbnRzIGluIGEgbWFjaGluZSByZWFkYWJsZSBmb3JtKTwv
Rk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yPlNvIGl0IHNlYW1zIG9uZSBoYXMgdG8gbW92
ZSBhcm91bmQgc2VydmljZSBzcGVjaWZpY2F0aW9ucyB3aGljaCBhcmU8L0ZPTlQ+DQo8QlI+PEZP
TlQgU0laRT0yPnVuZGVyc3RhbmRhYmxlIGJ5IHRoZSBvdGhlciBwYXJ0eSBhbnl3YXksIHdoYXQg
aXMgbm93IHlvdXIgcG9pbnQ/IElzIGl0PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj50aGF0IHlv
dSB3YW50IHRvIGxpbWl0L2ZpeCBhcyBtYW55IHBhcmFtZXRlcnMgYXMgcG9zc2libGU/IE9yIGFy
ZSB5b3UgbW9yZTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+dGhpbmsgYWJvdXQgc3RhbmRhcmRp
emVkIHNlcnZpY2VzIGV2ZXJ5Ym9keSB1bmRlcnN0YW5kcz88L0ZPTlQ+DQo8L1A+DQoNCjxQPjxG
T05UIFNJWkU9Mj5NYXJjdXM8L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj4tLU9uIFdl
ZG5lc2RheSwgSmFudWFyeSAxNiwgMjAwMiAzOjQ1IFBNICswMTAwICZxdW90O0dlaWIsIFJ1ZWRp
Z2VyJnF1b3Q7PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mbHQ7UnVlZGlnZXIuR2VpYkB0LXN5
c3RlbXMuY29tJmd0OyB3cm90ZTo8L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj4mZ3Q7
IEhlbGxvIERpY2ssPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7PC9GT05UPg0KPEJSPjxG
T05UIFNJWkU9Mj4mZ3Q7IHlvdXIgc3VnZ2VzdGlvbiBpcyBxdWl0ZSByZWFzb25hYmxlLiBJIGFs
c28gZmF2b3VyIGFuIGFyY2hpdGVjdHVyZSB3aGVyZTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+
Jmd0OyBhIFFvUyByZXF1ZXN0IGJ5IGFuZCBsYXJnZSBpcyBwcmVkZWZpbmVkIGluIHRlcm1zIG9m
IHRoZSByZXNvdXJjZXM8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgcmVxdWlyZWQgZnJv
bSB0aGUgYXZhaWxhYmxlIHRyYW5zcG9ydCBtZWNoYW5pc20uIFNlcnZpY2Ugc3BlY2lmaWM8L0ZP
TlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgcGFyYW1ldGVycyB0byBiZSBzaWduYWxlZCBkdXJp
bmcgcmVzZXJ2YXRpb24gc2hvdWxkIGJlIHN0cmljdGx5IGxpbWl0ZWQuPC9GT05UPg0KPEJSPjxG
T05UIFNJWkU9Mj4mZ3Q7IFRoZSBtb3JlIG1hcHBpbmcgYW5kIGV2YWx1YXRpb24gb2YgUW9TIHBh
cmFtZXRlcnMgaXMgcmVxdWlyZWQgZHVyaW5nPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7
IHJlc2VydmF0aW9uLCB0aGUgbW9yZSBjb21wbGV4IHRoZSBzZXJ2aWNlIGdldHMuIENvbXBsZXgg
c2VydmljZXMgYXJlIGhhcmQ8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgdG8gc2VsbCBh
bmQgaGFyZCB0byBwcm92aWRlLjwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OzwvRk9OVD4N
CjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyBSZWdhcmRzLDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+
Jmd0OzwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyBSP2RpZ2VyPC9GT05UPg0KPEJSPjxG
T05UIFNJWkU9Mj4mZ3Q7PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IFI/ZGlnZXIgR2Vp
YjwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyBTZW5pb3IgUHJvamVjdCBNYW5hZ2VyPC9G
T05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IFQtU3lzdGVtcyBOb3ZhIEdtYkg8L0ZPTlQ+DQo8
QlI+PEZPTlQgU0laRT0yPiZndDs8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsmZ3Q7IEkg
dGhpbmsgdGhhdCB3aGF0IGlzIG5lZWRlZCBpcyBhIG5ldyBwcm90b2NvbCB0aGF0IGNhbiBzaWdu
YWwgdGhlPC9GT05UPg0KPC9QPg0KDQo8L0JPRFk+DQo8L0hUTUw+

--0__=C1256B44004844228f9e8a93df938690918cC1256B4400484422--


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



From daemon@optimus.ietf.org  Thu Jan 17 08:24:09 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14474
	for <nsis-archive@odin.ietf.org>; Thu, 17 Jan 2002 08:24:09 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id IAA01477
	for nsis-archive@odin.ietf.org; Thu, 17 Jan 2002 08:24: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 IAA01292;
	Thu, 17 Jan 2002 08:14: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 IAA01259
	for <nsis@optimus.ietf.org>; Thu, 17 Jan 2002 08:14:41 -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 IAA14241
	for <nsis@ietf.org>; Thu, 17 Jan 2002 08:14:37 -0500 (EST)
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 g0HDEf921988
	for <nsis@ietf.org>; Thu, 17 Jan 2002 15:14:41 +0200 (EET)
Received: from esebh004.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T58816c43eaac158f220c8@esvir02nok.ntc.nokia.com>;
 Thu, 17 Jan 2002 15:14:38 +0200
Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779);
	 Thu, 17 Jan 2002 15:14:38 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [NSIS] Two kinds of requirements
Date: Thu, 17 Jan 2002 15:14:37 +0200
Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF5D937F@esebe004.NOE.Nokia.com>
Thread-Topic: [NSIS] Two kinds of requirements
Thread-Index: AcGfWEXB/JzpZtkCRXK+tl/xT8zRTgAAIUkA
From: "Loughney John (NRC/Helsinki)" <john.loughney@nokia.com>
To: "'ext Georgios Karagiannis (ELN)'" <Georgios.Karagiannis@eln.ericsson.se>,
        "'ext Kappler Cornelia'" <Cornelia.Kappler@icn.siemens.de>
Cc: <nsis@ietf.org>
X-OriginalArrivalTime: 17 Jan 2002 13:14:38.0203 (UTC) FILETIME=[EA6CECB0:01C19F58]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id IAA01260
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,

> I think that one of the requirements that should be included 
> in the NSIS WG requirements document is that the NSIS protocol
> should be modular. Modular in the context of having 
> a toolkit from which one can choose the applicable tools 
> in order to manage QoS in a particular networking environment.

I agree.  To put it another way, the protocol SHOULD be able
to be deployed in a number of different scenarios (end-to-edge, 
end-to-end, edge-to-edge, etc.)

John

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



From daemon@optimus.ietf.org  Thu Jan 17 08:27: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 IAA14589
	for <nsis-archive@odin.ietf.org>; Thu, 17 Jan 2002 08:27:34 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id IAA01560
	for nsis-archive@odin.ietf.org; Thu, 17 Jan 2002 08:27: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 IAA01533;
	Thu, 17 Jan 2002 08:26: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 IAA01501
	for <nsis@optimus.ietf.org>; Thu, 17 Jan 2002 08:26:06 -0500 (EST)
Received: from mail-server.comgates.co.il ([212.150.198.2])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14521
	for <nsis@ietf.org>; Thu, 17 Jan 2002 08:26:02 -0500 (EST)
Received: by mail-server.comgates.co.il with Internet Mail Service (5.5.2653.19)
	id <DC2CZY1T>; Thu, 17 Jan 2002 15:26:28 +0200
Message-ID: <6FEF757325DBD411B7DA000629A8A61E7BAD45@mail-server.comgates.co.il>
From: Yaron Kahana <ykahana@comgates.co.il>
To: "'sven.van_den_bosch@alcatel.be'" <sven.van_den_bosch@alcatel.be>
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements
Date: Thu, 17 Jan 2002 15:26:27 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C19F5A.90FE9140"
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_01C19F5A.90FE9140
Content-Type: text/plain;
	charset="windows-1255"

I agree with you on the technical part. I think we still argue on the
business rationalization.
Yaron

 -----Original Message-----
From: 	sven.van_den_bosch@alcatel.be [mailto:sven.van_den_bosch@alcatel.be]

Sent:	Thursday, January 17, 2002 3:13 PM
To:	Yaron Kahana
Cc:	'Georgios Karagiannis (ELN)'; nsis@ietf.org
Subject:	RE: [NSIS] Two kinds of requirements

 << File: att1.htm >> Hi,

I don't think it is feasible in this case to aim for the solution that just
fits within the constraint. Every section will have to do the best it can
and cannot afford to "live off the others' sacrifices". I think this is
even the case for all but the last section in a setup procedure where all
sections support the QoS signalling request.

Sven.





Yaron Kahana <ykahana@comgates.co.il> on 17/01/2002 14:06:11
                                                              
                                                              
                                                              
  To:          "'Georgios Karagiannis (ELN)'"                 
               <Georgios.Karagiannis@eln.ericsson.se>         
                                                              
  cc:          nsis@ietf.org(bcc: Sven VAN DEN                
               BOSCH/BE/ALCATEL)                              
                                                              
                                                              
                                                              
  Subject      RE: [NSIS] Two kinds of requirements           
  :                                                           
                                                              





Hi,

Great. This however leads to the question of QoS metrics budgeting (like
what should be the required delay in domain A, B, and C, when B is not
supporting/processing the QoS signalling request).

Yaron
 .

-----Original Message-----
From: Georgios Karagiannis (ELN)
[mailto:Georgios.Karagiannis@eln.ericsson.se]
Sent: Thursday, January 17, 2002 3:00 PM
To: 'Yaron Kahana'
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements

Hi Yaron

The toolkit is a method of specifying which QoS requirements will impact
a certain node in an IP based network, not in an ATM or other kind of
networks.
If an IP domain supports overprovisioning then it would probably be useless
to process (check and use) the (future)  NSIS protocol within this domain.
I think that it should be allowed that nodes bypass (without checking and
using)
the NSIS protocol messages if required.

Best Regards,
Georgios




-----Original Message-----
From: Yaron Kahana [mailto:ykahana@comgates.co.il]
Sent: donderdag 17 januari 2002 13:47
To: 'Georgios Karagiannis (ELN)'
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements



Hi Georgios,

From what you are saying I understand that this toolkit request are
"passing
through" any domain. Will it be the case over ATM/FR/IPv4/IPv6?

Best Regards
Yaron

-----Original Message-----
From: Georgios Karagiannis (ELN) [
mailto:Georgios.Karagiannis@eln.ericsson.se
<mailto:Georgios.Karagiannis@eln.ericsson.se> ]
Sent: Thursday, January 17, 2002 2:35 PM
To: 'Yaron Kahana'
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements

Hi Yaron

Assuming that the domain in the middle supports over-provisioning the end
-to end QoS provisioning
could be satisfied.

Best Regards,
Georgios

-----Original Message-----
From: Yaro mailto:ykahana@comgates.co.il <mailto:ykahana@comgates.co.il> ]
Sent: donderdag 17 januari 2002 12:09
To: 'Georgios Karagiannis (ELN)'; Geib, Ruediger; 'Freytsis, Ilya'
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements



Hi,

I still don't see how such a toolkit can be useful if a certain domain in
the middle did not deployed a support in it and the Chicken and Egg
syndrome.

Yaron

-----Original Message-----
From: Georgios Karagiannis (ELN) [
mailto:Georgios.Karagiannis@eln.ericsson.se
<mailto:Georgios.Karagiannis@eln.ericsson.se>  <
mailto:Georgios.Karagiannis@eln.ericsson.se
<mailto:Georgios.Karagiannis@eln.ericsson.se> > ]

Sent: Thursday, January 17, 2002 12:04 PM
To: 'Yaron Kahana'; Geib, Ruediger; 'Freytsis, Ilya'
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements

Hi Yaron, Ilya, Ruediger

Almost all issues that you addressed in your e-mails can be solved (see
also
my previous e-mail
addressed to Dick) by first creating a modular QoS signaling toolkit that
will contain mandatory and
optional QoS requirements.
Second, specifying how the protocol functionality should be separated in
building blocks
(NSIS protocol components) and define a minimum set of mandatory
reservation
options/features
that should be processed by any network nodes, e.g., end-hosts, proxies,
edges and interior nodes.

Best Regards,
Georgios

-----Original Message-----
From: Yaron Kahana [ mailto:ykahana@comgates.co.il
<mailto:ykahana@comgates.co.il>  < mailto:ykahana@comgates.co.il
<mailto:ykahana@comgates.co.il> > ]
Sent: woensdag 16 januari 2002 22:16
To: brunner@ccrle.nec.de; Geib, Ruediger; dick.rr.knight@bt.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements



Hello Ruediger, Marcus,

I agree with your comments. One of the crucial elements is th

We should try to keep it simple, even on the expense of full flexibility.

By the way - did anyone considered the problem of a non-cooperative IP
domain "in the middle" ? for example, Suppose I'm making a call from Los
Angeles to Munich through 3 domains - LA-NY, NY-London, London-Munich. What
will happen if the best/cheapest carrier along the NY-London domain won't
support this new protocol? Will he be condemned/ignored? When will he
upgrade his infrastructure, before the chicke

Yaron Kahana
COGITO Project Manager,
COMGATES

 -----Original Message-----
From:   Marcus Brunner [ mailto:brunner@ccrle.nec.de
<mailto:brunner@ccrle.nec.de>  < mailto:brunner@ccrle.nec.de
<mailto:brunner@ccrle.nec.de> >  < mailto:brunner@ccrle.nec.de
<mailto:brunner@ccrle.nec.de>  < mailto:brunner@ccrle.nec.de
<mailto:brunner@ccrle.nec.de> > > ]

Sent:   Wednesday, January 16, 2002 5:35 PM
To:     Geib, Ruediger; dick.rr.knight@bt.com
Cc:     nsis@ietf.org
Subject:        RE: [NSIS] Two kinds of requirements

Ruediger,

The service needs to be defined anyway. Then there are IMO two
possibilities
- the provider defines the services and offers them. In this case the
provider needs to describe the offers in a machine readable form (most
likely with parameter names and values)
- the consumer requests a particular service (this means the consumer has
to describe the service he wants in a machine readable form)

So it seams one has to move around service specifications which are
understandable by the other party anyway, what is now your point? Is it
that you want to limit/fix as many parameters as possible? Or are you more
think about standardized services everybody understands?

Marcus

--On Wednesday, January 16, 2002 3:45 PM +0100 "Geib, Ruediger"
<Ruediger.Geib@t-systems.com> wrote:

> Hello Dick,
>
> your suggestion is quite reasonable. I also favour an architecture where
> a QoS request by and large is predefined in terms of the resources
> required from the available transport mechanism. Service specific
> parameters to be signaled during reservation should be strictly limited.
> The more mapping and evaluation of QoS parameters is required during
> reservation, the more complex the service gets. Complex services are hard
> to sell and hard to provide.
>
> Regards,
>
> R?diger
>
> R?diger Geib
> Senior Project Manager
> T-Systems Nova GmbH
>
>> I think that what is needed is a new protocol that can signal the

(See attached file: att1.htm)


------_=_NextPart_001_01C19F5A.90FE9140
Content-Type: text/html;
	charset="windows-1255"
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=3Dwindows-1255">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>RE: [NSIS] Two kinds of requirements</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>I agree with you on the technical part. I think we =
still argue on the business rationalization.</FONT>
<BR><FONT SIZE=3D2>Yaron</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: &nbsp; sven.van_den_bosch@alcatel.be [<A =
HREF=3D"mailto:sven.van_den_bosch@alcatel.be">mailto:sven.van_den_bosch@=
alcatel.be</A>] </FONT>
<BR><FONT SIZE=3D2>Sent:&nbsp;&nbsp; Thursday, January 17, 2002 3:13 =
PM</FONT>
<BR><FONT SIZE=3D2>To:&nbsp;&nbsp;&nbsp;&nbsp; Yaron Kahana</FONT>
<BR><FONT SIZE=3D2>Cc:&nbsp;&nbsp;&nbsp;&nbsp; 'Georgios Karagiannis =
(ELN)'; nsis@ietf.org</FONT>
<BR><FONT SIZE=3D2>Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
RE: [NSIS] Two kinds of requirements</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&lt;&lt; File: att1.htm &gt;&gt; Hi,</FONT>
</P>

<P><FONT SIZE=3D2>I don't think it is feasible in this case to aim for =
the solution that just</FONT>
<BR><FONT SIZE=3D2>fits within the constraint. Every section will have =
to do the best it can</FONT>
<BR><FONT SIZE=3D2>and cannot afford to &quot;live off the others' =
sacrifices&quot;. I think this is</FONT>
<BR><FONT SIZE=3D2>even the case for all but the last section in a =
setup procedure where all</FONT>
<BR><FONT SIZE=3D2>sections support the QoS signalling request.</FONT>
</P>

<P><FONT SIZE=3D2>Sven.</FONT>
</P>
<BR>
<BR>
<BR>
<BR>

<P><FONT SIZE=3D2>Yaron Kahana &lt;ykahana@comgates.co.il&gt; on =
17/01/2002 14:06:11</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; </FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; </FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&nbsp; =
To:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&quot;'Georgios Karagiannis =
(ELN)'&quot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp; =
&lt;Georgios.Karagiannis@eln.ericsson.se&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&nbsp; =
cc:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
nsis@ietf.org(bcc: Sven VAN =
DEN&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp; =
BOSCH/BE/ALCATEL)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; </FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; </FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&nbsp; Subject&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; RE: =
[NSIS] Two kinds of =
requirements&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 </FONT>
<BR><FONT SIZE=3D2>&nbsp; =
:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; </FONT>
</P>
<BR>
<BR>
<BR>
<BR>

<P><FONT SIZE=3D2>Hi,</FONT>
</P>

<P><FONT SIZE=3D2>Great. This however leads to the question of QoS =
metrics budgeting (like</FONT>
<BR><FONT SIZE=3D2>what should be the required delay in domain A, B, =
and C, when B is not</FONT>
<BR><FONT SIZE=3D2>supporting/processing the QoS signalling =
request).</FONT>
</P>

<P><FONT SIZE=3D2>Yaron</FONT>
<BR><FONT SIZE=3D2>&nbsp;.</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Georgios Karagiannis (ELN)</FONT>
<BR><FONT SIZE=3D2>[<A =
HREF=3D"mailto:Georgios.Karagiannis@eln.ericsson.se">mailto:Georgios.Kar=
agiannis@eln.ericsson.se</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Thursday, January 17, 2002 3:00 PM</FONT>
<BR><FONT SIZE=3D2>To: 'Yaron Kahana'</FONT>
<BR><FONT SIZE=3D2>Cc: nsis@ietf.org</FONT>
<BR><FONT SIZE=3D2>Subject: RE: [NSIS] Two kinds of requirements</FONT>
</P>

<P><FONT SIZE=3D2>Hi Yaron</FONT>
</P>

<P><FONT SIZE=3D2>The toolkit is a method of specifying which QoS =
requirements will impact</FONT>
<BR><FONT SIZE=3D2>a certain node in an IP based network, not in an ATM =
or other kind of</FONT>
<BR><FONT SIZE=3D2>networks.</FONT>
<BR><FONT SIZE=3D2>If an IP domain supports overprovisioning then it =
would probably be useless</FONT>
<BR><FONT SIZE=3D2>to process (check and use) the (future)&nbsp; NSIS =
protocol within this domain.</FONT>
<BR><FONT SIZE=3D2>I think that it should be allowed that nodes bypass =
(without checking and</FONT>
<BR><FONT SIZE=3D2>using)</FONT>
<BR><FONT SIZE=3D2>the NSIS protocol messages if required.</FONT>
</P>

<P><FONT SIZE=3D2>Best Regards,</FONT>
<BR><FONT SIZE=3D2>Georgios</FONT>
</P>
<BR>
<BR>
<BR>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Yaron Kahana [<A =
HREF=3D"mailto:ykahana@comgates.co.il">mailto:ykahana@comgates.co.il</A>=
]</FONT>
<BR><FONT SIZE=3D2>Sent: donderdag 17 januari 2002 13:47</FONT>
<BR><FONT SIZE=3D2>To: 'Georgios Karagiannis (ELN)'</FONT>
<BR><FONT SIZE=3D2>Cc: nsis@ietf.org</FONT>
<BR><FONT SIZE=3D2>Subject: RE: [NSIS] Two kinds of requirements</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>Hi Georgios,</FONT>
</P>

<P><FONT SIZE=3D2>From what you are saying I understand that this =
toolkit request are</FONT>
<BR><FONT SIZE=3D2>&quot;passing</FONT>
<BR><FONT SIZE=3D2>through&quot; any domain. Will it be the case over =
ATM/FR/IPv4/IPv6?</FONT>
</P>

<P><FONT SIZE=3D2>Best Regards</FONT>
<BR><FONT SIZE=3D2>Yaron</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Georgios Karagiannis (ELN) [</FONT>
<BR><FONT SIZE=3D2><A =
HREF=3D"mailto:Georgios.Karagiannis@eln.ericsson.se">mailto:Georgios.Kar=
agiannis@eln.ericsson.se</A></FONT>
<BR><FONT SIZE=3D2>&lt;<A =
HREF=3D"mailto:Georgios.Karagiannis@eln.ericsson.se">mailto:Georgios.Kar=
agiannis@eln.ericsson.se</A>&gt; ]</FONT>
<BR><FONT SIZE=3D2>Sent: Thursday, January 17, 2002 2:35 PM</FONT>
<BR><FONT SIZE=3D2>To: 'Yaron Kahana'</FONT>
<BR><FONT SIZE=3D2>Cc: nsis@ietf.org</FONT>
<BR><FONT SIZE=3D2>Subject: RE: [NSIS] Two kinds of requirements</FONT>
</P>

<P><FONT SIZE=3D2>Hi Yaron</FONT>
</P>

<P><FONT SIZE=3D2>Assuming that the domain in the middle supports =
over-provisioning the end</FONT>
<BR><FONT SIZE=3D2>-to end QoS provisioning</FONT>
<BR><FONT SIZE=3D2>could be satisfied.</FONT>
</P>

<P><FONT SIZE=3D2>Best Regards,</FONT>
<BR><FONT SIZE=3D2>Georgios</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Yaro <A =
HREF=3D"mailto:ykahana@comgates.co.il">mailto:ykahana@comgates.co.il</A>=
 &lt;<A =
HREF=3D"mailto:ykahana@comgates.co.il">mailto:ykahana@comgates.co.il</A>=
&gt; ]</FONT>
<BR><FONT SIZE=3D2>Sent: donderdag 17 januari 2002 12:09</FONT>
<BR><FONT SIZE=3D2>To: 'Georgios Karagiannis (ELN)'; Geib, Ruediger; =
'Freytsis, Ilya'</FONT>
<BR><FONT SIZE=3D2>Cc: nsis@ietf.org</FONT>
<BR><FONT SIZE=3D2>Subject: RE: [NSIS] Two kinds of requirements</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>Hi,</FONT>
</P>

<P><FONT SIZE=3D2>I still don't see how such a toolkit can be useful if =
a certain domain in</FONT>
<BR><FONT SIZE=3D2>the middle did not deployed a support in it and the =
Chicken and Egg</FONT>
<BR><FONT SIZE=3D2>syndrome.</FONT>
</P>

<P><FONT SIZE=3D2>Yaron</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Georgios Karagiannis (ELN) [</FONT>
<BR><FONT SIZE=3D2><A =
HREF=3D"mailto:Georgios.Karagiannis@eln.ericsson.se">mailto:Georgios.Kar=
agiannis@eln.ericsson.se</A></FONT>
<BR><FONT SIZE=3D2>&lt;<A =
HREF=3D"mailto:Georgios.Karagiannis@eln.ericsson.se">mailto:Georgios.Kar=
agiannis@eln.ericsson.se</A>&gt;&nbsp; &lt;</FONT>
<BR><FONT SIZE=3D2><A =
HREF=3D"mailto:Georgios.Karagiannis@eln.ericsson.se">mailto:Georgios.Kar=
agiannis@eln.ericsson.se</A></FONT>
<BR><FONT SIZE=3D2>&lt;<A =
HREF=3D"mailto:Georgios.Karagiannis@eln.ericsson.se">mailto:Georgios.Kar=
agiannis@eln.ericsson.se</A>&gt; &gt; ]</FONT>
</P>

<P><FONT SIZE=3D2>Sent: Thursday, January 17, 2002 12:04 PM</FONT>
<BR><FONT SIZE=3D2>To: 'Yaron Kahana'; Geib, Ruediger; 'Freytsis, =
Ilya'</FONT>
<BR><FONT SIZE=3D2>Cc: nsis@ietf.org</FONT>
<BR><FONT SIZE=3D2>Subject: RE: [NSIS] Two kinds of requirements</FONT>
</P>

<P><FONT SIZE=3D2>Hi Yaron, Ilya, Ruediger</FONT>
</P>

<P><FONT SIZE=3D2>Almost all issues that you addressed in your e-mails =
can be solved (see</FONT>
<BR><FONT SIZE=3D2>also</FONT>
<BR><FONT SIZE=3D2>my previous e-mail</FONT>
<BR><FONT SIZE=3D2>addressed to Dick) by first creating a modular QoS =
signaling toolkit that</FONT>
<BR><FONT SIZE=3D2>will contain mandatory and</FONT>
<BR><FONT SIZE=3D2>optional QoS requirements.</FONT>
<BR><FONT SIZE=3D2>Second, specifying how the protocol functionality =
should be separated in</FONT>
<BR><FONT SIZE=3D2>building blocks</FONT>
<BR><FONT SIZE=3D2>(NSIS protocol components) and define a minimum set =
of mandatory</FONT>
<BR><FONT SIZE=3D2>reservation</FONT>
<BR><FONT SIZE=3D2>options/features</FONT>
<BR><FONT SIZE=3D2>that should be processed by any network nodes, e.g., =
end-hosts, proxies,</FONT>
<BR><FONT SIZE=3D2>edges and interior nodes.</FONT>
</P>

<P><FONT SIZE=3D2>Best Regards,</FONT>
<BR><FONT SIZE=3D2>Georgios</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Yaron Kahana [ <A =
HREF=3D"mailto:ykahana@comgates.co.il">mailto:ykahana@comgates.co.il</A>=
</FONT>
<BR><FONT SIZE=3D2>&lt;<A =
HREF=3D"mailto:ykahana@comgates.co.il">mailto:ykahana@comgates.co.il</A>=
&gt;&nbsp; &lt; <A =
HREF=3D"mailto:ykahana@comgates.co.il">mailto:ykahana@comgates.co.il</A>=
</FONT>
<BR><FONT SIZE=3D2>&lt;<A =
HREF=3D"mailto:ykahana@comgates.co.il">mailto:ykahana@comgates.co.il</A>=
&gt; &gt; ]</FONT>
<BR><FONT SIZE=3D2>Sent: woensdag 16 januari 2002 22:16</FONT>
<BR><FONT SIZE=3D2>To: brunner@ccrle.nec.de; Geib, Ruediger; =
dick.rr.knight@bt.com</FONT>
<BR><FONT SIZE=3D2>Cc: nsis@ietf.org</FONT>
<BR><FONT SIZE=3D2>Subject: RE: [NSIS] Two kinds of requirements</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>Hello Ruediger, Marcus,</FONT>
</P>

<P><FONT SIZE=3D2>I agree with your comments. One of the crucial =
elements is th</FONT>
</P>

<P><FONT SIZE=3D2>We should try to keep it simple, even on the expense =
of full flexibility.</FONT>
</P>

<P><FONT SIZE=3D2>By the way - did anyone considered the problem of a =
non-cooperative IP</FONT>
<BR><FONT SIZE=3D2>domain &quot;in the middle&quot; ? for example, =
Suppose I'm making a call from Los</FONT>
<BR><FONT SIZE=3D2>Angeles to Munich through 3 domains - LA-NY, =
NY-London, London-Munich. What</FONT>
<BR><FONT SIZE=3D2>will happen if the best/cheapest carrier along the =
NY-London domain won't</FONT>
<BR><FONT SIZE=3D2>support this new protocol? Will he be =
condemned/ignored? When will he</FONT>
<BR><FONT SIZE=3D2>upgrade his infrastructure, before the chicke</FONT>
</P>

<P><FONT SIZE=3D2>Yaron Kahana</FONT>
<BR><FONT SIZE=3D2>COGITO Project Manager,</FONT>
<BR><FONT SIZE=3D2>COMGATES</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From:&nbsp;&nbsp; Marcus Brunner [ <A =
HREF=3D"mailto:brunner@ccrle.nec.de">mailto:brunner@ccrle.nec.de</A></FO=
NT>
<BR><FONT SIZE=3D2>&lt;<A =
HREF=3D"mailto:brunner@ccrle.nec.de">mailto:brunner@ccrle.nec.de</A>&gt;=
&nbsp; &lt; <A =
HREF=3D"mailto:brunner@ccrle.nec.de">mailto:brunner@ccrle.nec.de</A></FO=
NT>
<BR><FONT SIZE=3D2>&lt;<A =
HREF=3D"mailto:brunner@ccrle.nec.de">mailto:brunner@ccrle.nec.de</A>&gt;=
 &gt;&nbsp; &lt; <A =
HREF=3D"mailto:brunner@ccrle.nec.de">mailto:brunner@ccrle.nec.de</A></FO=
NT>
<BR><FONT SIZE=3D2>&lt;<A =
HREF=3D"mailto:brunner@ccrle.nec.de">mailto:brunner@ccrle.nec.de</A>&gt;=
&nbsp; &lt; <A =
HREF=3D"mailto:brunner@ccrle.nec.de">mailto:brunner@ccrle.nec.de</A></FO=
NT>
<BR><FONT SIZE=3D2>&lt;<A =
HREF=3D"mailto:brunner@ccrle.nec.de">mailto:brunner@ccrle.nec.de</A>&gt;=
 &gt; &gt; ]</FONT>
</P>

<P><FONT SIZE=3D2>Sent:&nbsp;&nbsp; Wednesday, January 16, 2002 5:35 =
PM</FONT>
<BR><FONT SIZE=3D2>To:&nbsp;&nbsp;&nbsp;&nbsp; Geib, Ruediger; =
dick.rr.knight@bt.com</FONT>
<BR><FONT SIZE=3D2>Cc:&nbsp;&nbsp;&nbsp;&nbsp; nsis@ietf.org</FONT>
<BR><FONT SIZE=3D2>Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
RE: [NSIS] Two kinds of requirements</FONT>
</P>

<P><FONT SIZE=3D2>Ruediger,</FONT>
</P>

<P><FONT SIZE=3D2>The service needs to be defined anyway. Then there =
are IMO two</FONT>
<BR><FONT SIZE=3D2>possibilities</FONT>
<BR><FONT SIZE=3D2>- the provider defines the services and offers them. =
In this case the</FONT>
<BR><FONT SIZE=3D2>provider needs to describe the offers in a machine =
readable form (most</FONT>
<BR><FONT SIZE=3D2>likely with parameter names and values)</FONT>
<BR><FONT SIZE=3D2>- the consumer requests a particular service (this =
means the consumer has</FONT>
<BR><FONT SIZE=3D2>to describe the service he wants in a machine =
readable form)</FONT>
</P>

<P><FONT SIZE=3D2>So it seams one has to move around service =
specifications which are</FONT>
<BR><FONT SIZE=3D2>understandable by the other party anyway, what is =
now your point? Is it</FONT>
<BR><FONT SIZE=3D2>that you want to limit/fix as many parameters as =
possible? Or are you more</FONT>
<BR><FONT SIZE=3D2>think about standardized services everybody =
understands?</FONT>
</P>

<P><FONT SIZE=3D2>Marcus</FONT>
</P>

<P><FONT SIZE=3D2>--On Wednesday, January 16, 2002 3:45 PM +0100 =
&quot;Geib, Ruediger&quot;</FONT>
<BR><FONT SIZE=3D2>&lt;Ruediger.Geib@t-systems.com&gt; wrote:</FONT>
</P>

<P><FONT SIZE=3D2>&gt; Hello Dick,</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; your suggestion is quite reasonable. I also =
favour an architecture where</FONT>
<BR><FONT SIZE=3D2>&gt; a QoS request by and large is predefined in =
terms of the resources</FONT>
<BR><FONT SIZE=3D2>&gt; required from the available transport =
mechanism. Service specific</FONT>
<BR><FONT SIZE=3D2>&gt; parameters to be signaled during reservation =
should be strictly limited.</FONT>
<BR><FONT SIZE=3D2>&gt; The more mapping and evaluation of QoS =
parameters is required during</FONT>
<BR><FONT SIZE=3D2>&gt; reservation, the more complex the service gets. =
Complex services are hard</FONT>
<BR><FONT SIZE=3D2>&gt; to sell and hard to provide.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; Regards,</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; R?diger</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; R?diger Geib</FONT>
<BR><FONT SIZE=3D2>&gt; Senior Project Manager</FONT>
<BR><FONT SIZE=3D2>&gt; T-Systems Nova GmbH</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; I think that what is needed is a new =
protocol that can signal the</FONT>
</P>

<P><FONT SIZE=3D2>(See attached file: att1.htm)</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C19F5A.90FE9140--

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



From daemon@optimus.ietf.org  Thu Jan 17 09:32: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 JAA16588
	for <nsis-archive@odin.ietf.org>; Thu, 17 Jan 2002 09:32:49 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id JAA04245
	for nsis-archive@odin.ietf.org; Thu, 17 Jan 2002 09:32: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 JAA04015;
	Thu, 17 Jan 2002 09:31:00 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA03944
	for <nsis@optimus.ietf.org>; Thu, 17 Jan 2002 09:30:56 -0500 (EST)
Received: from kcmso1.proxy.att.com (kcmso1.att.com [192.128.133.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16501
	for <nsis@ietf.org>; Thu, 17 Jan 2002 09:30:48 -0500 (EST)
Received: from attrh1i.attrh.att.com ([135.71.62.10])
	by kcmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id g0HEU6n10259
	for <nsis@ietf.org>; Thu, 17 Jan 2002 09:30:09 -0500 (EST)
Received: from occlust04evs1.ugd.att.com (135.71.164.12) by attrh1i.attrh.att.com (5.5.029)
        id 3C0BA3A500215C48; Thu, 17 Jan 2002 09:29:31 -0500
content-class: urn:content-classes:message
Subject: RE: [NSIS] Two kinds of requirements
Date: Thu, 17 Jan 2002 09:29:31 -0500
Message-ID: <62DA45D4963FA747BA1B253E266760F9011E6D81@OCCLUST04EVS1.ugd.att.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Thread-Topic: [NSIS] Two kinds of requirements
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
Thread-Index: AcGfS3R13Rdmjgs4EdazmACQJ2FUNwAFhB2A
From: "Roy, Radhika R, ALASO" <rrroy@att.com>
To: "Loughney John (NRC/Helsinki)" <john.loughney@nokia.com>,
        "ext Georgios Karagiannis (ELN)" <Georgios.Karagiannis@eln.ericsson.se>
Cc: <nsis@ietf.org>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id JAA03945
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

Inputs are inline [RRR]

-----Original Message-----
From: Loughney John (NRC/Helsinki) [mailto:john.loughney@nokia.com]
Sent: Thursday, January 17, 2002 6:27 AM
To: 'ext Georgios Karagiannis (ELN)'
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


Hi Georgios,

> In the "analysis draft" located at the following URL, 
> a "brief" analysis, in the context of NSIS, of RFC2998
> is made.

Brief is correct.  My suggest was that we should look
at 2998 and see if we can apply RSVP to more than
just DiffServ / Intserv.  That is one of the primary 
tasks of this working group.

[RRR] After analyzing RFC 2998, probably, we may have to consider a two-step process: 1. End-to-end application layer QOS signaling (that is independent of the lower network layer technologies) protocol and 2. Implementation of the end-to-end QOS over the lower network layer (using single or multiple QOS signaling schemes [RSVP, DiffServ, MPLS, or others if any]) for resource reservation or provisioning.

[RRR] Definition of interactions between steps 1 and 2 will be a crucial part in defining the standard as well.


John

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

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



From daemon@optimus.ietf.org  Thu Jan 17 09:40: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 JAA16866
	for <nsis-archive@odin.ietf.org>; Thu, 17 Jan 2002 09:40:17 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id JAA04450
	for nsis-archive@odin.ietf.org; Thu, 17 Jan 2002 09:40: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 JAA03625;
	Thu, 17 Jan 2002 09:25: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 JAA03596
	for <nsis@optimus.ietf.org>; Thu, 17 Jan 2002 09:25:32 -0500 (EST)
Received: from albatross-ext.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 JAA16361
	for <nsis@ietf.org>; Thu, 17 Jan 2002 09:25:27 -0500 (EST)
Received: from mbb5.ericsson.se (mbb5.ericsson.se [136.225.151.210])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id g0HEPSJ08229
	for <nsis@ietf.org>; Thu, 17 Jan 2002 15:25:28 +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 <0GQ3000H16QGTD@mbb1.ericsson.se> for nsis@ietf.org; Thu,
 17 Jan 2002 15:25:28 +0100 (MET)
Date: Thu, 17 Jan 2002 16:25:27 +0100
From: David Partain <David.Partain@ericsson.com>
Subject: Re: [NSIS] Two kinds of requirements
In-reply-to: <0C1353ABB1DEB74DB067ADFF749C4EEF5D937C@esebe004.NOE.Nokia.com>
To: "Loughney John (NRC/Helsinki)" <john.loughney@nokia.com>,
        "'ext Georgios Karagiannis (ELN)'" <Georgios.Karagiannis@eln.ericsson.se>
Cc: nsis@ietf.org
Reply-to: David.Partain@ericsson.com
Message-id: <0GQ3000H26QGTD@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: <0C1353ABB1DEB74DB067ADFF749C4EEF5D937C@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,

> > By mandatory, I mean, requirements that MUST be supported
> > (used) by a node and optional are requirements that
> > MAY be supported by a node!
>
> If it is optional, then it is not required.

I think we're getting wrapped around the axle a bit.  What I
think Georgios means is that there are environments where a
certain kind of feature make sense and is considered mandatory.
There are others where that same feature would be considered
a waste of memory and cpu cycles.  I think we need to get
away from the discussion about words being used to describe
this issue.  I believe the issue certainly exists, and it
would be best if what we are working on allows us to have
"domain-specific features" and the "everyone-has it features".
If we don't do this, then vendors are certain to invent
non-standard ways to have their "domain-specific features".
That wouldn't be good.

Cheers,

-- 
David Partain                  David.Partain@ericsson.com
Ericsson Research's LinLab     Tel: +46 13 28 41 44
P.O. Box 1248                  Fax: +46 13 28 75 67
SE-581 12 Linköping, Sweden    #include <stddisclaimer.h>

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



From daemon@ns.ietf.org  Thu Jan 17 09:44: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 JAA17184
	for <nsis-archive@odin.ietf.org>; Thu, 17 Jan 2002 09:44:48 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id JAA04572
	for nsis-archive@odin.ietf.org; Thu, 17 Jan 2002 09:44: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 JAA04314;
	Thu, 17 Jan 2002 09:33: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 JAA04279
	for <nsis@optimus.ietf.org>; Thu, 17 Jan 2002 09:33:45 -0500 (EST)
Received: from kcmso1.proxy.att.com (kcmso1.att.com [192.128.133.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16622
	for <nsis@ietf.org>; Thu, 17 Jan 2002 09:33:40 -0500 (EST)
Received: from attrh1i.attrh.att.com ([135.71.62.10])
	by kcmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id g0HEXAn12218
	for <nsis@ietf.org>; Thu, 17 Jan 2002 09:33:11 -0500 (EST)
Received: from occlust04evs1.ugd.att.com (135.71.164.12) by attrh1i.attrh.att.com (5.5.029)
        id 3C0BA3A500215DC7; Thu, 17 Jan 2002 09:32:57 -0500
content-class: urn:content-classes:message
Subject: RE: [NSIS] Two kinds of requirements
Date: Thu, 17 Jan 2002 09:32:58 -0500
Message-ID: <62DA45D4963FA747BA1B253E266760F9011E6D8C@OCCLUST04EVS1.ugd.att.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Thread-Topic: [NSIS] Two kinds of requirements
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
Thread-Index: AcGfIQl2GpGBnAsMEdaSygAAwCUaDwAQjvqw
From: "Roy, Radhika R, ALASO" <rrroy@att.com>
To: "Loughney John (NRC/Helsinki)" <john.loughney@nokia.com>
Cc: <nsis@ietf.org>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id JAA04280
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

Inputs inline [RRR]

-----Original Message-----
From: Loughney John (NRC/Helsinki) [mailto:john.loughney@nokia.com]
Sent: Thursday, January 17, 2002 1:35 AM
To: Roy, Radhika R, ALASO
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


Hi Radhika,

> I think this was adequately addressed in RFC 2998, ``A Framework for 
> Integrated Services Operation over Diffserv Networks'' by Bernet, et 
> al.
> 
> [RRR] It is a good point. If we look into RFC 2998, we will 
> see that it will provide a good insight to develop our 
> end-to-end application layer QOS (generic) signaling 
> protocol. What we need to do to make it evolve in such a way 
> that the end-to-end QOS signaling will be able satisfy any 
> combinations of network layer QOS that has been implemented 
> using RSVP, DiffServ, MPLS, and/or other means while testing 
> RFC 2998's end-to-end scheme as one of the implementation schemes.

What would be good to do is document if something like RFC 2998 
can be expanded / extended / (reduced?) so that it supports
different combos of network layer QoS.

[RRR] You are right. It will be a good starting point.

best regards,
John

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



From daemon@ns.ietf.org  Thu Jan 17 09:50: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 JAA17546
	for <nsis-archive@odin.ietf.org>; Thu, 17 Jan 2002 09:50:39 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id JAA04747
	for nsis-archive@odin.ietf.org; Thu, 17 Jan 2002 09:50: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 JAA04706;
	Thu, 17 Jan 2002 09:48: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 JAA04677
	for <nsis@ns.ietf.org>; Thu, 17 Jan 2002 09:48:53 -0500 (EST)
Received: from almso1.proxy.att.com (almso1.att.com [192.128.167.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17491
	for <nsis@ietf.org>; Thu, 17 Jan 2002 09:48:49 -0500 (EST)
Received: from attrh1i.attrh.att.com ([135.71.62.10])
	by almso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id g0HEmIW27969
	for <nsis@ietf.org>; Thu, 17 Jan 2002 09:48:19 -0500 (EST)
Received: from occlust04evs1.ugd.att.com (135.71.164.12) by attrh1i.attrh.att.com (5.5.029)
        id 3C0BA3A5002163FD; Thu, 17 Jan 2002 09:47:28 -0500
content-class: urn:content-classes:message
Subject: RE: [NSIS] Two kinds of requirements
Date: Thu, 17 Jan 2002 09:47:28 -0500
Message-ID: <62DA45D4963FA747BA1B253E266760F9011E6DBC@OCCLUST04EVS1.ugd.att.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Thread-Topic: [NSIS] Two kinds of requirements
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
Thread-Index: AcGfWST8/jw14AtLEdaSygAAwCUaDwAC4Dbg
From: "Roy, Radhika R, ALASO" <rrroy@att.com>
To: <sven.van_den_bosch@alcatel.be>, "Yaron Kahana" <ykahana@comgates.co.il>
Cc: "Georgios Karagiannis (ELN)" <Georgios.Karagiannis@eln.ericsson.se>,
        <nsis@ietf.org>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id JAA04678
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

Comments inline [RRR]

-----Original Message-----
From: sven.van_den_bosch@alcatel.be
[mailto:sven.van_den_bosch@alcatel.be]
Sent: Thursday, January 17, 2002 8:13 AM
To: Yaron Kahana
Cc: 'Georgios Karagiannis (ELN)'; nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


Hi,

I don't think it is feasible in this case to aim for the solution that just
fits within the constraint. Every section will have to do the best it can
and cannot afford to "live off the others' sacrifices". I think this is
even the case for all but the last section in a setup procedure where all
sections support the QoS signalling request.

[RRR] I guess that it will be the lowest COMMON denominator of QOS among all domains {[domain 1][domain 2] ..[domain N]}. That is, if any domain in the end-to-end path offers the best-effort service, then the best-effort service will be the one that has to be accepted on end-to-end basis and it cannot be better than this.

Sven.






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



From daemon@ns.ietf.org  Thu Jan 17 09:55:25 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17695
	for <nsis-archive@odin.ietf.org>; Thu, 17 Jan 2002 09:55:25 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id JAA04866
	for nsis-archive@odin.ietf.org; Thu, 17 Jan 2002 09:55: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 JAA04840;
	Thu, 17 Jan 2002 09:53: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 JAA04807
	for <nsis@ns.ietf.org>; Thu, 17 Jan 2002 09:53:49 -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 JAA17658
	for <nsis@ietf.org>; Thu, 17 Jan 2002 09:53:45 -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 g0HEtpT02194;
	Thu, 17 Jan 2002 08:55:51 -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 g0HEr3h28126;
	Thu, 17 Jan 2002 08:53:03 -0600 (CST)
Received: by TRIMAIL2.ad.tri.sbc.com with Internet Mail Service (5.5.2653.19)
	id <ZND32FLV>; Thu, 17 Jan 2002 08:53:30 -0600
Message-ID: <905A1C4ABF353F4C8CC16FA9F53DD0D632241D@TRIMAIL2.ad.tri.sbc.com>
From: "Chen, Weijing" <wchen@tri.sbc.com>
To: "'Georgios Karagiannis (ELN)'" <Georgios.Karagiannis@eln.ericsson.se>
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements
Date: Thu, 17 Jan 2002 08:53:30 -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

Georgois,

Regarding the modularization of signaling protocol, I think that the
following is more close to what we want:

[host] <-----NSIS signaling------>[edge]
....1...[core]....2...[core]....1...[edge]<---NSIS signaling---->[host]

1 and 2 could be over-provisioning, CoS routing, MPLS tunnel, ATM
connection, etc. The main objective is to keep NSIS signaling simple and
widespread implementable, and independent of what core uses. 

--
Weijing Chen
SBC Technology Resources
9505 Arboretum Blvd.
Austin, TX 78759
512 372 5710
wchen@tri.sbc.com



 -----Original Message-----
From: 	Georgios Karagiannis (ELN)
[mailto:Georgios.Karagiannis@eln.ericsson.se] 
Sent:	Thursday, January 17, 2002 3:39 AM
To:	'dick.rr.knight@bt.com'
Cc:	nsis@ietf.org
Subject:	RE: [NSIS] Two kinds of requirements

Hi Dick 

In principle I agree with your comment (see below).

[DK] >> To be more precise, I am suggesting a new protocol that is 
[DK] >> independent of the underlying transport technology and the QoS 
[DK] >> implemented and is also independent of the session control protocol.


However, a very important point here is that we need to 
specify a protocol that can be used independent of the underlying transport 
technology, but that can satisfy the QoS requirements imposed by these 
underlying transport technologies. Otherwise the protocol will not be
suitable
and useful.

A way of achieving this is by first creating a modular QoS signaling toolkit

that will contain mandatory and optional QoS requirements;
Second, specify how the protocol functionality should be separated in 
building blocks (protocol components) and define a minimum set 
of mandatory reservation options/features that should be 
processed by any network nodes, e.g., end-hosts,
proxies, edges and interior nodes.
An example of such a protocol decomposition is given below!
In this way each node will only process (check and use) the protocol 
components of interest.


|---------|
|---------|
|everyhost|<------------------------------------------------------->|everyho
st|
|---------|
|---------|
|         |                                                         |
|
|---------|   |---------|                             |---------|
|---------|
|everyedge|<->|everyedge|<--------------------------->|everyedge|<->|everyed
ge|
|---------|   |---------|                             |---------|
|---------|
|         |   |         |                             |         |   |
|
|---------|   |---------|   |--------|   |--------|   |---------|
|---------|
|everyhop |<->|everyhop |<->|everyhop|<->|everyhop|<->|everyhop
|<->|everyhop |
|---------|   |---------|   |--------|   |--------|   |---------|
|---------| 
    host          edge        interior    interior       edge          host


  NSIS protocol decomposition (building blocks): 
 *  "everyhost", "everyedge" and "everyhop" are protocol components;
 *  host: can be an end-host or a proxy and it can process and use the
"everyhost", 
    "everyedge", and "everyhop" protocol components;

 *  edge: can be a Diffserv edge, MPLS edge, etc., and it can process and
use 
    the "everyedge", and "everyhop" protocol components. The "everyhost" 
    protocol component is not processed (used or checked);

 *  interior: can be any router within a domain and it can process and use 
    only the "everyhop" protocol component.
    The "everyhost" and "everyedge" protocol components are not 
    processed (used or checked);


Best Regards,
Georgios

-----Original Message-----
From: dick.rr.knight@bt.com [mailto:dick.rr.knight@bt.com]
Sent: woensdag 16 januari 2002 13:00
To: brian.williams@ericsson.com.au; lieve.bos@alcatel.be
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


I was waiting for some reaction to Brian's comments, but as there aren't
any, here are my thoughts on the requirements:

I agree with the analysis that discussion has been based around
application-related signalling for QoS (at session level) and QoS signalling
protocols used to actually provision the QoS at the transport level.
Brian is right that there will never be an enhancement to a single session
protocol that will satisfy all applications.
However, for similar reasons, it is never going to be possible to prescribe
a single QoS mechanism to be used in all networks. Existing networks (or
domains) will not be changed overnight and new networks already face several
workable mechanisms to deploy QoS.

I think that what is needed is a new protocol that can signal the
requirements of any session and can be satisfied by any QoS mechanism,
existing or new.
To be more precise, I am suggesting a new protocol that is independent of
the underlying transport technology and the QoS implemented and is also
independent of the session control protocol. Such a new protocol would be
generic, optionally implemented by applications that would benefit from
end-to-end QoS, and would be complimentary to the QoS mechanisms deployed
(and of course other mechanisms, such as the routing).

I think that this implies a more abstract definition of the QoS mechanism
and may lend itself to the signalling of pre-defined QoS classes rather than
parameters.

Dick Knight

-----Original Message-----
From: Brian Williams [mailto:brian.williams@ericsson.com.au]
Sent: 22 December 2001 23:57
To: lieve.bos@alcatel.be
Cc: nsis@ietf.org
Subject: Re: [NSIS] Two kinds of requirements


Hi.
While the two types of signalling may be related, I think there is a
need to develop a QoS bearer mechanism which is independent of any
specific session signalling, and thus can be used for any application. I
believe many of the applications which have identified requirements to
the working group have their own specific session layer signalling (ie
it is not end-to-end SIP).  

Having the session and transport protocols developed separately of
course does not prohibit the two being used in conjunction for a
specific application.
/brian
 
On Fri, 2001-12-21 at 22:24, lieve.bos@alcatel.be wrote:
> Hello all,
> 
> >From the discussion in Salt Lake city and the drafts submitted, one can
> easily see that people are suggesting improvements to QoS signalling at
> two totally different levels (some at session level and some at
> transport level).
> 
> First of all, there are drafts suggesting some improvements in the
> session setup procedures (i.e. the ability to negotiate the preferred
> QoS level between end users during SDP negotiation in SIP, so before the
> actual resources are being setup). The QoS information negotiated at the
> session layer determines the QoS level both endusers have to use for 
> their local access connection. This first kind of 'session level QoS
> negotiation' happens end-to-end between the two end-users.
> 
> Secondly, there are drafts suggesting that we need
> improvements/alternatives for the QoS signalling protocols (e.g. RSVP)
> used to actually provision the QoS at the transport level between two
> endusers. This second kind of 'transport level QoS signalling' can
> consist of several phases: end-to-edge and edge-to-edge. 
> 
> It's important that everybody realises that, in order to give endusers
> true end-to-end Quality of Service, we need improvements for QoS both at
> session and transport level. Also its important to understand that they
> are not uncorrelated. Providers want to be able to control (e.g. via
> policy control mechanisms) that the QoS requested at the transport level
> is not exceeding the QoS negotiated/authorised previously at session
> level. So, what about developing in NSIS a modular framework
> incorporating both session and transport level QoS signalling with
> possible hooks between the two layers (e.g. for policy enforcement).
> 
> Lieve
> 
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis



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

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

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

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



From daemon@ns.ietf.org  Thu Jan 17 10:37:58 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19127
	for <nsis-archive@odin.ietf.org>; Thu, 17 Jan 2002 10:37:58 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id KAA06969
	for nsis-archive@odin.ietf.org; Thu, 17 Jan 2002 10:37: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 KAA06175;
	Thu, 17 Jan 2002 10:26: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 KAA06146
	for <nsis@ns.ietf.org>; Thu, 17 Jan 2002 10:26:54 -0500 (EST)
Received: from albatross-ext.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 KAA18701
	for <nsis@ietf.org>; Thu, 17 Jan 2002 10:26:51 -0500 (EST)
Received: from esealnt409.al.sw.ericsson.se (ESEALNT409.al.sw.ericsson.se [153.88.251.32])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g0HFQrJ08269
	for <nsis@ietf.org>; Thu, 17 Jan 2002 16:26:53 +0100 (MET)
Received: FROM esealnt746.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Thu Jan 17 16:26:52 2002 +0100
Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <YHLJLJNP>; Thu, 17 Jan 2002 16:26:52 +0100
Message-ID: <E244E44D6AB85E40AEEF7EAABE3545FA82336D@enleent104.nl.eu.ericsson.se>
From: "Georgios Karagiannis (ELN)" <Georgios.Karagiannis@eln.ericsson.se>
To: "'Chen, Weijing'" <wchen@tri.sbc.com>
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements
Date: Thu, 17 Jan 2002 16:26:49 +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 Weijing

Please note that the access network, i.e., the network between the 
[host] and [edge] will include [interior] nodes. 
These [interior] nodes will only process and use 
only the "everyhop" protocol component. 
The "everyhost" and "everyedge" protocol components are not 
processed (used or checked). I did not show this into the 
protocol decomposition figure that I sent (reply to Dick), 
but it should be there. 

Moreover, I agree that the QoS for 1 and 2 can be supported by
over-provisioning, MPLS tunnel, etc., 
but if needed it should also be supported by the NSIS signaling 
protocol.

Best Regards,
Georgios


-----Original Message-----
From: Chen, Weijing [mailto:wchen@tri.sbc.com]
Sent: donderdag 17 januari 2002 15:54
To: 'Georgios Karagiannis (ELN)'
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


Georgois,

Regarding the modularization of signaling protocol, I think that the
following is more close to what we want:

[host] <-----NSIS signaling------>[edge]
....1...[core]....2...[core]....1...[edge]<---NSIS signaling---->[host]

1 and 2 could be over-provisioning, CoS routing, MPLS tunnel, ATM
connection, etc. The main objective is to keep NSIS signaling simple and
widespread implementable, and independent of what core uses. 

--
Weijing Chen
SBC Technology Resources
9505 Arboretum Blvd.
Austin, TX 78759
512 372 5710
wchen@tri.sbc.com



 -----Original Message-----
From: 	Georgios Karagiannis (ELN)
[mailto:Georgios.Karagiannis@eln.ericsson.se] 
Sent:	Thursday, January 17, 2002 3:39 AM
To:	'dick.rr.knight@bt.com'
Cc:	nsis@ietf.org
Subject:	RE: [NSIS] Two kinds of requirements

Hi Dick 

In principle I agree with your comment (see below).

[DK] >> To be more precise, I am suggesting a new protocol that is 
[DK] >> independent of the underlying transport technology and the QoS 
[DK] >> implemented and is also independent of the session control protocol.


However, a very important point here is that we need to 
specify a protocol that can be used independent of the underlying transport 
technology, but that can satisfy the QoS requirements imposed by these 
underlying transport technologies. Otherwise the protocol will not be
suitable
and useful.

A way of achieving this is by first creating a modular QoS signaling toolkit

that will contain mandatory and optional QoS requirements;
Second, specify how the protocol functionality should be separated in 
building blocks (protocol components) and define a minimum set 
of mandatory reservation options/features that should be 
processed by any network nodes, e.g., end-hosts,
proxies, edges and interior nodes.
An example of such a protocol decomposition is given below!
In this way each node will only process (check and use) the protocol 
components of interest.


|---------|
|---------|
|everyhost|<------------------------------------------------------->|everyho
st|
|---------|
|---------|
|         |                                                         |
|
|---------|   |---------|                             |---------|
|---------|
|everyedge|<->|everyedge|<--------------------------->|everyedge|<->|everyed
ge|
|---------|   |---------|                             |---------|
|---------|
|         |   |         |                             |         |   |
|
|---------|   |---------|   |--------|   |--------|   |---------|
|---------|
|everyhop |<->|everyhop |<->|everyhop|<->|everyhop|<->|everyhop
|<->|everyhop |
|---------|   |---------|   |--------|   |--------|   |---------|
|---------| 
    host          edge        interior    interior       edge          host


  NSIS protocol decomposition (building blocks): 
 *  "everyhost", "everyedge" and "everyhop" are protocol components;
 *  host: can be an end-host or a proxy and it can process and use the
"everyhost", 
    "everyedge", and "everyhop" protocol components;

 *  edge: can be a Diffserv edge, MPLS edge, etc., and it can process and
use 
    the "everyedge", and "everyhop" protocol components. The "everyhost" 
    protocol component is not processed (used or checked);

 *  interior: can be any router within a domain and it can process and use 
    only the "everyhop" protocol component.
    The "everyhost" and "everyedge" protocol components are not 
    processed (used or checked);


Best Regards,
Georgios

-----Original Message-----
From: dick.rr.knight@bt.com [mailto:dick.rr.knight@bt.com]
Sent: woensdag 16 januari 2002 13:00
To: brian.williams@ericsson.com.au; lieve.bos@alcatel.be
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


I was waiting for some reaction to Brian's comments, but as there aren't
any, here are my thoughts on the requirements:

I agree with the analysis that discussion has been based around
application-related signalling for QoS (at session level) and QoS signalling
protocols used to actually provision the QoS at the transport level.
Brian is right that there will never be an enhancement to a single session
protocol that will satisfy all applications.
However, for similar reasons, it is never going to be possible to prescribe
a single QoS mechanism to be used in all networks. Existing networks (or
domains) will not be changed overnight and new networks already face several
workable mechanisms to deploy QoS.

I think that what is needed is a new protocol that can signal the
requirements of any session and can be satisfied by any QoS mechanism,
existing or new.
To be more precise, I am suggesting a new protocol that is independent of
the underlying transport technology and the QoS implemented and is also
independent of the session control protocol. Such a new protocol would be
generic, optionally implemented by applications that would benefit from
end-to-end QoS, and would be complimentary to the QoS mechanisms deployed
(and of course other mechanisms, such as the routing).

I think that this implies a more abstract definition of the QoS mechanism
and may lend itself to the signalling of pre-defined QoS classes rather than
parameters.

Dick Knight

-----Original Message-----
From: Brian Williams [mailto:brian.williams@ericsson.com.au]
Sent: 22 December 2001 23:57
To: lieve.bos@alcatel.be
Cc: nsis@ietf.org
Subject: Re: [NSIS] Two kinds of requirements


Hi.
While the two types of signalling may be related, I think there is a
need to develop a QoS bearer mechanism which is independent of any
specific session signalling, and thus can be used for any application. I
believe many of the applications which have identified requirements to
the working group have their own specific session layer signalling (ie
it is not end-to-end SIP).  

Having the session and transport protocols developed separately of
course does not prohibit the two being used in conjunction for a
specific application.
/brian
 
On Fri, 2001-12-21 at 22:24, lieve.bos@alcatel.be wrote:
> Hello all,
> 
> >From the discussion in Salt Lake city and the drafts submitted, one can
> easily see that people are suggesting improvements to QoS signalling at
> two totally different levels (some at session level and some at
> transport level).
> 
> First of all, there are drafts suggesting some improvements in the
> session setup procedures (i.e. the ability to negotiate the preferred
> QoS level between end users during SDP negotiation in SIP, so before the
> actual resources are being setup). The QoS information negotiated at the
> session layer determines the QoS level both endusers have to use for 
> their local access connection. This first kind of 'session level QoS
> negotiation' happens end-to-end between the two end-users.
> 
> Secondly, there are drafts suggesting that we need
> improvements/alternatives for the QoS signalling protocols (e.g. RSVP)
> used to actually provision the QoS at the transport level between two
> endusers. This second kind of 'transport level QoS signalling' can
> consist of several phases: end-to-edge and edge-to-edge. 
> 
> It's important that everybody realises that, in order to give endusers
> true end-to-end Quality of Service, we need improvements for QoS both at
> session and transport level. Also its important to understand that they
> are not uncorrelated. Providers want to be able to control (e.g. via
> policy control mechanisms) that the QoS requested at the transport level
> is not exceeding the QoS negotiated/authorised previously at session
> level. So, what about developing in NSIS a modular framework
> incorporating both session and transport level QoS signalling with
> possible hooks between the two layers (e.g. for policy enforcement).
> 
> Lieve
> 
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis



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

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

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

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



From daemon@ns.ietf.org  Thu Jan 17 10:53: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 KAA19656
	for <nsis-archive@odin.ietf.org>; Thu, 17 Jan 2002 10:53:24 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id KAA07448
	for nsis-archive@odin.ietf.org; Thu, 17 Jan 2002 10:53:26 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA07418;
	Thu, 17 Jan 2002 10:52: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 KAA07343
	for <nsis@ns.ietf.org>; Thu, 17 Jan 2002 10:52:12 -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 KAA19588
	for <nsis@ietf.org>; Thu, 17 Jan 2002 10:52:09 -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 g0HFs8T03632;
	Thu, 17 Jan 2002 09:54:08 -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 g0HFpGM00455;
	Thu, 17 Jan 2002 09:51:16 -0600 (CST)
Received: by TRIMAIL2.ad.tri.sbc.com with Internet Mail Service (5.5.2653.19)
	id <ZND32FZH>; Thu, 17 Jan 2002 09:51:43 -0600
Message-ID: <905A1C4ABF353F4C8CC16FA9F53DD0D632241E@TRIMAIL2.ad.tri.sbc.com>
From: "Chen, Weijing" <wchen@tri.sbc.com>
To: "'Georgios Karagiannis (ELN)'" <Georgios.Karagiannis@eln.ericsson.se>
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements
Date: Thu, 17 Jan 2002 09:51: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

Georgios,

First of all, the major objective for NSIS signaling for a service operator
point of view is that KISS (keep it simple, stupid?). We have seen some very
good protocol in technical never got a chance to see the light in real world
commercially.  Now based on this assumption, I have a question regarding the
[everyhop] part of protocol: Who is initiating and constructing it content?
If it is host, I am afraid that we may ask too much for the host. Now if we
let [edge] to inject some additional information for [everyhop] instead of
[host], then it could be a solution. [edge] is intelligent and powerful, it
knows a lot more about the core [hop] than [host]. We should insulate the
[host] from what the network it except necessary part.

--
Weijing Chen
SBC Technology Resources
9505 Arboretum Blvd.
Austin, TX 78759
512 372 5710
wchen@tri.sbc.com



 -----Original Message-----
From: 	Georgios Karagiannis (ELN)
[mailto:Georgios.Karagiannis@eln.ericsson.se] 
Sent:	Thursday, January 17, 2002 9:27 AM
To:	Chen, Weijing
Cc:	nsis@ietf.org
Subject:	RE: [NSIS] Two kinds of requirements

Hi Weijing

Please note that the access network, i.e., the network between the 
[host] and [edge] will include [interior] nodes. 
These [interior] nodes will only process and use 
only the "everyhop" protocol component. 
The "everyhost" and "everyedge" protocol components are not 
processed (used or checked). I did not show this into the 
protocol decomposition figure that I sent (reply to Dick), 
but it should be there. 

Moreover, I agree that the QoS for 1 and 2 can be supported by
over-provisioning, MPLS tunnel, etc., 
but if needed it should also be supported by the NSIS signaling 
protocol.

Best Regards,
Georgios


-----Original Message-----
From: Chen, Weijing [mailto:wchen@tri.sbc.com]
Sent: donderdag 17 januari 2002 15:54
To: 'Georgios Karagiannis (ELN)'
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


Georgois,

Regarding the modularization of signaling protocol, I think that the
following is more close to what we want:

[host] <-----NSIS signaling------>[edge]
....1...[core]....2...[core]....1...[edge]<---NSIS signaling---->[host]

1 and 2 could be over-provisioning, CoS routing, MPLS tunnel, ATM
connection, etc. The main objective is to keep NSIS signaling simple and
widespread implementable, and independent of what core uses. 

--
Weijing Chen
SBC Technology Resources
9505 Arboretum Blvd.
Austin, TX 78759
512 372 5710
wchen@tri.sbc.com



 -----Original Message-----
From: 	Georgios Karagiannis (ELN)
[mailto:Georgios.Karagiannis@eln.ericsson.se] 
Sent:	Thursday, January 17, 2002 3:39 AM
To:	'dick.rr.knight@bt.com'
Cc:	nsis@ietf.org
Subject:	RE: [NSIS] Two kinds of requirements

Hi Dick 

In principle I agree with your comment (see below).

[DK] >> To be more precise, I am suggesting a new protocol that is 
[DK] >> independent of the underlying transport technology and the QoS 
[DK] >> implemented and is also independent of the session control protocol.


However, a very important point here is that we need to 
specify a protocol that can be used independent of the underlying transport 
technology, but that can satisfy the QoS requirements imposed by these 
underlying transport technologies. Otherwise the protocol will not be
suitable
and useful.

A way of achieving this is by first creating a modular QoS signaling toolkit

that will contain mandatory and optional QoS requirements;
Second, specify how the protocol functionality should be separated in 
building blocks (protocol components) and define a minimum set 
of mandatory reservation options/features that should be 
processed by any network nodes, e.g., end-hosts,
proxies, edges and interior nodes.
An example of such a protocol decomposition is given below!
In this way each node will only process (check and use) the protocol 
components of interest.


|---------|
|---------|
|everyhost|<------------------------------------------------------->|everyho
st|
|---------|
|---------|
|         |                                                         |
|
|---------|   |---------|                             |---------|
|---------|
|everyedge|<->|everyedge|<--------------------------->|everyedge|<->|everyed
ge|
|---------|   |---------|                             |---------|
|---------|
|         |   |         |                             |         |   |
|
|---------|   |---------|   |--------|   |--------|   |---------|
|---------|
|everyhop |<->|everyhop |<->|everyhop|<->|everyhop|<->|everyhop
|<->|everyhop |
|---------|   |---------|   |--------|   |--------|   |---------|
|---------| 
    host          edge        interior    interior       edge          host


  NSIS protocol decomposition (building blocks): 
 *  "everyhost", "everyedge" and "everyhop" are protocol components;
 *  host: can be an end-host or a proxy and it can process and use the
"everyhost", 
    "everyedge", and "everyhop" protocol components;

 *  edge: can be a Diffserv edge, MPLS edge, etc., and it can process and
use 
    the "everyedge", and "everyhop" protocol components. The "everyhost" 
    protocol component is not processed (used or checked);

 *  interior: can be any router within a domain and it can process and use 
    only the "everyhop" protocol component.
    The "everyhost" and "everyedge" protocol components are not 
    processed (used or checked);


Best Regards,
Georgios

-----Original Message-----
From: dick.rr.knight@bt.com [mailto:dick.rr.knight@bt.com]
Sent: woensdag 16 januari 2002 13:00
To: brian.williams@ericsson.com.au; lieve.bos@alcatel.be
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


I was waiting for some reaction to Brian's comments, but as there aren't
any, here are my thoughts on the requirements:

I agree with the analysis that discussion has been based around
application-related signalling for QoS (at session level) and QoS signalling
protocols used to actually provision the QoS at the transport level.
Brian is right that there will never be an enhancement to a single session
protocol that will satisfy all applications.
However, for similar reasons, it is never going to be possible to prescribe
a single QoS mechanism to be used in all networks. Existing networks (or
domains) will not be changed overnight and new networks already face several
workable mechanisms to deploy QoS.

I think that what is needed is a new protocol that can signal the
requirements of any session and can be satisfied by any QoS mechanism,
existing or new.
To be more precise, I am suggesting a new protocol that is independent of
the underlying transport technology and the QoS implemented and is also
independent of the session control protocol. Such a new protocol would be
generic, optionally implemented by applications that would benefit from
end-to-end QoS, and would be complimentary to the QoS mechanisms deployed
(and of course other mechanisms, such as the routing).

I think that this implies a more abstract definition of the QoS mechanism
and may lend itself to the signalling of pre-defined QoS classes rather than
parameters.

Dick Knight

-----Original Message-----
From: Brian Williams [mailto:brian.williams@ericsson.com.au]
Sent: 22 December 2001 23:57
To: lieve.bos@alcatel.be
Cc: nsis@ietf.org
Subject: Re: [NSIS] Two kinds of requirements


Hi.
While the two types of signalling may be related, I think there is a
need to develop a QoS bearer mechanism which is independent of any
specific session signalling, and thus can be used for any application. I
believe many of the applications which have identified requirements to
the working group have their own specific session layer signalling (ie
it is not end-to-end SIP).  

Having the session and transport protocols developed separately of
course does not prohibit the two being used in conjunction for a
specific application.
/brian
 
On Fri, 2001-12-21 at 22:24, lieve.bos@alcatel.be wrote:
> Hello all,
> 
> >From the discussion in Salt Lake city and the drafts submitted, one can
> easily see that people are suggesting improvements to QoS signalling at
> two totally different levels (some at session level and some at
> transport level).
> 
> First of all, there are drafts suggesting some improvements in the
> session setup procedures (i.e. the ability to negotiate the preferred
> QoS level between end users during SDP negotiation in SIP, so before the
> actual resources are being setup). The QoS information negotiated at the
> session layer determines the QoS level both endusers have to use for 
> their local access connection. This first kind of 'session level QoS
> negotiation' happens end-to-end between the two end-users.
> 
> Secondly, there are drafts suggesting that we need
> improvements/alternatives for the QoS signalling protocols (e.g. RSVP)
> used to actually provision the QoS at the transport level between two
> endusers. This second kind of 'transport level QoS signalling' can
> consist of several phases: end-to-edge and edge-to-edge. 
> 
> It's important that everybody realises that, in order to give endusers
> true end-to-end Quality of Service, we need improvements for QoS both at
> session and transport level. Also its important to understand that they
> are not uncorrelated. Providers want to be able to control (e.g. via
> policy control mechanisms) that the QoS requested at the transport level
> is not exceeding the QoS negotiated/authorised previously at session
> level. So, what about developing in NSIS a modular framework
> incorporating both session and transport level QoS signalling with
> possible hooks between the two layers (e.g. for policy enforcement).
> 
> Lieve
> 
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis



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

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

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

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



From daemon@ns.ietf.org  Thu Jan 17 11:28: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 LAA21013
	for <nsis-archive@odin.ietf.org>; Thu, 17 Jan 2002 11:28:21 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id LAA09020
	for nsis-archive@odin.ietf.org; Thu, 17 Jan 2002 11:28: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 LAA08924;
	Thu, 17 Jan 2002 11: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 LAA08887
	for <nsis@ns.ietf.org>; Thu, 17 Jan 2002 11:25:21 -0500 (EST)
Received: from albatross-ext.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 LAA20691
	for <nsis@ietf.org>; Thu, 17 Jan 2002 11:25:18 -0500 (EST)
Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g0HGPJJ00866
	for <nsis@ietf.org>; Thu, 17 Jan 2002 17:25:19 +0100 (MET)
Received: FROM esealnt747.al.sw.ericsson.se BY esealnt461 ; Thu Jan 17 17:25:18 2002 +0100
Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <YHKTKP91>; Thu, 17 Jan 2002 17:25:02 +0100
Message-ID: <E244E44D6AB85E40AEEF7EAABE3545FA823370@enleent104.nl.eu.ericsson.se>
From: "Georgios Karagiannis (ELN)" <Georgios.Karagiannis@eln.ericsson.se>
To: "'Chen, Weijing'" <wchen@tri.sbc.com>
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements
Date: Thu, 17 Jan 2002 17:25:18 +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 Weijing

Depending on the type of the network it can either be the
[host] or be the [edge].
For example, in a Radio Access Network (please look to 
the NSIS draft: 
http://www.ietf.org/internet-drafts/draft-karagiannis-nsis-wireless-requirements-00.txt) 
the node that is 
initiating and constructing the "everyhop" content is the
[edge] node.

Best Regards,
Georgios

-----Original Message-----
From: Chen, Weijing [mailto:wchen@tri.sbc.com]
Sent: donderdag 17 januari 2002 16:52
To: 'Georgios Karagiannis (ELN)'
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


Georgios,

First of all, the major objective for NSIS signaling for a service operator
point of view is that KISS (keep it simple, stupid?). We have seen some very
good protocol in technical never got a chance to see the light in real world
commercially.  Now based on this assumption, I have a question regarding the
[everyhop] part of protocol: Who is initiating and constructing it content?
If it is host, I am afraid that we may ask too much for the host. Now if we
let [edge] to inject some additional information for [everyhop] instead of
[host], then it could be a solution. [edge] is intelligent and powerful, it
knows a lot more about the core [hop] than [host]. We should insulate the
[host] from what the network it except necessary part.

--
Weijing Chen
SBC Technology Resources
9505 Arboretum Blvd.
Austin, TX 78759
512 372 5710
wchen@tri.sbc.com



 -----Original Message-----
From: 	Georgios Karagiannis (ELN)
[mailto:Georgios.Karagiannis@eln.ericsson.se] 
Sent:	Thursday, January 17, 2002 9:27 AM
To:	Chen, Weijing
Cc:	nsis@ietf.org
Subject:	RE: [NSIS] Two kinds of requirements

Hi Weijing

Please note that the access network, i.e., the network between the 
[host] and [edge] will include [interior] nodes. 
These [interior] nodes will only process and use 
only the "everyhop" protocol component. 
The "everyhost" and "everyedge" protocol components are not 
processed (used or checked). I did not show this into the 
protocol decomposition figure that I sent (reply to Dick), 
but it should be there. 

Moreover, I agree that the QoS for 1 and 2 can be supported by
over-provisioning, MPLS tunnel, etc., 
but if needed it should also be supported by the NSIS signaling 
protocol.

Best Regards,
Georgios


-----Original Message-----
From: Chen, Weijing [mailto:wchen@tri.sbc.com]
Sent: donderdag 17 januari 2002 15:54
To: 'Georgios Karagiannis (ELN)'
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


Georgois,

Regarding the modularization of signaling protocol, I think that the
following is more close to what we want:

[host] <-----NSIS signaling------>[edge]
....1...[core]....2...[core]....1...[edge]<---NSIS signaling---->[host]

1 and 2 could be over-provisioning, CoS routing, MPLS tunnel, ATM
connection, etc. The main objective is to keep NSIS signaling simple and
widespread implementable, and independent of what core uses. 

--
Weijing Chen
SBC Technology Resources
9505 Arboretum Blvd.
Austin, TX 78759
512 372 5710
wchen@tri.sbc.com



 -----Original Message-----
From: 	Georgios Karagiannis (ELN)
[mailto:Georgios.Karagiannis@eln.ericsson.se] 
Sent:	Thursday, January 17, 2002 3:39 AM
To:	'dick.rr.knight@bt.com'
Cc:	nsis@ietf.org
Subject:	RE: [NSIS] Two kinds of requirements

Hi Dick 

In principle I agree with your comment (see below).

[DK] >> To be more precise, I am suggesting a new protocol that is 
[DK] >> independent of the underlying transport technology and the QoS 
[DK] >> implemented and is also independent of the session control protocol.


However, a very important point here is that we need to 
specify a protocol that can be used independent of the underlying transport 
technology, but that can satisfy the QoS requirements imposed by these 
underlying transport technologies. Otherwise the protocol will not be
suitable
and useful.

A way of achieving this is by first creating a modular QoS signaling toolkit

that will contain mandatory and optional QoS requirements;
Second, specify how the protocol functionality should be separated in 
building blocks (protocol components) and define a minimum set 
of mandatory reservation options/features that should be 
processed by any network nodes, e.g., end-hosts,
proxies, edges and interior nodes.
An example of such a protocol decomposition is given below!
In this way each node will only process (check and use) the protocol 
components of interest.


|---------|
|---------|
|everyhost|<------------------------------------------------------->|everyho
st|
|---------|
|---------|
|         |                                                         |
|
|---------|   |---------|                             |---------|
|---------|
|everyedge|<->|everyedge|<--------------------------->|everyedge|<->|everyed
ge|
|---------|   |---------|                             |---------|
|---------|
|         |   |         |                             |         |   |
|
|---------|   |---------|   |--------|   |--------|   |---------|
|---------|
|everyhop |<->|everyhop |<->|everyhop|<->|everyhop|<->|everyhop
|<->|everyhop |
|---------|   |---------|   |--------|   |--------|   |---------|
|---------| 
    host          edge        interior    interior       edge          host


  NSIS protocol decomposition (building blocks): 
 *  "everyhost", "everyedge" and "everyhop" are protocol components;
 *  host: can be an end-host or a proxy and it can process and use the
"everyhost", 
    "everyedge", and "everyhop" protocol components;

 *  edge: can be a Diffserv edge, MPLS edge, etc., and it can process and
use 
    the "everyedge", and "everyhop" protocol components. The "everyhost" 
    protocol component is not processed (used or checked);

 *  interior: can be any router within a domain and it can process and use 
    only the "everyhop" protocol component.
    The "everyhost" and "everyedge" protocol components are not 
    processed (used or checked);


Best Regards,
Georgios

-----Original Message-----
From: dick.rr.knight@bt.com [mailto:dick.rr.knight@bt.com]
Sent: woensdag 16 januari 2002 13:00
To: brian.williams@ericsson.com.au; lieve.bos@alcatel.be
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


I was waiting for some reaction to Brian's comments, but as there aren't
any, here are my thoughts on the requirements:

I agree with the analysis that discussion has been based around
application-related signalling for QoS (at session level) and QoS signalling
protocols used to actually provision the QoS at the transport level.
Brian is right that there will never be an enhancement to a single session
protocol that will satisfy all applications.
However, for similar reasons, it is never going to be possible to prescribe
a single QoS mechanism to be used in all networks. Existing networks (or
domains) will not be changed overnight and new networks already face several
workable mechanisms to deploy QoS.

I think that what is needed is a new protocol that can signal the
requirements of any session and can be satisfied by any QoS mechanism,
existing or new.
To be more precise, I am suggesting a new protocol that is independent of
the underlying transport technology and the QoS implemented and is also
independent of the session control protocol. Such a new protocol would be
generic, optionally implemented by applications that would benefit from
end-to-end QoS, and would be complimentary to the QoS mechanisms deployed
(and of course other mechanisms, such as the routing).

I think that this implies a more abstract definition of the QoS mechanism
and may lend itself to the signalling of pre-defined QoS classes rather than
parameters.

Dick Knight

-----Original Message-----
From: Brian Williams [mailto:brian.williams@ericsson.com.au]
Sent: 22 December 2001 23:57
To: lieve.bos@alcatel.be
Cc: nsis@ietf.org
Subject: Re: [NSIS] Two kinds of requirements


Hi.
While the two types of signalling may be related, I think there is a
need to develop a QoS bearer mechanism which is independent of any
specific session signalling, and thus can be used for any application. I
believe many of the applications which have identified requirements to
the working group have their own specific session layer signalling (ie
it is not end-to-end SIP).  

Having the session and transport protocols developed separately of
course does not prohibit the two being used in conjunction for a
specific application.
/brian
 
On Fri, 2001-12-21 at 22:24, lieve.bos@alcatel.be wrote:
> Hello all,
> 
> >From the discussion in Salt Lake city and the drafts submitted, one can
> easily see that people are suggesting improvements to QoS signalling at
> two totally different levels (some at session level and some at
> transport level).
> 
> First of all, there are drafts suggesting some improvements in the
> session setup procedures (i.e. the ability to negotiate the preferred
> QoS level between end users during SDP negotiation in SIP, so before the
> actual resources are being setup). The QoS information negotiated at the
> session layer determines the QoS level both endusers have to use for 
> their local access connection. This first kind of 'session level QoS
> negotiation' happens end-to-end between the two end-users.
> 
> Secondly, there are drafts suggesting that we need
> improvements/alternatives for the QoS signalling protocols (e.g. RSVP)
> used to actually provision the QoS at the transport level between two
> endusers. This second kind of 'transport level QoS signalling' can
> consist of several phases: end-to-edge and edge-to-edge. 
> 
> It's important that everybody realises that, in order to give endusers
> true end-to-end Quality of Service, we need improvements for QoS both at
> session and transport level. Also its important to understand that they
> are not uncorrelated. Providers want to be able to control (e.g. via
> policy control mechanisms) that the QoS requested at the transport level
> is not exceeding the QoS negotiated/authorised previously at session
> level. So, what about developing in NSIS a modular framework
> incorporating both session and transport level QoS signalling with
> possible hooks between the two layers (e.g. for policy enforcement).
> 
> Lieve
> 
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis



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

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

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

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



From daemon@ns.ietf.org  Thu Jan 17 11:34: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 LAA22258
	for <nsis-archive@odin.ietf.org>; Thu, 17 Jan 2002 11:34:44 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id LAA09718
	for nsis-archive@odin.ietf.org; Thu, 17 Jan 2002 11:34: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 LAA08780;
	Thu, 17 Jan 2002 11:20: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 LAA08752
	for <nsis@ns.ietf.org>; Thu, 17 Jan 2002 11:20:52 -0500 (EST)
Received: from ckmso1.proxy.att.com (ckmso1.att.com [12.20.58.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20617
	for <nsis@ietf.org>; Thu, 17 Jan 2002 11:20:49 -0500 (EST)
Received: from attrh3i.attrh.att.com ([135.71.62.12])
	by ckmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id g0HGKIZ08531
	for <nsis@ietf.org>; Thu, 17 Jan 2002 11:20:19 -0500 (EST)
Received: from occlust04evs1.ugd.att.com (135.71.164.12) by attrh3i.attrh.att.com (5.5.029)
        id 3C06950500AB7F13; Thu, 17 Jan 2002 11:19:21 -0500
content-class: urn:content-classes:message
Subject: RE: [NSIS] Two kinds of requirements
Date: Thu, 17 Jan 2002 11:20:03 -0500
Message-ID: <62DA45D4963FA747BA1B253E266760F9011E6EE2@OCCLUST04EVS1.ugd.att.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Thread-Topic: [NSIS] Two kinds of requirements
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
Thread-Index: AcGfbyTrfkHfKwtfEdajbgCQJ60IGQAAbFDg
From: "Roy, Radhika R, ALASO" <rrroy@att.com>
To: "Chen, Weijing" <wchen@tri.sbc.com>,
        "Georgios Karagiannis (ELN)" <Georgios.Karagiannis@eln.ericsson.se>
Cc: <nsis@ietf.org>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA08753
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


Inputs are inline [RRR]

-----Original Message-----
From: Chen, Weijing [mailto:wchen@tri.sbc.com]
Sent: Thursday, January 17, 2002 10:52 AM
To: 'Georgios Karagiannis (ELN)'
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


Georgios,

First of all, the major objective for NSIS signaling for a service operator
point of view is that KISS (keep it simple, stupid?). We have seen some very
good protocol in technical never got a chance to see the light in real world
commercially.  Now based on this assumption, I have a question regarding the
[everyhop] part of protocol: Who is initiating and constructing it content?
If it is host, I am afraid that we may ask too much for the host. Now if we
let [edge] to inject some additional information for [everyhop] instead of
[host], then it could be a solution. [edge] is intelligent and powerful, it
knows a lot more about the core [hop] than [host]. We should insulate the
[host] from what the network it except necessary part.

[RRR] Host will only express its needs to satisfy the applications. We can standardize in a simple way how a host can express its needs.

[RRR] Edge is where the actual implementation starts: Complex signaling to reserve the resources. An edge might have to work with an entity (e.g., proxy/bandwidth broker) that has the global knowledge for the end-to-end topology and can implement QOS dynamically. 

[RRR] In other cases, SLAs will help to ensure what needs to be done in each domain/segment where the end-to-end path/QOS allocation is priori known. Each domain will implement its own part.

--
Weijing Chen
SBC Technology Resources
9505 Arboretum Blvd.
Austin, TX 78759
512 372 5710
wchen@tri.sbc.com



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



From daemon@ns.ietf.org  Thu Jan 17 11:48: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 LAA23816
	for <nsis-archive@odin.ietf.org>; Thu, 17 Jan 2002 11:48:51 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id LAA10938
	for nsis-archive@odin.ietf.org; Thu, 17 Jan 2002 11:48: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 LAA10781;
	Thu, 17 Jan 2002 11:45: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 LAA10746
	for <nsis@ns.ietf.org>; Thu, 17 Jan 2002 11:45:28 -0500 (EST)
Received: from albatross-ext.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 LAA23734
	for <nsis@ietf.org>; Thu, 17 Jan 2002 11:45:25 -0500 (EST)
Received: from esealnt409.al.sw.ericsson.se (ESEALNT409.al.sw.ericsson.se [153.88.251.32])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g0HGjQJ14764
	for <nsis@ietf.org>; Thu, 17 Jan 2002 17:45:26 +0100 (MET)
Received: FROM esealnt746.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Thu Jan 17 17:45:25 2002 +0100
Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <YHLJLK1B>; Thu, 17 Jan 2002 17:45:25 +0100
Message-ID: <E244E44D6AB85E40AEEF7EAABE3545FA823374@enleent104.nl.eu.ericsson.se>
From: "Georgios Karagiannis (ELN)" <Georgios.Karagiannis@eln.ericsson.se>
To: "'Roy, Radhika R, ALASO'" <rrroy@att.com>
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements
Date: Thu, 17 Jan 2002 17:45:08 +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 Roy

I think you are right, but for some network scenarios
the [host] should also be able to include the [everyhop]
content.

Best regards,
Georgios

-----Original Message-----
From: Roy, Radhika R, ALASO [mailto:rrroy@att.com]
Sent: donderdag 17 januari 2002 17:20
To: Chen, Weijing; Georgios Karagiannis (ELN)
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements



Inputs are inline [RRR]

-----Original Message-----
From: Chen, Weijing [mailto:wchen@tri.sbc.com]
Sent: Thursday, January 17, 2002 10:52 AM
To: 'Georgios Karagiannis (ELN)'
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


Georgios,

First of all, the major objective for NSIS signaling for a service operator
point of view is that KISS (keep it simple, stupid?). We have seen some very
good protocol in technical never got a chance to see the light in real world
commercially.  Now based on this assumption, I have a question regarding the
[everyhop] part of protocol: Who is initiating and constructing it content?
If it is host, I am afraid that we may ask too much for the host. Now if we
let [edge] to inject some additional information for [everyhop] instead of
[host], then it could be a solution. [edge] is intelligent and powerful, it
knows a lot more about the core [hop] than [host]. We should insulate the
[host] from what the network it except necessary part.

[RRR] Host will only express its needs to satisfy the applications. We can standardize in a simple way how a host can express its needs.

[RRR] Edge is where the actual implementation starts: Complex signaling to reserve the resources. An edge might have to work with an entity (e.g., proxy/bandwidth broker) that has the global knowledge for the end-to-end topology and can implement QOS dynamically. 

[RRR] In other cases, SLAs will help to ensure what needs to be done in each domain/segment where the end-to-end path/QOS allocation is priori known. Each domain will implement its own part.

--
Weijing Chen
SBC Technology Resources
9505 Arboretum Blvd.
Austin, TX 78759
512 372 5710
wchen@tri.sbc.com


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



From daemon@ns.ietf.org  Thu Jan 17 11:49: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 LAA23833
	for <nsis-archive@odin.ietf.org>; Thu, 17 Jan 2002 11:49:01 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id LAA10953
	for nsis-archive@odin.ietf.org; Thu, 17 Jan 2002 11:49: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 LAA10906;
	Thu, 17 Jan 2002 11:46: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 LAA10869
	for <nsis@ns.ietf.org>; Thu, 17 Jan 2002 11:46:51 -0500 (EST)
Received: from sm13.texas.rr.com (sm13.texas.rr.com [24.93.35.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23761
	for <nsis@ietf.org>; Thu, 17 Jan 2002 11:46:48 -0500 (EST)
Received: from Joonslaptop (bu24242141-166.austin.rr.com [24.242.141.166])
	by sm13.texas.rr.com (8.12.0.Beta16/8.12.0.Beta16) with SMTP id g0HGo6Sp030665
	for <nsis@ietf.org>; Thu, 17 Jan 2002 10:50:06 -0600
Reply-To: <jmaeng@ipdialog.com>
From: "jmaeng" <jmaeng@ipdialog.com>
To: <nsis@ietf.org>
Date: Thu, 17 Jan 2002 10:49:00 -0600
Message-ID: <002701c19f76$de0ce970$a68df218@Joonslaptop>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
In-Reply-To: <62DA45D4963FA747BA1B253E266760F9011E6EE2@OCCLUST04EVS1.ugd.att.com>
Content-Transfer-Encoding: 7bit
Subject: [NSIS] Charter of nsis
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 am new to this group. I read most of discussions and am confused with the
charter of this group.  In my mind, RSVP is more than signaling since it
specifies how routers should behave and so on.  Is nsis' goal is to define
something like RSVP and specify the behavior of networks to meet the
signaling?  I would appreciate any clarification.
Joon


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



From daemon@optimus.ietf.org  Thu Jan 17 13:14: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 NAA28886
	for <nsis-archive@odin.ietf.org>; Thu, 17 Jan 2002 13:14:25 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id NAA16511
	for nsis-archive@odin.ietf.org; Thu, 17 Jan 2002 13:14:26 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA16408;
	Thu, 17 Jan 2002 13:12: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 NAA16374
	for <nsis@optimus.ietf.org>; Thu, 17 Jan 2002 13:12:33 -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 NAA28821
	for <nsis@ietf.org>; Thu, 17 Jan 2002 13:12:30 -0500 (EST)
Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56])
	by zcars0m9.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g0HIBxb21947;
	Thu, 17 Jan 2002 13:11:59 -0500 (EST)
Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7])
	by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g0HIBuG04921;
	Thu, 17 Jan 2002 13:11:56 -0500 (EST)
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19)
	id <C8PZV53X>; Thu, 17 Jan 2002 13:11:51 -0500
Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4782@zcard031.ca.nortel.com>
From: "Gary Kenward"<gkenward@nortelnetworks.com>
To: "'Loughney John (NRC/Helsinki)'" <john.loughney@nokia.com>,
        brunner@ccrle.nec.de, Yaron Kahana <ykahana@comgates.co.il>,
        "Geib, Ruediger" <Ruediger.Geib@t-systems.com>, dick.rr.knight@bt.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements
Date: Thu, 17 Jan 2002 13:11:24 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C19F82.5FA5A2A0"
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_01C19F82.5FA5A2A0
Content-Type: text/plain;
	charset="ISO-8859-1"

hello

Perhaps I'm off track here, but it seems to me that how a particular
user service is mapped to particular network services and, in particular,
resource allocation, is/should be completely under the operators purvue.
The tools the operator uses to define/support a given service include
network
engineering, traffic engineering, and policy management. Customization and
flexibility are the key characteristics to any operator who does not want to
be a "bit pipe" provider - i.e. who wants to be as profitable as possible.

Whatever signalling solution is derived, it must not attempt to standardize
user services. The only exception to this may be the one (maybe two)
service(s)
that is(are) pervasive, namely telephony voice (BE internet data). Even
then,
there are still approaches that would allow flexibility for these services
(different voice grades, gold, silver and platinum BE).

Just a thought.
Gary Kenward

> -----Original Message-----
> From: Loughney John (NRC/Helsinki) [mailto:john.loughney@nokia.com]
> Sent: January 17, 2002 06:16
> To: brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
> dick.rr.knight@bt.com
> Cc: nsis@ietf.org
> Subject: RE: [NSIS] Two kinds of requirements
> 
> 
> Hi all,
> 
> > Good point, my question is whether the operator more likely 
> opt for a 
> > simple solution, with little flexibility, which implies no 
> > competition in the type of services offered, since these are
> standardized 
> > (I assume there is still a lot of differentiation possible 
> with weaker
> 
> > service parameters)
> 
> I've been wondering if this is a spurious argument.  I cannot 
> think of 
> how service providers could use QoS as a service.  What I have been 
> hearing from service providers is that they would like to be able
> to provide certain QoS levels for customers, but they would like
> to be free to deploy / allocate resources as they see fit.  
> 
> With the PSTN, there SHOULD be only one quality, but in practice,
> when calling overseas, I tend to get quite variable quality - 
> of course
> I still pay the same price ...
> 
> Additionally, I think we need to start somewhere, and I think that we 
> need to be able to set some base line for signaling QoS. This does not
> mean that we cannot allow more to be done / offered, but we want
> to start with a minimum.  One option could be that we allow a simple
> solution that supports optional extras.  These extras could be used
> by service providers for enhanced services, but we don't specify 
> them.
> 
> best regards,
> John
> 
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis
> 

------_=_NextPart_001_01C19F82.5FA5A2A0
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] Two kinds of requirements</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>hello</FONT>
</P>

<P><FONT SIZE=3D2>Perhaps I'm off track here, but it seems to me that =
how a particular</FONT>
<BR><FONT SIZE=3D2>user service is mapped to particular network =
services and, in particular,</FONT>
<BR><FONT SIZE=3D2>resource allocation, is/should be completely under =
the operators purvue.</FONT>
<BR><FONT SIZE=3D2>The tools the operator uses to define/support a =
given service include network</FONT>
<BR><FONT SIZE=3D2>engineering, traffic engineering, and policy =
management. Customization and</FONT>
<BR><FONT SIZE=3D2>flexibility are the key characteristics to any =
operator who does not want to</FONT>
<BR><FONT SIZE=3D2>be a &quot;bit pipe&quot; provider - i.e. who wants =
to be as profitable as possible.</FONT>
</P>

<P><FONT SIZE=3D2>Whatever signalling solution is derived, it must not =
attempt to standardize</FONT>
<BR><FONT SIZE=3D2>user services. The only exception to this may be the =
one (maybe two) service(s)</FONT>
<BR><FONT SIZE=3D2>that is(are) pervasive, namely telephony voice (BE =
internet data). Even then,</FONT>
<BR><FONT SIZE=3D2>there are still approaches that would allow =
flexibility for these services</FONT>
<BR><FONT SIZE=3D2>(different voice grades, gold, silver and platinum =
BE).</FONT>
</P>

<P><FONT SIZE=3D2>Just a thought.</FONT>
<BR><FONT SIZE=3D2>Gary Kenward</FONT>
</P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Loughney John (NRC/Helsinki) [<A =
HREF=3D"mailto:john.loughney@nokia.com">mailto:john.loughney@nokia.com</=
A>]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: January 17, 2002 06:16</FONT>
<BR><FONT SIZE=3D2>&gt; To: brunner@ccrle.nec.de; Yaron Kahana; Geib, =
Ruediger;</FONT>
<BR><FONT SIZE=3D2>&gt; dick.rr.knight@bt.com</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: nsis@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: RE: [NSIS] Two kinds of =
requirements</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; &gt; Good point, my question is whether the =
operator more likely </FONT>
<BR><FONT SIZE=3D2>&gt; opt for a </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; simple solution, with little flexibility, =
which implies no </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; competition in the type of services =
offered, since these are</FONT>
<BR><FONT SIZE=3D2>&gt; standardized </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; (I assume there is still a lot of =
differentiation possible </FONT>
<BR><FONT SIZE=3D2>&gt; with weaker</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; service parameters)</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I've been wondering if this is a spurious =
argument.&nbsp; I cannot </FONT>
<BR><FONT SIZE=3D2>&gt; think of </FONT>
<BR><FONT SIZE=3D2>&gt; how service providers could use QoS as a =
service.&nbsp; What I have been </FONT>
<BR><FONT SIZE=3D2>&gt; hearing from service providers is that they =
would like to be able</FONT>
<BR><FONT SIZE=3D2>&gt; to provide certain QoS levels for customers, =
but they would like</FONT>
<BR><FONT SIZE=3D2>&gt; to be free to deploy / allocate resources as =
they see fit.&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; With the PSTN, there SHOULD be only one =
quality, but in practice,</FONT>
<BR><FONT SIZE=3D2>&gt; when calling overseas, I tend to get quite =
variable quality - </FONT>
<BR><FONT SIZE=3D2>&gt; of course</FONT>
<BR><FONT SIZE=3D2>&gt; I still pay the same price ...</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Additionally, I think we need to start =
somewhere, and I think that we </FONT>
<BR><FONT SIZE=3D2>&gt; need to be able to set some base line for =
signaling QoS. This does not</FONT>
<BR><FONT SIZE=3D2>&gt; mean that we cannot allow more to be done / =
offered, but we want</FONT>
<BR><FONT SIZE=3D2>&gt; to start with a minimum.&nbsp; One option could =
be that we allow a simple</FONT>
<BR><FONT SIZE=3D2>&gt; solution that supports optional extras.&nbsp; =
These extras could be used</FONT>
<BR><FONT SIZE=3D2>&gt; by service providers for enhanced services, but =
we don't specify </FONT>
<BR><FONT SIZE=3D2>&gt; them.</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_01C19F82.5FA5A2A0--

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



From daemon@optimus.ietf.org  Thu Jan 17 13:24: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 NAA29204
	for <nsis-archive@odin.ietf.org>; Thu, 17 Jan 2002 13:24:25 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id NAA16701
	for nsis-archive@odin.ietf.org; Thu, 17 Jan 2002 13:24:26 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA16502;
	Thu, 17 Jan 2002 13:14: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 NAA16467
	for <nsis@optimus.ietf.org>; Thu, 17 Jan 2002 13:14:09 -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 NAA28871
	for <nsis@ietf.org>; Thu, 17 Jan 2002 13:14:05 -0500 (EST)
Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56])
	by zcars0m9.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g0HIDYb22352;
	Thu, 17 Jan 2002 13:13:34 -0500 (EST)
Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7])
	by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g0HIDVG05075;
	Thu, 17 Jan 2002 13:13:31 -0500 (EST)
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19)
	id <C8PZV5Q4>; Thu, 17 Jan 2002 13:13:31 -0500
Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4783@zcard031.ca.nortel.com>
From: "Gary Kenward"<gkenward@nortelnetworks.com>
To: "'Loughney John (NRC/Helsinki)'" <john.loughney@nokia.com>,
        "'ext Georgios Karagiannis (ELN)'" <Georgios.Karagiannis@eln.ericsson.se>,
        dick.rr.knight@bt.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements
Date: Thu, 17 Jan 2002 13:13:29 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C19F82.AA0CE060"
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_01C19F82.AA0CE060
Content-Type: text/plain;
	charset="ISO-8859-1"

John:

  Perhaps Gergios meant a "requirement" that was optional. Perhaps
denotatively
a contradiction, it is a common approach. In IETF parlance, this would be a
"SHOULD" or "MAY".

Gary

> -----Original Message-----
> From: Loughney John (NRC/Helsinki) [mailto:john.loughney@nokia.com]
> Sent: January 17, 2002 06:25
> To: 'ext Georgios Karagiannis (ELN)'; dick.rr.knight@bt.com
> Cc: nsis@ietf.org
> Subject: RE: [NSIS] Two kinds of requirements
> 
> 
> Hi Georgios,
> 
> One thing that struck me from the mail below is:
> 
> > A way of achieving this is by first creating a modular QoS 
> > signaling toolkit that will contain mandatory and optional QoS 
> > requirements;
> 
> What is an optional requirement?  My dictionary says that
> requirement means:
> 
> 	a : something wanted or needed : NECESSITY 
>  
> 	b : something essential to the existence or 
>           occurrence of something else : 
> 
> My strong suggestion is that we drop discussion of all
> optional requirements, since it is an oxymoron.  Any
> solution we work on can do more than what we list in
> the requirements work, but the requirements draft
> SHOULD be a pithy read (in other words, a short
> document).
> 
> best regards,
> John
> 
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis
> 

------_=_NextPart_001_01C19F82.AA0CE060
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] Two kinds of requirements</TITLE>
</HEAD>
<BODY>

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

<P><FONT SIZE=3D2>&nbsp; Perhaps Gergios meant a =
&quot;requirement&quot; that was optional. Perhaps denotatively</FONT>
<BR><FONT SIZE=3D2>a contradiction, it is a common approach. In IETF =
parlance, this would be a</FONT>
<BR><FONT SIZE=3D2>&quot;SHOULD&quot; or &quot;MAY&quot;.</FONT>
</P>

<P><FONT SIZE=3D2>Gary</FONT>
</P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Loughney John (NRC/Helsinki) [<A =
HREF=3D"mailto:john.loughney@nokia.com">mailto:john.loughney@nokia.com</=
A>]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: January 17, 2002 06:25</FONT>
<BR><FONT SIZE=3D2>&gt; To: 'ext Georgios Karagiannis (ELN)'; =
dick.rr.knight@bt.com</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: nsis@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: RE: [NSIS] Two kinds of =
requirements</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Hi Georgios,</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; One thing that struck me from the mail below =
is:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; A way of achieving this is by first =
creating a modular QoS </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; signaling toolkit that will contain =
mandatory and optional QoS </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; requirements;</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; What is an optional requirement?&nbsp; My =
dictionary says that</FONT>
<BR><FONT SIZE=3D2>&gt; requirement means:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; a : something =
wanted or needed : NECESSITY </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; b : something =
essential to the existence or </FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; occurrence of something else : </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; My strong suggestion is that we drop discussion =
of all</FONT>
<BR><FONT SIZE=3D2>&gt; optional requirements, since it is an =
oxymoron.&nbsp; Any</FONT>
<BR><FONT SIZE=3D2>&gt; solution we work on can do more than what we =
list in</FONT>
<BR><FONT SIZE=3D2>&gt; the requirements work, but the requirements =
draft</FONT>
<BR><FONT SIZE=3D2>&gt; SHOULD be a pithy read (in other words, a =
short</FONT>
<BR><FONT SIZE=3D2>&gt; document).</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_01C19F82.AA0CE060--

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



From daemon@optimus.ietf.org  Thu Jan 17 13:38: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 NAA29612
	for <nsis-archive@odin.ietf.org>; Thu, 17 Jan 2002 13:38:31 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id NAA17492
	for nsis-archive@odin.ietf.org; Thu, 17 Jan 2002 13:38: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 NAA17414;
	Thu, 17 Jan 2002 13:35: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 NAA17383
	for <nsis@optimus.ietf.org>; Thu, 17 Jan 2002 13:35:50 -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 NAA29572
	for <nsis@ietf.org>; Thu, 17 Jan 2002 13:35:47 -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 g0HIZGb26308;
	Thu, 17 Jan 2002 13:35:17 -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 g0HIZFG00621;
	Thu, 17 Jan 2002 13:35:15 -0500 (EST)
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19)
	id <C8PZV6H2>; Thu, 17 Jan 2002 13:35:14 -0500
Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4784@zcard031.ca.nortel.com>
From: "Gary Kenward"<gkenward@nortelnetworks.com>
To: "'Loughney John (NRC/Helsinki)'" <john.loughney@nokia.com>,
        "'ext Georgios Karagiannis (ELN)'" <Georgios.Karagiannis@eln.ericsson.se>,
        "'ext Kappler Cornelia'" <Cornelia.Kappler@icn.siemens.de>
Cc: nsis <nsis@ietf.org>
Subject: RE: [NSIS] Two kinds of requirements
Date: Thu, 17 Jan 2002 13:35:11 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C19F85.B25116D0"
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_01C19F85.B25116D0
Content-Type: text/plain;
	charset="ISO-8859-1"

RFC 2026 describes how technical specifications and applicability
statements are to be defined, and provides a framework for defining
the different levels of applicability (e.g. "required", "elective",
etc.) for variagated networking scenarios.

RFC 2119 describes how keywords such as "MUST", "MUST NOT", 
"REQUIRED", "SHALL", "SHALL OT", "SHOULD", "SHOULD NOT", 
"RECOMMENDED",  "MAY", and "OPTIONAL" are to be used in a requirements
document.

Having been through the process of trying to define requirements for 
a protocol recently, I definitely agree that care must be taken to 
avoid specifying non-requirements (e.g. "the protocol MAY be reliable"),
but I do not believe that you can satisfy the variety of networking
scenarios without optional features. Frequently, optional features
are features that can be avoided if one wants to simplify the protocol
implementation/deployment. In some cases, optional features are features
that might oppose each other if used simultaneously (e.g. IS and DS
negotiation at the network edge).

Note that "conditional" requirements (e.g. "if the network is "x" then
"y" MUST be there) are identical to optional ("MAY", "SHOULD") requirements.

I don't see how you can make all the requirements MUST. 

Gary K.

> -----Original Message-----
> From: Loughney John (NRC/Helsinki) [mailto:john.loughney@nokia.com]
> Sent: January 17, 2002 08:15
> To: 'ext Georgios Karagiannis (ELN)'; 'ext Kappler Cornelia'
> Cc: nsis
> Subject: RE: [NSIS] Two kinds of requirements
> 
> 
> Hi Georgios,
> 
> > I think that one of the requirements that should be included 
> > in the NSIS WG requirements document is that the NSIS protocol
> > should be modular. Modular in the context of having 
> > a toolkit from which one can choose the applicable tools 
> > in order to manage QoS in a particular networking environment.
> 
> I agree.  To put it another way, the protocol SHOULD be able
> to be deployed in a number of different scenarios (end-to-edge, 
> end-to-end, edge-to-edge, etc.)
> 
> John
> 
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis
> 

------_=_NextPart_001_01C19F85.B25116D0
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] Two kinds of requirements</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>RFC 2026 describes how technical specifications and =
applicability</FONT>
<BR><FONT SIZE=3D2>statements are to be defined, and provides a =
framework for defining</FONT>
<BR><FONT SIZE=3D2>the different levels of applicability (e.g. =
&quot;required&quot;, &quot;elective&quot;,</FONT>
<BR><FONT SIZE=3D2>etc.) for variagated networking scenarios.</FONT>
</P>

<P><FONT SIZE=3D2>RFC 2119 describes how keywords such as =
&quot;MUST&quot;, &quot;MUST NOT&quot;, </FONT>
<BR><FONT SIZE=3D2>&quot;REQUIRED&quot;, &quot;SHALL&quot;, &quot;SHALL =
OT&quot;, &quot;SHOULD&quot;, &quot;SHOULD NOT&quot;, </FONT>
<BR><FONT SIZE=3D2>&quot;RECOMMENDED&quot;,&nbsp; &quot;MAY&quot;, and =
&quot;OPTIONAL&quot; are to be used in a requirements</FONT>
<BR><FONT SIZE=3D2>document.</FONT>
</P>

<P><FONT SIZE=3D2>Having been through the process of trying to define =
requirements for </FONT>
<BR><FONT SIZE=3D2>a protocol recently, I definitely agree that care =
must be taken to </FONT>
<BR><FONT SIZE=3D2>avoid specifying non-requirements (e.g. &quot;the =
protocol MAY be reliable&quot;),</FONT>
<BR><FONT SIZE=3D2>but I do not believe that you can satisfy the =
variety of networking</FONT>
<BR><FONT SIZE=3D2>scenarios without optional features. Frequently, =
optional features</FONT>
<BR><FONT SIZE=3D2>are features that can be avoided if one wants to =
simplify the protocol</FONT>
<BR><FONT SIZE=3D2>implementation/deployment. In some cases, optional =
features are features</FONT>
<BR><FONT SIZE=3D2>that might oppose each other if used simultaneously =
(e.g. IS and DS</FONT>
<BR><FONT SIZE=3D2>negotiation at the network edge).</FONT>
</P>

<P><FONT SIZE=3D2>Note that &quot;conditional&quot; requirements (e.g. =
&quot;if the network is &quot;x&quot; then</FONT>
<BR><FONT SIZE=3D2>&quot;y&quot; MUST be there) are identical to =
optional (&quot;MAY&quot;, &quot;SHOULD&quot;) requirements.</FONT>
</P>

<P><FONT SIZE=3D2>I don't see how you can make all the requirements =
MUST. </FONT>
</P>

<P><FONT SIZE=3D2>Gary K.</FONT>
</P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Loughney John (NRC/Helsinki) [<A =
HREF=3D"mailto:john.loughney@nokia.com">mailto:john.loughney@nokia.com</=
A>]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: January 17, 2002 08:15</FONT>
<BR><FONT SIZE=3D2>&gt; To: 'ext Georgios Karagiannis (ELN)'; 'ext =
Kappler Cornelia'</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: nsis</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: RE: [NSIS] Two kinds of =
requirements</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Hi Georgios,</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; I think that one of the requirements that =
should be included </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; in the NSIS WG requirements document is =
that the NSIS protocol</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; should be modular. Modular in the context =
of having </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; a toolkit from which one can choose the =
applicable tools </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; in order to manage QoS in a particular =
networking environment.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I agree.&nbsp; To put it another way, the =
protocol SHOULD be able</FONT>
<BR><FONT SIZE=3D2>&gt; to be deployed in a number of different =
scenarios (end-to-edge, </FONT>
<BR><FONT SIZE=3D2>&gt; end-to-end, edge-to-edge, etc.)</FONT>
<BR><FONT SIZE=3D2>&gt; </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_01C19F85.B25116D0--

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



From daemon@optimus.ietf.org  Thu Jan 17 13:51: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 NAA00162
	for <nsis-archive@odin.ietf.org>; Thu, 17 Jan 2002 13:51:13 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id NAA17893
	for nsis-archive@odin.ietf.org; Thu, 17 Jan 2002 13:51: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 NAA17833;
	Thu, 17 Jan 2002 13:48: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 NAA17798
	for <nsis@optimus.ietf.org>; Thu, 17 Jan 2002 13:48:24 -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 NAA00048
	for <nsis@ietf.org>; Thu, 17 Jan 2002 13:48:22 -0500 (EST)
Received: (from sob@localhost)
	by newdev.harvard.edu (8.10.2/8.10.2) id g0HIfhY22025;
	Thu, 17 Jan 2002 13:41:43 -0500 (EST)
Date: Thu, 17 Jan 2002 13:41:43 -0500 (EST)
From: Scott  Bradner <sob@harvard.edu>
Message-Id: <200201171841.g0HIfhY22025@newdev.harvard.edu>
To: Cornelia.Kappler@icn.siemens.de, Georgios.Karagiannis@eln.ericsson.se,
        gkenward@nortelnetworks.com, john.loughney@nokia.com
Subject: RE: [NSIS] Two kinds of requirements
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

> I don't see how you can make all the requirements MUST. 

I agree, but it is good to think hard about a feature that is not needed
in most cases - maybe it can be left out (and maybe it can not)


Scott

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



From daemon@optimus.ietf.org  Thu Jan 17 13:53: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 NAA00254
	for <nsis-archive@odin.ietf.org>; Thu, 17 Jan 2002 13:53:22 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id NAA17936
	for nsis-archive@odin.ietf.org; Thu, 17 Jan 2002 13:53: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 NAA17707;
	Thu, 17 Jan 2002 13:46: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 NAA17637
	for <nsis@optimus.ietf.org>; Thu, 17 Jan 2002 13:46:03 -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 NAA29945
	for <nsis@ietf.org>; Thu, 17 Jan 2002 13:46:00 -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 g0HIjUb28042;
	Thu, 17 Jan 2002 13:45:30 -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 g0HIjSG01268;
	Thu, 17 Jan 2002 13:45:28 -0500 (EST)
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19)
	id <C8PZV6Q0>; Thu, 17 Jan 2002 13:45:27 -0500
Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4785@zcard031.ca.nortel.com>
From: "Gary Kenward"<gkenward@nortelnetworks.com>
To: "'Chen, Weijing'" <wchen@tri.sbc.com>,
        "'Georgios Karagiannis (ELN)'"
	 <Georgios.Karagiannis@eln.ericsson.se>
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements
Date: Thu, 17 Jan 2002 13:45:25 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C19F87.203BB5F0"
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_01C19F87.203BB5F0
Content-Type: text/plain;
	charset="ISO-8859-1"

I agree whole-heartedly with Weijing here.
The internet model trys to keep the "intelligence" at
the host, however, the down side with this approach
is that with QoS (and indeed, any negotiable service or 
service characteristic), the host is burdened with having to 
have knowledge of the network. The second down side,
particularly important for those of us working in wireless,
is the need to pass information between host and network.

There is more then one protocol here, or at least, more then
one flavour/configuration of a protocol. One flavour allows
the host to tell the access network "give me one of the services
my user has contracted with you to use", the other flavour allows
the network to figure out how to fullfill this contract, opaque
to the host. Perhaps a third flavour allows one network to ask
another network to provide a give service. (By "service" here
I also imply "service characteristic" such as QoS).

As an example: do I really need to tell the host what path the
network has selected in order to provide QoS? This is what RSVP
end-to-end does. 

Gary Kenward.

> -----Original Message-----
> From: Chen, Weijing [mailto:wchen@tri.sbc.com]
> Sent: January 17, 2002 10:52
> To: 'Georgios Karagiannis (ELN)'
> Cc: nsis@ietf.org
> Subject: RE: [NSIS] Two kinds of requirements
> 
> 
> Georgios,
> 
> First of all, the major objective for NSIS signaling for a 
> service operator
> point of view is that KISS (keep it simple, stupid?). We have 
> seen some very
> good protocol in technical never got a chance to see the 
> light in real world
> commercially.  Now based on this assumption, I have a 
> question regarding the
> [everyhop] part of protocol: Who is initiating and 
> constructing it content?
> If it is host, I am afraid that we may ask too much for the 
> host. Now if we
> let [edge] to inject some additional information for 
> [everyhop] instead of
> [host], then it could be a solution. [edge] is intelligent 
> and powerful, it
> knows a lot more about the core [hop] than [host]. We should 
> insulate the
> [host] from what the network it except necessary part.
> 
> --
> Weijing Chen
> SBC Technology Resources
> 9505 Arboretum Blvd.
> Austin, TX 78759
> 512 372 5710
> wchen@tri.sbc.com
> 
> 
> 
>  -----Original Message-----
> From: 	Georgios Karagiannis (ELN)
> [mailto:Georgios.Karagiannis@eln.ericsson.se] 
> Sent:	Thursday, January 17, 2002 9:27 AM
> To:	Chen, Weijing
> Cc:	nsis@ietf.org
> Subject:	RE: [NSIS] Two kinds of requirements
> 
> Hi Weijing
> 
> Please note that the access network, i.e., the network between the 
> [host] and [edge] will include [interior] nodes. 
> These [interior] nodes will only process and use 
> only the "everyhop" protocol component. 
> The "everyhost" and "everyedge" protocol components are not 
> processed (used or checked). I did not show this into the 
> protocol decomposition figure that I sent (reply to Dick), 
> but it should be there. 
> 
> Moreover, I agree that the QoS for 1 and 2 can be supported by
> over-provisioning, MPLS tunnel, etc., 
> but if needed it should also be supported by the NSIS signaling 
> protocol.
> 
> Best Regards,
> Georgios
> 
> 
> -----Original Message-----
> From: Chen, Weijing [mailto:wchen@tri.sbc.com]
> Sent: donderdag 17 januari 2002 15:54
> To: 'Georgios Karagiannis (ELN)'
> Cc: nsis@ietf.org
> Subject: RE: [NSIS] Two kinds of requirements
> 
> 
> Georgois,
> 
> Regarding the modularization of signaling protocol, I think that the
> following is more close to what we want:
> 
> [host] <-----NSIS signaling------>[edge]
> ....1...[core]....2...[core]....1...[edge]<---NSIS 
> signaling---->[host]
> 
> 1 and 2 could be over-provisioning, CoS routing, MPLS tunnel, ATM
> connection, etc. The main objective is to keep NSIS signaling 
> simple and
> widespread implementable, and independent of what core uses. 
> 
> --
> Weijing Chen
> SBC Technology Resources
> 9505 Arboretum Blvd.
> Austin, TX 78759
> 512 372 5710
> wchen@tri.sbc.com
> 
> 
> 
>  -----Original Message-----
> From: 	Georgios Karagiannis (ELN)
> [mailto:Georgios.Karagiannis@eln.ericsson.se] 
> Sent:	Thursday, January 17, 2002 3:39 AM
> To:	'dick.rr.knight@bt.com'
> Cc:	nsis@ietf.org
> Subject:	RE: [NSIS] Two kinds of requirements
> 
> Hi Dick 
> 
> In principle I agree with your comment (see below).
> 
> [DK] >> To be more precise, I am suggesting a new protocol that is 
> [DK] >> independent of the underlying transport technology 
> and the QoS 
> [DK] >> implemented and is also independent of the session 
> control protocol.
> 
> 
> However, a very important point here is that we need to 
> specify a protocol that can be used independent of the 
> underlying transport 
> technology, but that can satisfy the QoS requirements imposed 
> by these 
> underlying transport technologies. Otherwise the protocol will not be
> suitable
> and useful.
> 
> A way of achieving this is by first creating a modular QoS 
> signaling toolkit
> 
> that will contain mandatory and optional QoS requirements;
> Second, specify how the protocol functionality should be separated in 
> building blocks (protocol components) and define a minimum set 
> of mandatory reservation options/features that should be 
> processed by any network nodes, e.g., end-hosts,
> proxies, edges and interior nodes.
> An example of such a protocol decomposition is given below!
> In this way each node will only process (check and use) the protocol 
> components of interest.
> 
> 
> |---------|
> |---------|
> |everyhost|<--------------------------------------------------
> ----->|everyho
> st|
> |---------|
> |---------|
> |         |                                                         |
> |
> |---------|   |---------|                             |---------|
> |---------|
> |everyedge|<->|everyedge|<--------------------------->|everyed
> ge|<->|everyed
> ge|
> |---------|   |---------|                             |---------|
> |---------|
> |         |   |         |                             |         |   |
> |
> |---------|   |---------|   |--------|   |--------|   |---------|
> |---------|
> |everyhop |<->|everyhop |<->|everyhop|<->|everyhop|<->|everyhop
> |<->|everyhop |
> |---------|   |---------|   |--------|   |--------|   |---------|
> |---------| 
>     host          edge        interior    interior       edge 
>          host
> 
> 
>   NSIS protocol decomposition (building blocks): 
>  *  "everyhost", "everyedge" and "everyhop" are protocol components;
>  *  host: can be an end-host or a proxy and it can process and use the
> "everyhost", 
>     "everyedge", and "everyhop" protocol components;
> 
>  *  edge: can be a Diffserv edge, MPLS edge, etc., and it can 
> process and
> use 
>     the "everyedge", and "everyhop" protocol components. The 
> "everyhost" 
>     protocol component is not processed (used or checked);
> 
>  *  interior: can be any router within a domain and it can 
> process and use 
>     only the "everyhop" protocol component.
>     The "everyhost" and "everyedge" protocol components are not 
>     processed (used or checked);
> 
> 
> Best Regards,
> Georgios
> 
> -----Original Message-----
> From: dick.rr.knight@bt.com [mailto:dick.rr.knight@bt.com]
> Sent: woensdag 16 januari 2002 13:00
> To: brian.williams@ericsson.com.au; lieve.bos@alcatel.be
> Cc: nsis@ietf.org
> Subject: RE: [NSIS] Two kinds of requirements
> 
> 
> I was waiting for some reaction to Brian's comments, but as 
> there aren't
> any, here are my thoughts on the requirements:
> 
> I agree with the analysis that discussion has been based around
> application-related signalling for QoS (at session level) and 
> QoS signalling
> protocols used to actually provision the QoS at the transport level.
> Brian is right that there will never be an enhancement to a 
> single session
> protocol that will satisfy all applications.
> However, for similar reasons, it is never going to be 
> possible to prescribe
> a single QoS mechanism to be used in all networks. Existing 
> networks (or
> domains) will not be changed overnight and new networks 
> already face several
> workable mechanisms to deploy QoS.
> 
> I think that what is needed is a new protocol that can signal the
> requirements of any session and can be satisfied by any QoS mechanism,
> existing or new.
> To be more precise, I am suggesting a new protocol that is 
> independent of
> the underlying transport technology and the QoS implemented 
> and is also
> independent of the session control protocol. Such a new 
> protocol would be
> generic, optionally implemented by applications that would 
> benefit from
> end-to-end QoS, and would be complimentary to the QoS 
> mechanisms deployed
> (and of course other mechanisms, such as the routing).
> 
> I think that this implies a more abstract definition of the 
> QoS mechanism
> and may lend itself to the signalling of pre-defined QoS 
> classes rather than
> parameters.
> 
> Dick Knight
> 
> -----Original Message-----
> From: Brian Williams [mailto:brian.williams@ericsson.com.au]
> Sent: 22 December 2001 23:57
> To: lieve.bos@alcatel.be
> Cc: nsis@ietf.org
> Subject: Re: [NSIS] Two kinds of requirements
> 
> 
> Hi.
> While the two types of signalling may be related, I think there is a
> need to develop a QoS bearer mechanism which is independent of any
> specific session signalling, and thus can be used for any 
> application. I
> believe many of the applications which have identified requirements to
> the working group have their own specific session layer signalling (ie
> it is not end-to-end SIP).  
> 
> Having the session and transport protocols developed separately of
> course does not prohibit the two being used in conjunction for a
> specific application.
> /brian
>  
> On Fri, 2001-12-21 at 22:24, lieve.bos@alcatel.be wrote:
> > Hello all,
> > 
> > >From the discussion in Salt Lake city and the drafts 
> submitted, one can
> > easily see that people are suggesting improvements to QoS 
> signalling at
> > two totally different levels (some at session level and some at
> > transport level).
> > 
> > First of all, there are drafts suggesting some improvements in the
> > session setup procedures (i.e. the ability to negotiate the 
> preferred
> > QoS level between end users during SDP negotiation in SIP, 
> so before the
> > actual resources are being setup). The QoS information 
> negotiated at the
> > session layer determines the QoS level both endusers have 
> to use for 
> > their local access connection. This first kind of 'session level QoS
> > negotiation' happens end-to-end between the two end-users.
> > 
> > Secondly, there are drafts suggesting that we need
> > improvements/alternatives for the QoS signalling protocols 
> (e.g. RSVP)
> > used to actually provision the QoS at the transport level 
> between two
> > endusers. This second kind of 'transport level QoS signalling' can
> > consist of several phases: end-to-edge and edge-to-edge. 
> > 
> > It's important that everybody realises that, in order to 
> give endusers
> > true end-to-end Quality of Service, we need improvements 
> for QoS both at
> > session and transport level. Also its important to 
> understand that they
> > are not uncorrelated. Providers want to be able to control (e.g. via
> > policy control mechanisms) that the QoS requested at the 
> transport level
> > is not exceeding the QoS negotiated/authorised previously at session
> > level. So, what about developing in NSIS a modular framework
> > incorporating both session and transport level QoS signalling with
> > possible hooks between the two layers (e.g. for policy enforcement).
> > 
> > Lieve
> > 
> > _______________________________________________
> > nsis mailing list
> > nsis@ietf.org
> > https://www1.ietf.org/mailman/listinfo/nsis
> 
> 
> 
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis
> 
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis
> 
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis
> 
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis
> 

------_=_NextPart_001_01C19F87.203BB5F0
Content-Type: text/html;
	charset="ISO-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2654.89">
<TITLE>RE: [NSIS] Two kinds of requirements</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>I agree whole-heartedly with Weijing here.</FONT>
<BR><FONT SIZE=2>The internet model trys to keep the &quot;intelligence&quot; at</FONT>
<BR><FONT SIZE=2>the host, however, the down side with this approach</FONT>
<BR><FONT SIZE=2>is that with QoS (and indeed, any negotiable service or </FONT>
<BR><FONT SIZE=2>service characteristic), the host is burdened with having to </FONT>
<BR><FONT SIZE=2>have knowledge of the network. The second down side,</FONT>
<BR><FONT SIZE=2>particularly important for those of us working in wireless,</FONT>
<BR><FONT SIZE=2>is the need to pass information between host and network.</FONT>
</P>

<P><FONT SIZE=2>There is more then one protocol here, or at least, more then</FONT>
<BR><FONT SIZE=2>one flavour/configuration of a protocol. One flavour allows</FONT>
<BR><FONT SIZE=2>the host to tell the access network &quot;give me one of the services</FONT>
<BR><FONT SIZE=2>my user has contracted with you to use&quot;, the other flavour allows</FONT>
<BR><FONT SIZE=2>the network to figure out how to fullfill this contract, opaque</FONT>
<BR><FONT SIZE=2>to the host. Perhaps a third flavour allows one network to ask</FONT>
<BR><FONT SIZE=2>another network to provide a give service. (By &quot;service&quot; here</FONT>
<BR><FONT SIZE=2>I also imply &quot;service characteristic&quot; such as QoS).</FONT>
</P>

<P><FONT SIZE=2>As an example: do I really need to tell the host what path the</FONT>
<BR><FONT SIZE=2>network has selected in order to provide QoS? This is what RSVP</FONT>
<BR><FONT SIZE=2>end-to-end does. </FONT>
</P>

<P><FONT SIZE=2>Gary Kenward.</FONT>
</P>

<P><FONT SIZE=2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; From: Chen, Weijing [<A HREF="mailto:wchen@tri.sbc.com">mailto:wchen@tri.sbc.com</A>]</FONT>
<BR><FONT SIZE=2>&gt; Sent: January 17, 2002 10:52</FONT>
<BR><FONT SIZE=2>&gt; To: 'Georgios Karagiannis (ELN)'</FONT>
<BR><FONT SIZE=2>&gt; Cc: nsis@ietf.org</FONT>
<BR><FONT SIZE=2>&gt; Subject: RE: [NSIS] Two kinds of requirements</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Georgios,</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; First of all, the major objective for NSIS signaling for a </FONT>
<BR><FONT SIZE=2>&gt; service operator</FONT>
<BR><FONT SIZE=2>&gt; point of view is that KISS (keep it simple, stupid?). We have </FONT>
<BR><FONT SIZE=2>&gt; seen some very</FONT>
<BR><FONT SIZE=2>&gt; good protocol in technical never got a chance to see the </FONT>
<BR><FONT SIZE=2>&gt; light in real world</FONT>
<BR><FONT SIZE=2>&gt; commercially.&nbsp; Now based on this assumption, I have a </FONT>
<BR><FONT SIZE=2>&gt; question regarding the</FONT>
<BR><FONT SIZE=2>&gt; [everyhop] part of protocol: Who is initiating and </FONT>
<BR><FONT SIZE=2>&gt; constructing it content?</FONT>
<BR><FONT SIZE=2>&gt; If it is host, I am afraid that we may ask too much for the </FONT>
<BR><FONT SIZE=2>&gt; host. Now if we</FONT>
<BR><FONT SIZE=2>&gt; let [edge] to inject some additional information for </FONT>
<BR><FONT SIZE=2>&gt; [everyhop] instead of</FONT>
<BR><FONT SIZE=2>&gt; [host], then it could be a solution. [edge] is intelligent </FONT>
<BR><FONT SIZE=2>&gt; and powerful, it</FONT>
<BR><FONT SIZE=2>&gt; knows a lot more about the core [hop] than [host]. We should </FONT>
<BR><FONT SIZE=2>&gt; insulate the</FONT>
<BR><FONT SIZE=2>&gt; [host] from what the network it except necessary part.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; --</FONT>
<BR><FONT SIZE=2>&gt; Weijing Chen</FONT>
<BR><FONT SIZE=2>&gt; SBC Technology Resources</FONT>
<BR><FONT SIZE=2>&gt; 9505 Arboretum Blvd.</FONT>
<BR><FONT SIZE=2>&gt; Austin, TX 78759</FONT>
<BR><FONT SIZE=2>&gt; 512 372 5710</FONT>
<BR><FONT SIZE=2>&gt; wchen@tri.sbc.com</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt;&nbsp; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; From: &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Georgios Karagiannis (ELN)</FONT>
<BR><FONT SIZE=2>&gt; [<A HREF="mailto:Georgios.Karagiannis@eln.ericsson.se">mailto:Georgios.Karagiannis@eln.ericsson.se</A>] </FONT>
<BR><FONT SIZE=2>&gt; Sent: Thursday, January 17, 2002 9:27 AM</FONT>
<BR><FONT SIZE=2>&gt; To:&nbsp;&nbsp; Chen, Weijing</FONT>
<BR><FONT SIZE=2>&gt; Cc:&nbsp;&nbsp; nsis@ietf.org</FONT>
<BR><FONT SIZE=2>&gt; Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; RE: [NSIS] Two kinds of requirements</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Hi Weijing</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Please note that the access network, i.e., the network between the </FONT>
<BR><FONT SIZE=2>&gt; [host] and [edge] will include [interior] nodes. </FONT>
<BR><FONT SIZE=2>&gt; These [interior] nodes will only process and use </FONT>
<BR><FONT SIZE=2>&gt; only the &quot;everyhop&quot; protocol component. </FONT>
<BR><FONT SIZE=2>&gt; The &quot;everyhost&quot; and &quot;everyedge&quot; protocol components are not </FONT>
<BR><FONT SIZE=2>&gt; processed (used or checked). I did not show this into the </FONT>
<BR><FONT SIZE=2>&gt; protocol decomposition figure that I sent (reply to Dick), </FONT>
<BR><FONT SIZE=2>&gt; but it should be there. </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Moreover, I agree that the QoS for 1 and 2 can be supported by</FONT>
<BR><FONT SIZE=2>&gt; over-provisioning, MPLS tunnel, etc., </FONT>
<BR><FONT SIZE=2>&gt; but if needed it should also be supported by the NSIS signaling </FONT>
<BR><FONT SIZE=2>&gt; protocol.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Best Regards,</FONT>
<BR><FONT SIZE=2>&gt; Georgios</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; From: Chen, Weijing [<A HREF="mailto:wchen@tri.sbc.com">mailto:wchen@tri.sbc.com</A>]</FONT>
<BR><FONT SIZE=2>&gt; Sent: donderdag 17 januari 2002 15:54</FONT>
<BR><FONT SIZE=2>&gt; To: 'Georgios Karagiannis (ELN)'</FONT>
<BR><FONT SIZE=2>&gt; Cc: nsis@ietf.org</FONT>
<BR><FONT SIZE=2>&gt; Subject: RE: [NSIS] Two kinds of requirements</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Georgois,</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Regarding the modularization of signaling protocol, I think that the</FONT>
<BR><FONT SIZE=2>&gt; following is more close to what we want:</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; [host] &lt;-----NSIS signaling------&gt;[edge]</FONT>
<BR><FONT SIZE=2>&gt; ....1...[core]....2...[core]....1...[edge]&lt;---NSIS </FONT>
<BR><FONT SIZE=2>&gt; signaling----&gt;[host]</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; 1 and 2 could be over-provisioning, CoS routing, MPLS tunnel, ATM</FONT>
<BR><FONT SIZE=2>&gt; connection, etc. The main objective is to keep NSIS signaling </FONT>
<BR><FONT SIZE=2>&gt; simple and</FONT>
<BR><FONT SIZE=2>&gt; widespread implementable, and independent of what core uses. </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; --</FONT>
<BR><FONT SIZE=2>&gt; Weijing Chen</FONT>
<BR><FONT SIZE=2>&gt; SBC Technology Resources</FONT>
<BR><FONT SIZE=2>&gt; 9505 Arboretum Blvd.</FONT>
<BR><FONT SIZE=2>&gt; Austin, TX 78759</FONT>
<BR><FONT SIZE=2>&gt; 512 372 5710</FONT>
<BR><FONT SIZE=2>&gt; wchen@tri.sbc.com</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt;&nbsp; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; From: &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Georgios Karagiannis (ELN)</FONT>
<BR><FONT SIZE=2>&gt; [<A HREF="mailto:Georgios.Karagiannis@eln.ericsson.se">mailto:Georgios.Karagiannis@eln.ericsson.se</A>] </FONT>
<BR><FONT SIZE=2>&gt; Sent: Thursday, January 17, 2002 3:39 AM</FONT>
<BR><FONT SIZE=2>&gt; To:&nbsp;&nbsp; 'dick.rr.knight@bt.com'</FONT>
<BR><FONT SIZE=2>&gt; Cc:&nbsp;&nbsp; nsis@ietf.org</FONT>
<BR><FONT SIZE=2>&gt; Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; RE: [NSIS] Two kinds of requirements</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Hi Dick </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; In principle I agree with your comment (see below).</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; [DK] &gt;&gt; To be more precise, I am suggesting a new protocol that is </FONT>
<BR><FONT SIZE=2>&gt; [DK] &gt;&gt; independent of the underlying transport technology </FONT>
<BR><FONT SIZE=2>&gt; and the QoS </FONT>
<BR><FONT SIZE=2>&gt; [DK] &gt;&gt; implemented and is also independent of the session </FONT>
<BR><FONT SIZE=2>&gt; control protocol.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; However, a very important point here is that we need to </FONT>
<BR><FONT SIZE=2>&gt; specify a protocol that can be used independent of the </FONT>
<BR><FONT SIZE=2>&gt; underlying transport </FONT>
<BR><FONT SIZE=2>&gt; technology, but that can satisfy the QoS requirements imposed </FONT>
<BR><FONT SIZE=2>&gt; by these </FONT>
<BR><FONT SIZE=2>&gt; underlying transport technologies. Otherwise the protocol will not be</FONT>
<BR><FONT SIZE=2>&gt; suitable</FONT>
<BR><FONT SIZE=2>&gt; and useful.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; A way of achieving this is by first creating a modular QoS </FONT>
<BR><FONT SIZE=2>&gt; signaling toolkit</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; that will contain mandatory and optional QoS requirements;</FONT>
<BR><FONT SIZE=2>&gt; Second, specify how the protocol functionality should be separated in </FONT>
<BR><FONT SIZE=2>&gt; building blocks (protocol components) and define a minimum set </FONT>
<BR><FONT SIZE=2>&gt; of mandatory reservation options/features that should be </FONT>
<BR><FONT SIZE=2>&gt; processed by any network nodes, e.g., end-hosts,</FONT>
<BR><FONT SIZE=2>&gt; proxies, edges and interior nodes.</FONT>
<BR><FONT SIZE=2>&gt; An example of such a protocol decomposition is given below!</FONT>
<BR><FONT SIZE=2>&gt; In this way each node will only process (check and use) the protocol </FONT>
<BR><FONT SIZE=2>&gt; components of interest.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; |---------|</FONT>
<BR><FONT SIZE=2>&gt; |---------|</FONT>
<BR><FONT SIZE=2>&gt; |everyhost|&lt;--------------------------------------------------</FONT>
<BR><FONT SIZE=2>&gt; -----&gt;|everyho</FONT>
<BR><FONT SIZE=2>&gt; st|</FONT>
<BR><FONT SIZE=2>&gt; |---------|</FONT>
<BR><FONT SIZE=2>&gt; |---------|</FONT>
<BR><FONT SIZE=2>&gt; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</FONT>
<BR><FONT SIZE=2>&gt; |</FONT>
<BR><FONT SIZE=2>&gt; |---------|&nbsp;&nbsp; |---------|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |---------|</FONT>
<BR><FONT SIZE=2>&gt; |---------|</FONT>
<BR><FONT SIZE=2>&gt; |everyedge|&lt;-&gt;|everyedge|&lt;---------------------------&gt;|everyed</FONT>
<BR><FONT SIZE=2>&gt; ge|&lt;-&gt;|everyed</FONT>
<BR><FONT SIZE=2>&gt; ge|</FONT>
<BR><FONT SIZE=2>&gt; |---------|&nbsp;&nbsp; |---------|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |---------|</FONT>
<BR><FONT SIZE=2>&gt; |---------|</FONT>
<BR><FONT SIZE=2>&gt; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp; |</FONT>
<BR><FONT SIZE=2>&gt; |</FONT>
<BR><FONT SIZE=2>&gt; |---------|&nbsp;&nbsp; |---------|&nbsp;&nbsp; |--------|&nbsp;&nbsp; |--------|&nbsp;&nbsp; |---------|</FONT>
<BR><FONT SIZE=2>&gt; |---------|</FONT>
<BR><FONT SIZE=2>&gt; |everyhop |&lt;-&gt;|everyhop |&lt;-&gt;|everyhop|&lt;-&gt;|everyhop|&lt;-&gt;|everyhop</FONT>
<BR><FONT SIZE=2>&gt; |&lt;-&gt;|everyhop |</FONT>
<BR><FONT SIZE=2>&gt; |---------|&nbsp;&nbsp; |---------|&nbsp;&nbsp; |--------|&nbsp;&nbsp; |--------|&nbsp;&nbsp; |---------|</FONT>
<BR><FONT SIZE=2>&gt; |---------| </FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; host&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; edge&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; interior&nbsp;&nbsp;&nbsp; interior&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; edge </FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; host</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp; NSIS protocol decomposition (building blocks): </FONT>
<BR><FONT SIZE=2>&gt;&nbsp; *&nbsp; &quot;everyhost&quot;, &quot;everyedge&quot; and &quot;everyhop&quot; are protocol components;</FONT>
<BR><FONT SIZE=2>&gt;&nbsp; *&nbsp; host: can be an end-host or a proxy and it can process and use the</FONT>
<BR><FONT SIZE=2>&gt; &quot;everyhost&quot;, </FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; &quot;everyedge&quot;, and &quot;everyhop&quot; protocol components;</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt;&nbsp; *&nbsp; edge: can be a Diffserv edge, MPLS edge, etc., and it can </FONT>
<BR><FONT SIZE=2>&gt; process and</FONT>
<BR><FONT SIZE=2>&gt; use </FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; the &quot;everyedge&quot;, and &quot;everyhop&quot; protocol components. The </FONT>
<BR><FONT SIZE=2>&gt; &quot;everyhost&quot; </FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; protocol component is not processed (used or checked);</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt;&nbsp; *&nbsp; interior: can be any router within a domain and it can </FONT>
<BR><FONT SIZE=2>&gt; process and use </FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; only the &quot;everyhop&quot; protocol component.</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; The &quot;everyhost&quot; and &quot;everyedge&quot; protocol components are not </FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; processed (used or checked);</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Best Regards,</FONT>
<BR><FONT SIZE=2>&gt; Georgios</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; From: dick.rr.knight@bt.com [<A HREF="mailto:dick.rr.knight@bt.com">mailto:dick.rr.knight@bt.com</A>]</FONT>
<BR><FONT SIZE=2>&gt; Sent: woensdag 16 januari 2002 13:00</FONT>
<BR><FONT SIZE=2>&gt; To: brian.williams@ericsson.com.au; lieve.bos@alcatel.be</FONT>
<BR><FONT SIZE=2>&gt; Cc: nsis@ietf.org</FONT>
<BR><FONT SIZE=2>&gt; Subject: RE: [NSIS] Two kinds of requirements</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; I was waiting for some reaction to Brian's comments, but as </FONT>
<BR><FONT SIZE=2>&gt; there aren't</FONT>
<BR><FONT SIZE=2>&gt; any, here are my thoughts on the requirements:</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; I agree with the analysis that discussion has been based around</FONT>
<BR><FONT SIZE=2>&gt; application-related signalling for QoS (at session level) and </FONT>
<BR><FONT SIZE=2>&gt; QoS signalling</FONT>
<BR><FONT SIZE=2>&gt; protocols used to actually provision the QoS at the transport level.</FONT>
<BR><FONT SIZE=2>&gt; Brian is right that there will never be an enhancement to a </FONT>
<BR><FONT SIZE=2>&gt; single session</FONT>
<BR><FONT SIZE=2>&gt; protocol that will satisfy all applications.</FONT>
<BR><FONT SIZE=2>&gt; However, for similar reasons, it is never going to be </FONT>
<BR><FONT SIZE=2>&gt; possible to prescribe</FONT>
<BR><FONT SIZE=2>&gt; a single QoS mechanism to be used in all networks. Existing </FONT>
<BR><FONT SIZE=2>&gt; networks (or</FONT>
<BR><FONT SIZE=2>&gt; domains) will not be changed overnight and new networks </FONT>
<BR><FONT SIZE=2>&gt; already face several</FONT>
<BR><FONT SIZE=2>&gt; workable mechanisms to deploy QoS.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; I think that what is needed is a new protocol that can signal the</FONT>
<BR><FONT SIZE=2>&gt; requirements of any session and can be satisfied by any QoS mechanism,</FONT>
<BR><FONT SIZE=2>&gt; existing or new.</FONT>
<BR><FONT SIZE=2>&gt; To be more precise, I am suggesting a new protocol that is </FONT>
<BR><FONT SIZE=2>&gt; independent of</FONT>
<BR><FONT SIZE=2>&gt; the underlying transport technology and the QoS implemented </FONT>
<BR><FONT SIZE=2>&gt; and is also</FONT>
<BR><FONT SIZE=2>&gt; independent of the session control protocol. Such a new </FONT>
<BR><FONT SIZE=2>&gt; protocol would be</FONT>
<BR><FONT SIZE=2>&gt; generic, optionally implemented by applications that would </FONT>
<BR><FONT SIZE=2>&gt; benefit from</FONT>
<BR><FONT SIZE=2>&gt; end-to-end QoS, and would be complimentary to the QoS </FONT>
<BR><FONT SIZE=2>&gt; mechanisms deployed</FONT>
<BR><FONT SIZE=2>&gt; (and of course other mechanisms, such as the routing).</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; I think that this implies a more abstract definition of the </FONT>
<BR><FONT SIZE=2>&gt; QoS mechanism</FONT>
<BR><FONT SIZE=2>&gt; and may lend itself to the signalling of pre-defined QoS </FONT>
<BR><FONT SIZE=2>&gt; classes rather than</FONT>
<BR><FONT SIZE=2>&gt; parameters.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Dick Knight</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; From: Brian Williams [<A HREF="mailto:brian.williams@ericsson.com.au">mailto:brian.williams@ericsson.com.au</A>]</FONT>
<BR><FONT SIZE=2>&gt; Sent: 22 December 2001 23:57</FONT>
<BR><FONT SIZE=2>&gt; To: lieve.bos@alcatel.be</FONT>
<BR><FONT SIZE=2>&gt; Cc: nsis@ietf.org</FONT>
<BR><FONT SIZE=2>&gt; Subject: Re: [NSIS] Two kinds of requirements</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Hi.</FONT>
<BR><FONT SIZE=2>&gt; While the two types of signalling may be related, I think there is a</FONT>
<BR><FONT SIZE=2>&gt; need to develop a QoS bearer mechanism which is independent of any</FONT>
<BR><FONT SIZE=2>&gt; specific session signalling, and thus can be used for any </FONT>
<BR><FONT SIZE=2>&gt; application. I</FONT>
<BR><FONT SIZE=2>&gt; believe many of the applications which have identified requirements to</FONT>
<BR><FONT SIZE=2>&gt; the working group have their own specific session layer signalling (ie</FONT>
<BR><FONT SIZE=2>&gt; it is not end-to-end SIP).&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Having the session and transport protocols developed separately of</FONT>
<BR><FONT SIZE=2>&gt; course does not prohibit the two being used in conjunction for a</FONT>
<BR><FONT SIZE=2>&gt; specific application.</FONT>
<BR><FONT SIZE=2>&gt; /brian</FONT>
<BR><FONT SIZE=2>&gt;&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; On Fri, 2001-12-21 at 22:24, lieve.bos@alcatel.be wrote:</FONT>
<BR><FONT SIZE=2>&gt; &gt; Hello all,</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;From the discussion in Salt Lake city and the drafts </FONT>
<BR><FONT SIZE=2>&gt; submitted, one can</FONT>
<BR><FONT SIZE=2>&gt; &gt; easily see that people are suggesting improvements to QoS </FONT>
<BR><FONT SIZE=2>&gt; signalling at</FONT>
<BR><FONT SIZE=2>&gt; &gt; two totally different levels (some at session level and some at</FONT>
<BR><FONT SIZE=2>&gt; &gt; transport level).</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; First of all, there are drafts suggesting some improvements in the</FONT>
<BR><FONT SIZE=2>&gt; &gt; session setup procedures (i.e. the ability to negotiate the </FONT>
<BR><FONT SIZE=2>&gt; preferred</FONT>
<BR><FONT SIZE=2>&gt; &gt; QoS level between end users during SDP negotiation in SIP, </FONT>
<BR><FONT SIZE=2>&gt; so before the</FONT>
<BR><FONT SIZE=2>&gt; &gt; actual resources are being setup). The QoS information </FONT>
<BR><FONT SIZE=2>&gt; negotiated at the</FONT>
<BR><FONT SIZE=2>&gt; &gt; session layer determines the QoS level both endusers have </FONT>
<BR><FONT SIZE=2>&gt; to use for </FONT>
<BR><FONT SIZE=2>&gt; &gt; their local access connection. This first kind of 'session level QoS</FONT>
<BR><FONT SIZE=2>&gt; &gt; negotiation' happens end-to-end between the two end-users.</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; Secondly, there are drafts suggesting that we need</FONT>
<BR><FONT SIZE=2>&gt; &gt; improvements/alternatives for the QoS signalling protocols </FONT>
<BR><FONT SIZE=2>&gt; (e.g. RSVP)</FONT>
<BR><FONT SIZE=2>&gt; &gt; used to actually provision the QoS at the transport level </FONT>
<BR><FONT SIZE=2>&gt; between two</FONT>
<BR><FONT SIZE=2>&gt; &gt; endusers. This second kind of 'transport level QoS signalling' can</FONT>
<BR><FONT SIZE=2>&gt; &gt; consist of several phases: end-to-edge and edge-to-edge. </FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; It's important that everybody realises that, in order to </FONT>
<BR><FONT SIZE=2>&gt; give endusers</FONT>
<BR><FONT SIZE=2>&gt; &gt; true end-to-end Quality of Service, we need improvements </FONT>
<BR><FONT SIZE=2>&gt; for QoS both at</FONT>
<BR><FONT SIZE=2>&gt; &gt; session and transport level. Also its important to </FONT>
<BR><FONT SIZE=2>&gt; understand that they</FONT>
<BR><FONT SIZE=2>&gt; &gt; are not uncorrelated. Providers want to be able to control (e.g. via</FONT>
<BR><FONT SIZE=2>&gt; &gt; policy control mechanisms) that the QoS requested at the </FONT>
<BR><FONT SIZE=2>&gt; transport level</FONT>
<BR><FONT SIZE=2>&gt; &gt; is not exceeding the QoS negotiated/authorised previously at session</FONT>
<BR><FONT SIZE=2>&gt; &gt; level. So, what about developing in NSIS a modular framework</FONT>
<BR><FONT SIZE=2>&gt; &gt; incorporating both session and transport level QoS signalling with</FONT>
<BR><FONT SIZE=2>&gt; &gt; possible hooks between the two layers (e.g. for policy enforcement).</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; Lieve</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; _______________________________________________</FONT>
<BR><FONT SIZE=2>&gt; &gt; nsis mailing list</FONT>
<BR><FONT SIZE=2>&gt; &gt; nsis@ietf.org</FONT>
<BR><FONT SIZE=2>&gt; &gt; <A HREF="https://www1.ietf.org/mailman/listinfo/nsis" TARGET="_blank">https://www1.ietf.org/mailman/listinfo/nsis</A></FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; _______________________________________________</FONT>
<BR><FONT SIZE=2>&gt; nsis mailing list</FONT>
<BR><FONT SIZE=2>&gt; nsis@ietf.org</FONT>
<BR><FONT SIZE=2>&gt; <A HREF="https://www1.ietf.org/mailman/listinfo/nsis" TARGET="_blank">https://www1.ietf.org/mailman/listinfo/nsis</A></FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; _______________________________________________</FONT>
<BR><FONT SIZE=2>&gt; nsis mailing list</FONT>
<BR><FONT SIZE=2>&gt; nsis@ietf.org</FONT>
<BR><FONT SIZE=2>&gt; <A HREF="https://www1.ietf.org/mailman/listinfo/nsis" TARGET="_blank">https://www1.ietf.org/mailman/listinfo/nsis</A></FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; _______________________________________________</FONT>
<BR><FONT SIZE=2>&gt; nsis mailing list</FONT>
<BR><FONT SIZE=2>&gt; nsis@ietf.org</FONT>
<BR><FONT SIZE=2>&gt; <A HREF="https://www1.ietf.org/mailman/listinfo/nsis" TARGET="_blank">https://www1.ietf.org/mailman/listinfo/nsis</A></FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; _______________________________________________</FONT>
<BR><FONT SIZE=2>&gt; nsis mailing list</FONT>
<BR><FONT SIZE=2>&gt; nsis@ietf.org</FONT>
<BR><FONT SIZE=2>&gt; <A HREF="https://www1.ietf.org/mailman/listinfo/nsis" TARGET="_blank">https://www1.ietf.org/mailman/listinfo/nsis</A></FONT>
<BR><FONT SIZE=2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C19F87.203BB5F0--

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



From daemon@optimus.ietf.org  Thu Jan 17 14:04: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 OAA00506
	for <nsis-archive@odin.ietf.org>; Thu, 17 Jan 2002 14:04:30 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id OAA18769
	for nsis-archive@odin.ietf.org; Thu, 17 Jan 2002 14:04: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 NAA18009;
	Thu, 17 Jan 2002 13:54: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 NAA17977
	for <nsis@optimus.ietf.org>; Thu, 17 Jan 2002 13:54:54 -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 NAA00307
	for <nsis@ietf.org>; Thu, 17 Jan 2002 13:54:51 -0500 (EST)
Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56])
	by zcars0m9.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g0HIsKb29316;
	Thu, 17 Jan 2002 13:54:20 -0500 (EST)
Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7])
	by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g0HIsHG07631;
	Thu, 17 Jan 2002 13:54:18 -0500 (EST)
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19)
	id <C8PZV6Y9>; Thu, 17 Jan 2002 13:54:17 -0500
Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4786@zcard031.ca.nortel.com>
From: "Gary Kenward"<gkenward@nortelnetworks.com>
To: "'Roy, Radhika R, ALASO'" <rrroy@att.com>,
        "Loughney John (NRC/Helsinki)" <john.loughney@nokia.com>,
        brunner@ccrle.nec.de, Yaron Kahana <ykahana@comgates.co.il>,
        "Geib, Ruediger" <Ruediger.Geib@t-systems.com>, dick.rr.knight@bt.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements
Date: Thu, 17 Jan 2002 13:54:15 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C19F88.5C103820"
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_01C19F88.5C103820
Content-Type: text/plain;
	charset="ISO-8859-1"

Roy:

 I think we agree. 

Gary

> -----Original Message-----
> From: Roy, Radhika R, ALASO [mailto:rrroy@att.com]
> Sent: January 17, 2002 13:37
> To: Kenward, Gary [WDLN2:AN10:EXCH]; Loughney John (NRC/Helsinki);
> brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
> dick.rr.knight@bt.com
> Cc: nsis@ietf.org
> Subject: RE: [NSIS] Two kinds of requirements
> 
> 
>         Inputs are inline [Roy, Radhika R, ALARC] .
> 
> -----Original Message-----
> From: Gary Kenward [mailto:gkenward@nortelnetworks.com]
> Sent: Thursday, January 17, 2002 1:11 PM
> To: 'Loughney John (NRC/Helsinki)'; brunner@ccrle.nec.de; 
> Yaron Kahana; Geib, Ruediger; dick.rr.knight@bt.com
> Cc: nsis@ietf.org
> Subject: RE: [NSIS] Two kinds of requirements
> 
> 
> 
> hello 
> 
> Perhaps I'm off track here, but it seems to me that how a particular 
> user service is mapped to particular network services and, in 
> particular, 
> resource allocation, is/should be completely under the 
> operators purvue. 
> [Roy, Radhika R, ALARC]  I would say that it is the QOS needs 
> of the application (e.g., SIP-based VoIP) that the user likes 
> to express (as opposed to "service"). Similarly, instead of 
> network services, we would say network layer QOS services 
> (e.g., RSVP, DiffServ, MPLS). We would develop the end-to-end 
> (application layer) QOS signaling protocol (say, NSIS QOS). 
> Now, there needs to have some kinds of standards how NSIS QOS 
> will be mapped over RSVP, DiffServ, MPLS, etc.
> 
>  
> The tools the operator uses to define/support a given service 
> include network 
> engineering, traffic engineering, and policy management. 
> Customization and 
> flexibility are the key characteristics to any operator who 
> does not want to 
> be a "bit pipe" provider - i.e. who wants to be as profitable 
> as possible. 
> [Roy, Radhika R, ALARC] I agree these areas may be left at 
> the will of the operators and, no standardization may be required.
> 
> Whatever signalling solution is derived, it must not attempt 
> to standardize 
> user services. 
> [Roy, Radhika R, ALARC] On principle, we all agree that we 
> would not standardize any services.
> 
>  The only exception to this may be the one (maybe two) service(s) 
> that is(are) pervasive, namely telephony voice (BE internet 
> data). Even then, 
> there are still approaches that would allow flexibility for 
> these services 
> (different voice grades, gold, silver and platinum BE). 
> [Roy, Radhika R, ALARC] This is area where we may not put too 
> much time because other IETF WGs are more appropriate to 
> address these network layer QOS issues. We may try to work 
> together with those WGs. Our charter is limited to NSIS QOS, 
> mapping of NSIS QOS over RSVP/DiffServ/MPLS, and 
> recommendations (not standardization per se) of some 
> end-to-end implementation schemes. 
> 
> Just a thought. 
> Gary Kenward 
> 
> 

------_=_NextPart_001_01C19F88.5C103820
Content-Type: text/html;
	charset="ISO-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2654.89">
<TITLE>RE: [NSIS] Two kinds of requirements</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Roy:</FONT>
</P>

<P><FONT SIZE=2>&nbsp;I think we agree. </FONT>
</P>

<P><FONT SIZE=2>Gary</FONT>
</P>

<P><FONT SIZE=2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; From: Roy, Radhika R, ALASO [<A HREF="mailto:rrroy@att.com">mailto:rrroy@att.com</A>]</FONT>
<BR><FONT SIZE=2>&gt; Sent: January 17, 2002 13:37</FONT>
<BR><FONT SIZE=2>&gt; To: Kenward, Gary [WDLN2:AN10:EXCH]; Loughney John (NRC/Helsinki);</FONT>
<BR><FONT SIZE=2>&gt; brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;</FONT>
<BR><FONT SIZE=2>&gt; dick.rr.knight@bt.com</FONT>
<BR><FONT SIZE=2>&gt; Cc: nsis@ietf.org</FONT>
<BR><FONT SIZE=2>&gt; Subject: RE: [NSIS] Two kinds of requirements</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Inputs are inline [Roy, Radhika R, ALARC] .</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; From: Gary Kenward [<A HREF="mailto:gkenward@nortelnetworks.com">mailto:gkenward@nortelnetworks.com</A>]</FONT>
<BR><FONT SIZE=2>&gt; Sent: Thursday, January 17, 2002 1:11 PM</FONT>
<BR><FONT SIZE=2>&gt; To: 'Loughney John (NRC/Helsinki)'; brunner@ccrle.nec.de; </FONT>
<BR><FONT SIZE=2>&gt; Yaron Kahana; Geib, Ruediger; dick.rr.knight@bt.com</FONT>
<BR><FONT SIZE=2>&gt; Cc: nsis@ietf.org</FONT>
<BR><FONT SIZE=2>&gt; Subject: RE: [NSIS] Two kinds of requirements</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; hello </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Perhaps I'm off track here, but it seems to me that how a particular </FONT>
<BR><FONT SIZE=2>&gt; user service is mapped to particular network services and, in </FONT>
<BR><FONT SIZE=2>&gt; particular, </FONT>
<BR><FONT SIZE=2>&gt; resource allocation, is/should be completely under the </FONT>
<BR><FONT SIZE=2>&gt; operators purvue. </FONT>
<BR><FONT SIZE=2>&gt; [Roy, Radhika R, ALARC]&nbsp; I would say that it is the QOS needs </FONT>
<BR><FONT SIZE=2>&gt; of the application (e.g., SIP-based VoIP) that the user likes </FONT>
<BR><FONT SIZE=2>&gt; to express (as opposed to &quot;service&quot;). Similarly, instead of </FONT>
<BR><FONT SIZE=2>&gt; network services, we would say network layer QOS services </FONT>
<BR><FONT SIZE=2>&gt; (e.g., RSVP, DiffServ, MPLS). We would develop the end-to-end </FONT>
<BR><FONT SIZE=2>&gt; (application layer) QOS signaling protocol (say, NSIS QOS). </FONT>
<BR><FONT SIZE=2>&gt; Now, there needs to have some kinds of standards how NSIS QOS </FONT>
<BR><FONT SIZE=2>&gt; will be mapped over RSVP, DiffServ, MPLS, etc.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt;&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; The tools the operator uses to define/support a given service </FONT>
<BR><FONT SIZE=2>&gt; include network </FONT>
<BR><FONT SIZE=2>&gt; engineering, traffic engineering, and policy management. </FONT>
<BR><FONT SIZE=2>&gt; Customization and </FONT>
<BR><FONT SIZE=2>&gt; flexibility are the key characteristics to any operator who </FONT>
<BR><FONT SIZE=2>&gt; does not want to </FONT>
<BR><FONT SIZE=2>&gt; be a &quot;bit pipe&quot; provider - i.e. who wants to be as profitable </FONT>
<BR><FONT SIZE=2>&gt; as possible. </FONT>
<BR><FONT SIZE=2>&gt; [Roy, Radhika R, ALARC] I agree these areas may be left at </FONT>
<BR><FONT SIZE=2>&gt; the will of the operators and, no standardization may be required.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Whatever signalling solution is derived, it must not attempt </FONT>
<BR><FONT SIZE=2>&gt; to standardize </FONT>
<BR><FONT SIZE=2>&gt; user services. </FONT>
<BR><FONT SIZE=2>&gt; [Roy, Radhika R, ALARC] On principle, we all agree that we </FONT>
<BR><FONT SIZE=2>&gt; would not standardize any services.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt;&nbsp; The only exception to this may be the one (maybe two) service(s) </FONT>
<BR><FONT SIZE=2>&gt; that is(are) pervasive, namely telephony voice (BE internet </FONT>
<BR><FONT SIZE=2>&gt; data). Even then, </FONT>
<BR><FONT SIZE=2>&gt; there are still approaches that would allow flexibility for </FONT>
<BR><FONT SIZE=2>&gt; these services </FONT>
<BR><FONT SIZE=2>&gt; (different voice grades, gold, silver and platinum BE). </FONT>
<BR><FONT SIZE=2>&gt; [Roy, Radhika R, ALARC] This is area where we may not put too </FONT>
<BR><FONT SIZE=2>&gt; much time because other IETF WGs are more appropriate to </FONT>
<BR><FONT SIZE=2>&gt; address these network layer QOS issues. We may try to work </FONT>
<BR><FONT SIZE=2>&gt; together with those WGs. Our charter is limited to NSIS QOS, </FONT>
<BR><FONT SIZE=2>&gt; mapping of NSIS QOS over RSVP/DiffServ/MPLS, and </FONT>
<BR><FONT SIZE=2>&gt; recommendations (not standardization per se) of some </FONT>
<BR><FONT SIZE=2>&gt; end-to-end implementation schemes. </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Just a thought. </FONT>
<BR><FONT SIZE=2>&gt; Gary Kenward </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C19F88.5C103820--

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



From daemon@optimus.ietf.org  Thu Jan 17 14:08: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 OAA00707
	for <nsis-archive@odin.ietf.org>; Thu, 17 Jan 2002 14:08:43 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id OAA19011
	for nsis-archive@odin.ietf.org; Thu, 17 Jan 2002 14:08: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 OAA18922;
	Thu, 17 Jan 2002 14:07: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 OAA18891
	for <nsis@optimus.ietf.org>; Thu, 17 Jan 2002 14:07:24 -0500 (EST)
Received: from kcmso1.proxy.att.com (kcmso1.att.com [192.128.133.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00656
	for <nsis@ietf.org>; Thu, 17 Jan 2002 14:07:19 -0500 (EST)
Received: from attrh3i.attrh.att.com ([135.71.62.12])
	by kcmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id g0HJ6Gn23065
	for <nsis@ietf.org>; Thu, 17 Jan 2002 14:06:17 -0500 (EST)
Received: from occlust04evs1.ugd.att.com (135.71.164.12) by attrh3i.attrh.att.com (5.5.029)
        id 3C06950500AC3ABE; Thu, 17 Jan 2002 13:36:30 -0500
content-class: urn:content-classes:message
Subject: RE: [NSIS] Two kinds of requirements
Date: Thu, 17 Jan 2002 13:37:10 -0500
Message-ID: <62DA45D4963FA747BA1B253E266760F9011E706D@OCCLUST04EVS1.ugd.att.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Thread-Topic: [NSIS] Two kinds of requirements
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
Thread-Index: AcGfgtcDnx2N2wtzEdanAgCQJ3s5nwAAEimg
From: "Roy, Radhika R, ALASO" <rrroy@att.com>
To: "Gary Kenward" <gkenward@nortelnetworks.com>,
        "Loughney John (NRC/Helsinki)" <john.loughney@nokia.com>,
        <brunner@ccrle.nec.de>, "Yaron Kahana" <ykahana@comgates.co.il>,
        "Geib, Ruediger" <Ruediger.Geib@t-systems.com>,
        <dick.rr.knight@bt.com>
Cc: <nsis@ietf.org>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id OAA18892
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

        Inputs are inline [Roy, Radhika R, ALARC] .

-----Original Message-----
From: Gary Kenward [mailto:gkenward@nortelnetworks.com]
Sent: Thursday, January 17, 2002 1:11 PM
To: 'Loughney John (NRC/Helsinki)'; brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger; dick.rr.knight@bt.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements



hello 

Perhaps I'm off track here, but it seems to me that how a particular 
user service is mapped to particular network services and, in particular, 
resource allocation, is/should be completely under the operators purvue. 
[Roy, Radhika R, ALARC]  I would say that it is the QOS needs of the application (e.g., SIP-based VoIP) that the user likes to express (as opposed to "service"). Similarly, instead of network services, we would say network layer QOS services (e.g., RSVP, DiffServ, MPLS). We would develop the end-to-end (application layer) QOS signaling protocol (say, NSIS QOS). Now, there needs to have some kinds of standards how NSIS QOS will be mapped over RSVP, DiffServ, MPLS, etc.

 
The tools the operator uses to define/support a given service include network 
engineering, traffic engineering, and policy management. Customization and 
flexibility are the key characteristics to any operator who does not want to 
be a "bit pipe" provider - i.e. who wants to be as profitable as possible. 
[Roy, Radhika R, ALARC] I agree these areas may be left at the will of the operators and, no standardization may be required.

Whatever signalling solution is derived, it must not attempt to standardize 
user services. 
[Roy, Radhika R, ALARC] On principle, we all agree that we would not standardize any services.

 The only exception to this may be the one (maybe two) service(s) 
that is(are) pervasive, namely telephony voice (BE internet data). Even then, 
there are still approaches that would allow flexibility for these services 
(different voice grades, gold, silver and platinum BE). 
[Roy, Radhika R, ALARC] This is area where we may not put too much time because other IETF WGs are more appropriate to address these network layer QOS issues. We may try to work together with those WGs. Our charter is limited to NSIS QOS, mapping of NSIS QOS over RSVP/DiffServ/MPLS, and recommendations (not standardization per se) of some end-to-end implementation schemes. 

Just a thought. 
Gary Kenward 


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



From daemon@optimus.ietf.org  Thu Jan 17 14:59:43 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05877
	for <nsis-archive@odin.ietf.org>; Thu, 17 Jan 2002 14:59:43 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id OAA21289
	for nsis-archive@odin.ietf.org; Thu, 17 Jan 2002 14:59: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 OAA21204;
	Thu, 17 Jan 2002 14:56: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 OAA21171
	for <nsis@optimus.ietf.org>; Thu, 17 Jan 2002 14:56:49 -0500 (EST)
Received: from picard.ee.ucl.ac.uk (picard.ee.ucl.ac.uk [128.40.42.82])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05381
	for <nsis@ietf.org>; Thu, 17 Jan 2002 14:56:41 -0500 (EST)
Received: from dipsy.ee.ucl.ac.uk (dipsy [128.40.42.35])
	by picard.ee.ucl.ac.uk (8.10.2+Sun/8.10.2) with ESMTP id g0HJuLO19955;
	Thu, 17 Jan 2002 19:56:21 GMT
Message-Id: <5.1.0.14.0.20020117184436.02285e10@pop1.ee.ucl.ac.uk>
X-Sender: hdemeer@pop1.ee.ucl.ac.uk
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 17 Jan 2002 19:49:13 +0000
To: "Georgios Karagiannis (ELN)" <Georgios.Karagiannis@eln.ericsson.se>,
        "'Loughney John (NRC/Helsinki)'" <john.loughney@nokia.com>,
        "'ext Kappler Cornelia'" <Cornelia.Kappler@icn.siemens.de>
From: Hermann De Meer <h.demeer@ee.ucl.ac.uk>
Subject: RE: [NSIS] Two kinds of requirements
Cc: nsis@ietf.org
In-Reply-To: <E244E44D6AB85E40AEEF7EAABE3545FA82336B@enleent104.nl.eu.er
 icsson.se>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
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 all

At 14:09 17/01/2002 +0100, Georgios Karagiannis (ELN) wrote:
>Hi John and Cornelia
>
>I think that one of the requirements that should be included
>in the NSIS WG requirements document is that the NSIS protocol
>should be modular. Modular in the context of having
>a toolkit from which one can choose the applicable tools
>in order to manage QoS in a particular networking environment.

I believe you are raising a very important issue with the emphasis on 
modularity
of QoS architectures/signalling.

But one can generalize that: it's all about flexibility,
namely flexibility of signalling/control/provisioning vs. flexibility of 
applications/users.

Flexibility does not necessarily mean complexity, often on the contrary:
one side being flexible makes the life for the other side easier (think of 
airline ticket pricing:
the price for the *same seat* can vary in an order of magnitude simply
depending on how flexible you are!)

QoS signalling is about indicating of how "inflexible" you are from that 
perspective.
But looking at IntServ (RSVP) or DiffServ,  an interpretation of these signals
have traditionally been seen rather statically:

- a "one-size-fits-all"  "end-to-end" implementation of the mechanisms
- a "take-it-or-leave-it" approach: statically defined QoS classes.

this makes QoS provisioning cumbersome, complex, expensive (unnecessarily)
(and it may be a good deal the reason for the "failure/insufficiency" of 
current QoS solutions/
signalling techniques).

Remember, the success of IP networking has to a larger extend been due to 
the fact of
relying on flexibility and cooperation, for example, for congestion handling.
(or "exception" handling, if you want, by TCP-similar schemes)

in <draft-demeer-nsis-analyis-00.txt> we therefore make a point to extend 
QoS signalling for:

1) explicitly dealing with such "QoS exceptions" (there is also an economic 
argument for this)
     that is, not only signaling QoS preferences from applications to the 
network, but also
     QoS exceptions back from networks to applications or to between networks,
     and an expected cooperative adaptation.

2) allowing for flexible interpretations in different domains (core, 
access, mobile, wireless,
      administrative conditions, ....)


The "trick" may be to modify signalling (including RSVP) such that most 
flexibility/cooperation
can be re-gained by assuring a minimum support of inflexibility 
(intentionally not using the
the term QoS guarantee here).


--Hermann











>Best Regards,
>Georgios
>
>
>
>-----Original Message-----
>From: Loughney John (NRC/Helsinki) [mailto:john.loughney@nokia.com]
>Sent: donderdag 17 januari 2002 13:54
>To: 'ext Kappler Cornelia'; 'ext Georgios Karagiannis (ELN)'
>Cc: nsis@ietf.org
>Subject: RE: [NSIS] Two kinds of requirements
>
>
>Hi Cornelia,
>
> > to my understanding the very idea of the modular / toolkit
> > approach is providing basic "MUST" functionality, but at the
> > same time _leaving open_ the possiblity of later adding "MAY"
> > functionality.
> >
> > This means we should try designing the protocol such that
> > later "MAY" functionality can be added in a modular fashion.
>
>Yes, I agree with you & Georgios, however, with respect to
>the Requirements Document - I think we should only place
>MUSTs in such a document.
>
>John
>
>_______________________________________________
>nsis mailing list
>nsis@ietf.org
>https://www1.ietf.org/mailman/listinfo/nsis
>
>_______________________________________________
>nsis mailing list
>nsis@ietf.org
>https://www1.ietf.org/mailman/listinfo/nsis


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



From daemon@optimus.ietf.org  Thu Jan 17 17:14: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 RAA14472
	for <nsis-archive@odin.ietf.org>; Thu, 17 Jan 2002 17:14:43 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id RAA27341
	for nsis-archive@odin.ietf.org; Thu, 17 Jan 2002 17:14: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 RAA27299;
	Thu, 17 Jan 2002 17:12:54 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA27262
	for <nsis@optimus.ietf.org>; Thu, 17 Jan 2002 17:12:51 -0500 (EST)
Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14458
	for <nsis@ietf.org>; Thu, 17 Jan 2002 17:12:46 -0500 (EST)
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id g0HMBSI01540;
	Thu, 17 Jan 2002 14:12:12 -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 AAR86810;
	Thu, 17 Jan 2002 14:10:55 -0800 (PST)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA17069; Thu, 17 Jan 2002 14:11:27 -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: <15431.19471.257423.150121@thomasm-u1.cisco.com>
Date: Thu, 17 Jan 2002 14:11:27 -0800 (PST)
To: "Loughney John (NRC/Helsinki)" <john.loughney@nokia.com>
Cc: "'ext Kappler Cornelia'" <Cornelia.Kappler@icn.siemens.de>,
        "'ext Georgios Karagiannis (ELN)'" <Georgios.Karagiannis@eln.ericsson.se>,
        <nsis@ietf.org>
Subject: RE: [NSIS] Two kinds of requirements
In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEF5D937D@esebe004.NOE.Nokia.com>
References: <0C1353ABB1DEB74DB067ADFF749C4EEF5D937D@esebe004.NOE.Nokia.com>
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

Loughney John (NRC/Helsinki) writes:
 > Hi Cornelia,
 > 
 > > to my understanding the very idea of the modular / toolkit 
 > > approach is providing basic "MUST" functionality, but at the 
 > > same time _leaving open_ the possiblity of later adding "MAY" 
 > > functionality. 
 > > 
 > > This means we should try designing the protocol such that 
 > > later "MAY" functionality can be added in a modular fashion. 
 > 
 > Yes, I agree with you & Georgios, however, with respect to
 > the Requirements Document - I think we should only place
 > MUSTs in such a document.

   I think that Scott might have addressed this,
   but SHOULD's aren't necessarily an oxymoron in
   a requirements draft. The way I interpret that
   is that the design really, really ought to 
   implement the SHOULD requirement or have a very 
   good reason why it doesn't. MAY's are pretty
   much a waste, IMO.

	  Mike

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



From daemon@optimus.ietf.org  Thu Jan 17 20:22: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 UAA16868
	for <nsis-archive@odin.ietf.org>; Thu, 17 Jan 2002 20:22:48 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id UAA03057
	for nsis-archive@odin.ietf.org; Thu, 17 Jan 2002 20:22: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 UAA02998;
	Thu, 17 Jan 2002 20:17: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 UAA02970
	for <nsis@optimus.ietf.org>; Thu, 17 Jan 2002 20:17:37 -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 UAA16810
	for <nsis@ietf.org>; Thu, 17 Jan 2002 20:17:34 -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 g0I1JdT12261;
	Thu, 17 Jan 2002 19:19:39 -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 g0I1GuU15624;
	Thu, 17 Jan 2002 19:16:56 -0600 (CST)
Received: by TRIMAIL2.ad.tri.sbc.com with Internet Mail Service (5.5.2653.19)
	id <ZND32JLQ>; Thu, 17 Jan 2002 19:17:23 -0600
Message-ID: <905A1C4ABF353F4C8CC16FA9F53DD0D638B99C@TRIMAIL2.ad.tri.sbc.com>
From: "Schneider, Marco" <schneider@tri.sbc.com>
To: "'dick.rr.knight@bt.com'" <dick.rr.knight@bt.com>,
        brian.williams@ericsson.com.au, lieve.bos@alcatel.be
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements
Date: Thu, 17 Jan 2002 19:17:13 -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 Dick,

I want to second the general thrust of your comments below. 

To what extent would you agree that the signaling protocol should be
independent of the type or types of QOS specifications it carries?

Marco Schneider

-----Original Message-----
From: dick.rr.knight@bt.com [mailto:dick.rr.knight@bt.com]
Sent: Wednesday, January 16, 2002 6:00 AM
To: brian.williams@ericsson.com.au; lieve.bos@alcatel.be
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


I was waiting for some reaction to Brian's comments, but as there aren't
any, here are my thoughts on the requirements:

I agree with the analysis that discussion has been based around
application-related signalling for QoS (at session level) and QoS signalling
protocols used to actually provision the QoS at the transport level.
Brian is right that there will never be an enhancement to a single session
protocol that will satisfy all applications.
However, for similar reasons, it is never going to be possible to prescribe
a single QoS mechanism to be used in all networks. Existing networks (or
domains) will not be changed overnight and new networks already face several
workable mechanisms to deploy QoS.

I think that what is needed is a new protocol that can signal the
requirements of any session and can be satisfied by any QoS mechanism,
existing or new.
To be more precise, I am suggesting a new protocol that is independent of
the underlying transport technology and the QoS implemented and is also
independent of the session control protocol. Such a new protocol would be
generic, optionally implemented by applications that would benefit from
end-to-end QoS, and would be complimentary to the QoS mechanisms deployed
(and of course other mechanisms, such as the routing).

I think that this implies a more abstract definition of the QoS mechanism
and may lend itself to the signalling of pre-defined QoS classes rather than
parameters.

Dick Knight

-----Original Message-----
From: Brian Williams [mailto:brian.williams@ericsson.com.au]
Sent: 22 December 2001 23:57
To: lieve.bos@alcatel.be
Cc: nsis@ietf.org
Subject: Re: [NSIS] Two kinds of requirements


Hi.
While the two types of signalling may be related, I think there is a
need to develop a QoS bearer mechanism which is independent of any
specific session signalling, and thus can be used for any application. I
believe many of the applications which have identified requirements to
the working group have their own specific session layer signalling (ie
it is not end-to-end SIP).  

Having the session and transport protocols developed separately of
course does not prohibit the two being used in conjunction for a
specific application.
/brian
 
On Fri, 2001-12-21 at 22:24, lieve.bos@alcatel.be wrote:
> Hello all,
> 
> >From the discussion in Salt Lake city and the drafts submitted, one can
> easily see that people are suggesting improvements to QoS signalling at
> two totally different levels (some at session level and some at
> transport level).
> 
> First of all, there are drafts suggesting some improvements in the
> session setup procedures (i.e. the ability to negotiate the preferred
> QoS level between end users during SDP negotiation in SIP, so before the
> actual resources are being setup). The QoS information negotiated at the
> session layer determines the QoS level both endusers have to use for 
> their local access connection. This first kind of 'session level QoS
> negotiation' happens end-to-end between the two end-users.
> 
> Secondly, there are drafts suggesting that we need
> improvements/alternatives for the QoS signalling protocols (e.g. RSVP)
> used to actually provision the QoS at the transport level between two
> endusers. This second kind of 'transport level QoS signalling' can
> consist of several phases: end-to-edge and edge-to-edge. 
> 
> It's important that everybody realises that, in order to give endusers
> true end-to-end Quality of Service, we need improvements for QoS both at
> session and transport level. Also its important to understand that they
> are not uncorrelated. Providers want to be able to control (e.g. via
> policy control mechanisms) that the QoS requested at the transport level
> is not exceeding the QoS negotiated/authorised previously at session
> level. So, what about developing in NSIS a modular framework
> incorporating both session and transport level QoS signalling with
> possible hooks between the two layers (e.g. for policy enforcement).
> 
> Lieve
> 
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis



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

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

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



From daemon@optimus.ietf.org  Thu Jan 17 20:47: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 UAA17191
	for <nsis-archive@odin.ietf.org>; Thu, 17 Jan 2002 20:47:51 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id UAA04138
	for nsis-archive@odin.ietf.org; Thu, 17 Jan 2002 20:47: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 UAA04125;
	Thu, 17 Jan 2002 20:47: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 UAA04091
	for <nsis@optimus.ietf.org>; Thu, 17 Jan 2002 20:47:12 -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 UAA17165
	for <nsis@ietf.org>; Thu, 17 Jan 2002 20:47:09 -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 g0I1nET12397;
	Thu, 17 Jan 2002 19:49:14 -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 g0I1kQ616447;
	Thu, 17 Jan 2002 19:46:26 -0600 (CST)
Received: by TRIMAIL2.ad.tri.sbc.com with Internet Mail Service (5.5.2653.19)
	id <ZND32J37>; Thu, 17 Jan 2002 19:46:53 -0600
Message-ID: <905A1C4ABF353F4C8CC16FA9F53DD0D638B99E@TRIMAIL2.ad.tri.sbc.com>
From: "Schneider, Marco" <schneider@tri.sbc.com>
To: "'Roy, Radhika R, ALASO'" <rrroy@att.com>,
        Gary Kenward
	 <gkenward@nortelnetworks.com>,
        "Loughney John (NRC/Helsinki)"
	 <john.loughney@nokia.com>,
        brunner@ccrle.nec.de, Yaron Kahana
	 <ykahana@comgates.co.il>,
        "Geib, Ruediger" <Ruediger.Geib@t-systems.com>, dick.rr.knight@bt.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements
Date: Thu, 17 Jan 2002 19:46:52 -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 Roy,

Can you please define what you mean by "End-to-End Application Layer QOS
Signaling". Thanks.

Marco Schneider

-----Original Message-----
From: Roy, Radhika R, ALASO [mailto:rrroy@att.com]
Sent: Thursday, January 17, 2002 12:37 PM
To: Gary Kenward; Loughney John (NRC/Helsinki); brunner@ccrle.nec.de;
Yaron Kahana; Geib, Ruediger; dick.rr.knight@bt.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


        Inputs are inline [Roy, Radhika R, ALARC] .

-----Original Message-----
From: Gary Kenward [mailto:gkenward@nortelnetworks.com]
Sent: Thursday, January 17, 2002 1:11 PM
To: 'Loughney John (NRC/Helsinki)'; brunner@ccrle.nec.de; Yaron Kahana;
Geib, Ruediger; dick.rr.knight@bt.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements



hello 

Perhaps I'm off track here, but it seems to me that how a particular 
user service is mapped to particular network services and, in particular, 
resource allocation, is/should be completely under the operators purvue. 
[Roy, Radhika R, ALARC]  I would say that it is the QOS needs of the
application (e.g., SIP-based VoIP) that the user likes to express (as
opposed to "service"). Similarly, instead of network services, we would say
network layer QOS services (e.g., RSVP, DiffServ, MPLS). We would develop
the end-to-end (application layer) QOS signaling protocol (say, NSIS QOS).
Now, there needs to have some kinds of standards how NSIS QOS will be mapped
over RSVP, DiffServ, MPLS, etc.

 
The tools the operator uses to define/support a given service include
network 
engineering, traffic engineering, and policy management. Customization and 
flexibility are the key characteristics to any operator who does not want to

be a "bit pipe" provider - i.e. who wants to be as profitable as possible. 
[Roy, Radhika R, ALARC] I agree these areas may be left at the will of the
operators and, no standardization may be required.

Whatever signalling solution is derived, it must not attempt to standardize 
user services. 
[Roy, Radhika R, ALARC] On principle, we all agree that we would not
standardize any services.

 The only exception to this may be the one (maybe two) service(s) 
that is(are) pervasive, namely telephony voice (BE internet data). Even
then, 
there are still approaches that would allow flexibility for these services 
(different voice grades, gold, silver and platinum BE). 
[Roy, Radhika R, ALARC] This is area where we may not put too much time
because other IETF WGs are more appropriate to address these network layer
QOS issues. We may try to work together with those WGs. Our charter is
limited to NSIS QOS, mapping of NSIS QOS over RSVP/DiffServ/MPLS, and
recommendations (not standardization per se) of some end-to-end
implementation schemes. 

Just a thought. 
Gary Kenward 


_______________________________________________
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 Jan 17 20:57: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 UAA17308
	for <nsis-archive@odin.ietf.org>; Thu, 17 Jan 2002 20:57:24 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id UAA04378
	for nsis-archive@odin.ietf.org; Thu, 17 Jan 2002 20:57:26 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA03961;
	Thu, 17 Jan 2002 20:44: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 UAA03890
	for <nsis@optimus.ietf.org>; Thu, 17 Jan 2002 20:44:13 -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 UAA17126
	for <nsis@ietf.org>; Thu, 17 Jan 2002 20:44:10 -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 g0I1kFT12381;
	Thu, 17 Jan 2002 19:46: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 g0I1ha116388;
	Thu, 17 Jan 2002 19:43:38 -0600 (CST)
Received: by TRIMAIL2.ad.tri.sbc.com with Internet Mail Service (5.5.2653.19)
	id <ZND32J3V>; Thu, 17 Jan 2002 19:44:03 -0600
Message-ID: <905A1C4ABF353F4C8CC16FA9F53DD0D638B99D@TRIMAIL2.ad.tri.sbc.com>
From: "Schneider, Marco" <schneider@tri.sbc.com>
To: "'Georgios Karagiannis (ELN)'" <Georgios.Karagiannis@eln.ericsson.se>,
        "'dick.rr.knight@bt.com'" <dick.rr.knight@bt.com>
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements
Date: Thu, 17 Jan 2002 19:43:56 -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 Georgios,

While I agree NSIS could be used to support Interior to Interior (of one
carrier) or Edge to Core, I think that we need to prioritize on a signaling
protocol across the boundary between a customer and the network. Note that
the customer could be an individual, an ISP or another Carrier.

Marco Schneider

-----Original Message-----
From: Georgios Karagiannis (ELN)
[mailto:Georgios.Karagiannis@eln.ericsson.se]
Sent: Thursday, January 17, 2002 3:39 AM
To: 'dick.rr.knight@bt.com'
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


Hi Dick 

In principle I agree with your comment (see below).

[DK] >> To be more precise, I am suggesting a new protocol that is 
[DK] >> independent of the underlying transport technology and the QoS 
[DK] >> implemented and is also independent of the session control protocol.


However, a very important point here is that we need to 
specify a protocol that can be used independent of the underlying transport 
technology, but that can satisfy the QoS requirements imposed by these 
underlying transport technologies. Otherwise the protocol will not be
suitable
and useful.

A way of achieving this is by first creating a modular QoS signaling toolkit

that will contain mandatory and optional QoS requirements;
Second, specify how the protocol functionality should be separated in 
building blocks (protocol components) and define a minimum set 
of mandatory reservation options/features that should be 
processed by any network nodes, e.g., end-hosts,
proxies, edges and interior nodes.
An example of such a protocol decomposition is given below!
In this way each node will only process (check and use) the protocol 
components of interest.


|---------|
|---------|
|everyhost|<------------------------------------------------------->|everyho
st|
|---------|
|---------|
|         |                                                         |
|
|---------|   |---------|                             |---------|
|---------|
|everyedge|<->|everyedge|<--------------------------->|everyedge|<->|everyed
ge|
|---------|   |---------|                             |---------|
|---------|
|         |   |         |                             |         |   |
|
|---------|   |---------|   |--------|   |--------|   |---------|
|---------|
|everyhop |<->|everyhop |<->|everyhop|<->|everyhop|<->|everyhop
|<->|everyhop |
|---------|   |---------|   |--------|   |--------|   |---------|
|---------| 
    host          edge        interior    interior       edge          host


  NSIS protocol decomposition (building blocks): 
 *  "everyhost", "everyedge" and "everyhop" are protocol components;
 *  host: can be an end-host or a proxy and it can process and use the
"everyhost", 
    "everyedge", and "everyhop" protocol components;

 *  edge: can be a Diffserv edge, MPLS edge, etc., and it can process and
use 
    the "everyedge", and "everyhop" protocol components. The "everyhost" 
    protocol component is not processed (used or checked);

 *  interior: can be any router within a domain and it can process and use 
    only the "everyhop" protocol component.
    The "everyhost" and "everyedge" protocol components are not 
    processed (used or checked);


Best Regards,
Georgios

-----Original Message-----
From: dick.rr.knight@bt.com [mailto:dick.rr.knight@bt.com]
Sent: woensdag 16 januari 2002 13:00
To: brian.williams@ericsson.com.au; lieve.bos@alcatel.be
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


I was waiting for some reaction to Brian's comments, but as there aren't
any, here are my thoughts on the requirements:

I agree with the analysis that discussion has been based around
application-related signalling for QoS (at session level) and QoS signalling
protocols used to actually provision the QoS at the transport level.
Brian is right that there will never be an enhancement to a single session
protocol that will satisfy all applications.
However, for similar reasons, it is never going to be possible to prescribe
a single QoS mechanism to be used in all networks. Existing networks (or
domains) will not be changed overnight and new networks already face several
workable mechanisms to deploy QoS.

I think that what is needed is a new protocol that can signal the
requirements of any session and can be satisfied by any QoS mechanism,
existing or new.
To be more precise, I am suggesting a new protocol that is independent of
the underlying transport technology and the QoS implemented and is also
independent of the session control protocol. Such a new protocol would be
generic, optionally implemented by applications that would benefit from
end-to-end QoS, and would be complimentary to the QoS mechanisms deployed
(and of course other mechanisms, such as the routing).

I think that this implies a more abstract definition of the QoS mechanism
and may lend itself to the signalling of pre-defined QoS classes rather than
parameters.

Dick Knight

-----Original Message-----
From: Brian Williams [mailto:brian.williams@ericsson.com.au]
Sent: 22 December 2001 23:57
To: lieve.bos@alcatel.be
Cc: nsis@ietf.org
Subject: Re: [NSIS] Two kinds of requirements


Hi.
While the two types of signalling may be related, I think there is a
need to develop a QoS bearer mechanism which is independent of any
specific session signalling, and thus can be used for any application. I
believe many of the applications which have identified requirements to
the working group have their own specific session layer signalling (ie
it is not end-to-end SIP).  

Having the session and transport protocols developed separately of
course does not prohibit the two being used in conjunction for a
specific application.
/brian
 
On Fri, 2001-12-21 at 22:24, lieve.bos@alcatel.be wrote:
> Hello all,
> 
> >From the discussion in Salt Lake city and the drafts submitted, one can
> easily see that people are suggesting improvements to QoS signalling at
> two totally different levels (some at session level and some at
> transport level).
> 
> First of all, there are drafts suggesting some improvements in the
> session setup procedures (i.e. the ability to negotiate the preferred
> QoS level between end users during SDP negotiation in SIP, so before the
> actual resources are being setup). The QoS information negotiated at the
> session layer determines the QoS level both endusers have to use for 
> their local access connection. This first kind of 'session level QoS
> negotiation' happens end-to-end between the two end-users.
> 
> Secondly, there are drafts suggesting that we need
> improvements/alternatives for the QoS signalling protocols (e.g. RSVP)
> used to actually provision the QoS at the transport level between two
> endusers. This second kind of 'transport level QoS signalling' can
> consist of several phases: end-to-edge and edge-to-edge. 
> 
> It's important that everybody realises that, in order to give endusers
> true end-to-end Quality of Service, we need improvements for QoS both at
> session and transport level. Also its important to understand that they
> are not uncorrelated. Providers want to be able to control (e.g. via
> policy control mechanisms) that the QoS requested at the transport level
> is not exceeding the QoS negotiated/authorised previously at session
> level. So, what about developing in NSIS a modular framework
> incorporating both session and transport level QoS signalling with
> possible hooks between the two layers (e.g. for policy enforcement).
> 
> Lieve
> 
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis



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

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

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

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



From daemon@optimus.ietf.org  Fri Jan 18 02:19: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 CAA02712
	for <nsis-archive@odin.ietf.org>; Fri, 18 Jan 2002 02:19:08 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id CAA27721
	for nsis-archive@odin.ietf.org; Fri, 18 Jan 2002 02:19: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 CAA27616;
	Fri, 18 Jan 2002 02:13: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 CAA27583
	for <nsis@optimus.ietf.org>; Fri, 18 Jan 2002 02:13:14 -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 CAA02664
	for <nsis@ietf.org>; Fri, 18 Jan 2002 02:13:11 -0500 (EST)
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 g0I7DE922269
	for <nsis@ietf.org>; Fri, 18 Jan 2002 09:13:14 +0200 (EET)
Received: from esebh001.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T588547b78dac158f220c8@esvir02nok.ntc.nokia.com>;
 Fri, 18 Jan 2002 09:13:11 +0200
Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779);
	 Fri, 18 Jan 2002 09:13:11 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [NSIS] Charter of nsis
Date: Fri, 18 Jan 2002 09:13:11 +0200
Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF5D938C@esebe004.NOE.Nokia.com>
Thread-Topic: [NSIS] Charter of nsis
Thread-Index: AcGfdp7ENIa5BvOSSyCxjZJgnXIv0gAeMh5A
From: "Loughney John (NRC/Helsinki)" <john.loughney@nokia.com>
To: <jmaeng@ipdialog.com>, <nsis@ietf.org>
X-OriginalArrivalTime: 18 Jan 2002 07:13:12.0036 (UTC) FILETIME=[96E03240:01C19FEF]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id CAA27584
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,

> I am new to this group. I read most of discussions and am 
> confused with the charter of this group.  In my mind, RSVP is 
> more than signaling since it specifies how routers should behave 
> and so on.  Is nsis' goal is to define something like RSVP and 
> specify the behavior of networks to meet the
> signaling?  I would appreciate any clarification.

No, we are looking at using RSVP only for signaling so that
some features of RSVP may not be needed.  Also, we can
think of 'creative' ways in which to use RSVP for signaling
that may require additional specification.

best regards,
John

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



From daemon@optimus.ietf.org  Fri Jan 18 02:19: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 CAA02728
	for <nsis-archive@odin.ietf.org>; Fri, 18 Jan 2002 02:19:12 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id CAA27737
	for nsis-archive@odin.ietf.org; Fri, 18 Jan 2002 02:19: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 CAA27108;
	Fri, 18 Jan 2002 02:04:42 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA27076
	for <nsis@optimus.ietf.org>; Fri, 18 Jan 2002 02:04:41 -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 CAA00059
	for <nsis@ietf.org>; Fri, 18 Jan 2002 02:04:38 -0500 (EST)
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 g0I74g917956
	for <nsis@ietf.org>; Fri, 18 Jan 2002 09:04:42 +0200 (EET)
Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T58853fe448ac158f240c7@esvir04nok.ntc.nokia.com>;
 Fri, 18 Jan 2002 09:04:38 +0200
Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779);
	 Fri, 18 Jan 2002 09:04:38 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [NSIS] Two kinds of requirements
Date: Fri, 18 Jan 2002 09:04:38 +0200
Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF5D9389@esebe004.NOE.Nokia.com>
Thread-Topic: [NSIS] Two kinds of requirements
Thread-Index: AcGfgs99zcZgDNRWS9iY6qpHsfinkwAa07uQ
From: "Loughney John (NRC/Helsinki)" <john.loughney@nokia.com>
To: "'ext Gary Kenward'" <gkenward@nortelnetworks.com>
Cc: <nsis@ietf.org>
X-OriginalArrivalTime: 18 Jan 2002 07:04:38.0992 (UTC) FILETIME=[6513E500:01C19FEE]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id CAA27077
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 Gary,

>  Perhaps Gergios meant a "requirement" that was optional. Perhaps
denotatively 
> a contradiction, it is a common approach. In IETF parlance, this would
be a 
> "SHOULD" or "MAY". 

Going through some requirements work in other WGs, I've found that
any MAY requirements are pretty much useless & SHOULDs need to be
a strong SHOULD in order to have meaning.  Again, I am hoping
that the requirements draft focuses on minimum requirements,
but allows for future evolution / enhancements.  Piling
requirements on without real need will not be a good thing.

John

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



From daemon@optimus.ietf.org  Fri Jan 18 02:19:26 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02744
	for <nsis-archive@odin.ietf.org>; Fri, 18 Jan 2002 02:19:26 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id CAA27751
	for nsis-archive@odin.ietf.org; Fri, 18 Jan 2002 02:19: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 CAA27450;
	Fri, 18 Jan 2002 02:10: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 CAA27419
	for <nsis@optimus.ietf.org>; Fri, 18 Jan 2002 02:10:33 -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 CAA02639
	for <nsis@ietf.org>; Fri, 18 Jan 2002 02:10:30 -0500 (EST)
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 g0I7Adk05593
	for <nsis@ietf.org>; Fri, 18 Jan 2002 09:10:39 +0200 (EET)
Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T5885452fa1ac158f2111e@esvir01nok.ntc.nokia.com>;
 Fri, 18 Jan 2002 09:10:25 +0200
Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779);
	 Fri, 18 Jan 2002 09:10:24 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [NSIS] Two kinds of requirements
Date: Fri, 18 Jan 2002 09:10:23 +0200
Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF5D938B@esebe004.NOE.Nokia.com>
Thread-Topic: [NSIS] Two kinds of requirements
Thread-Index: AcGfpAe75cdhYiGsTGOs6RW3xVXx7QASxAtg
From: "Loughney John (NRC/Helsinki)" <john.loughney@nokia.com>
To: "'ext Michael Thomas'" <mat@cisco.com>
Cc: <nsis@ietf.org>
X-OriginalArrivalTime: 18 Jan 2002 07:10:24.0698 (UTC) FILETIME=[332271A0:01C19FEF]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id CAA27420
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,

>    I think that Scott might have addressed this,
>    but SHOULD's aren't necessarily an oxymoron in
>    a requirements draft. The way I interpret that
>    is that the design really, really ought to 
>    implement the SHOULD requirement or have a very 
>    good reason why it doesn't. MAY's are pretty
>    much a waste, IMO.

Agreed - I think MAY requirements are a waste &
SHOULD requirements are best if it is a strong
should.

John

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



From daemon@optimus.ietf.org  Fri Jan 18 02:19: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 CAA02775
	for <nsis-archive@odin.ietf.org>; Fri, 18 Jan 2002 02:19:35 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id CAA27766
	for nsis-archive@odin.ietf.org; Fri, 18 Jan 2002 02:19:34 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA27307;
	Fri, 18 Jan 2002 02:08: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 CAA27269
	for <nsis@optimus.ietf.org>; Fri, 18 Jan 2002 02:08:29 -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 CAA02570
	for <nsis@ietf.org>; Fri, 18 Jan 2002 02:08:26 -0500 (EST)
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 g0I78T919968
	for <nsis@ietf.org>; Fri, 18 Jan 2002 09:08:30 +0200 (EET)
Received: from esebh004.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T5885435ec2ac158f220c8@esvir02nok.ntc.nokia.com>;
 Fri, 18 Jan 2002 09:08:26 +0200
Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779);
	 Fri, 18 Jan 2002 09:08:26 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [NSIS] Two kinds of requirements
Date: Fri, 18 Jan 2002 09:08:26 +0200
Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF5D938A@esebe004.NOE.Nokia.com>
Thread-Topic: [NSIS] Two kinds of requirements
Thread-Index: AcGfh4sTavIRfHvmT42SfkJO7NE3zQAZu86Q
From: "Loughney John (NRC/Helsinki)" <john.loughney@nokia.com>
To: "'ext Scott  Bradner'" <sob@harvard.edu>
Cc: <nsis@ietf.org>
X-OriginalArrivalTime: 18 Jan 2002 07:08:27.0033 (UTC) FILETIME=[ED003090:01C19FEE]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id CAA27273
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 don't see how you can make all the requirements MUST. 
> 
> I agree, but it is good to think hard about a feature that is 
> not needed in most cases - maybe it can be left out (and maybe 
> it can not)

I agree.  I think we need to ensure that a requirement is
useful before adding it.  Additionally, not including
a requirement does not imply that a solution cannot 
fufill the (unstated) requirement. 

For example, if Gary said that one requirement is that
the protocol SHOULD have an ASCII text info field &
the working group felt that this requirement was not
needed, it does not mean that the NSIS protocol could
not have an ASCII text info field.

John

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



From daemon@optimus.ietf.org  Fri Jan 18 04:25: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 EAA04723
	for <nsis-archive@odin.ietf.org>; Fri, 18 Jan 2002 04:25:47 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id EAA01778
	for nsis-archive@odin.ietf.org; Fri, 18 Jan 2002 04:25: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 EAA01606;
	Fri, 18 Jan 2002 04:15:05 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA01571
	for <nsis@optimus.ietf.org>; Fri, 18 Jan 2002 04:15:03 -0500 (EST)
Received: from albatross-ext.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 EAA04563
	for <nsis@ietf.org>; Fri, 18 Jan 2002 04:14:59 -0500 (EST)
Received: from esealnt409.al.sw.ericsson.se (ESEALNT409.al.sw.ericsson.se [153.88.251.32])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g0I9F0J17106
	for <nsis@ietf.org>; Fri, 18 Jan 2002 10:15:00 +0100 (MET)
Received: FROM esealnt747.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Fri Jan 18 10:14:41 2002 +0100
Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <YHKTKSFB>; Fri, 18 Jan 2002 10:14:41 +0100
Message-ID: <E244E44D6AB85E40AEEF7EAABE3545FA823378@enleent104.nl.eu.ericsson.se>
From: "Georgios Karagiannis (ELN)" <Georgios.Karagiannis@eln.ericsson.se>
To: nsis@ietf.org
Cc: "'Scott  Bradner'" <sob@harvard.edu>, john.loughney@nokia.com,
        "David Partain (ERA)" <david.partain@era.ericsson.se>
Subject: RE: [NSIS] Two kinds of requirements
Date: Fri, 18 Jan 2002 10:14:56 +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,

Actually I agree with the comment of Scott regarding the MUST feature.

Furthermore, I would like to emphasize that what I meant 
by modularity is exactly what David Partain mentioned in 
his last NSIS e-mail:
"There are environments where a
certain kind of feature make sense and is considered mandatory.
There are others where that same feature would be considered
a waste of memory and cpu cycles.  I think we need to get
away from the discussion about words being used to describe
this issue.  I believe the issue certainly exists, and it
would be best if what we are working on allows us to have
"domain-specific features" and the "everyone-has it features".
If we don't do this, then vendors are certain to invent
non-standard ways to have their "domain-specific features".
That wouldn't be good."

Best Regards,
Georgios

-----Original Message-----
From: Scott Bradner [mailto:sob@harvard.edu]
Sent: donderdag 17 januari 2002 19:42
To: Cornelia.Kappler@icn.siemens.de;
Georgios.Karagiannis@eln.ericsson.se; gkenward@nortelnetworks.com;
john.loughney@nokia.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


> I don't see how you can make all the requirements MUST. 

I agree, but it is good to think hard about a feature that is not needed
in most cases - maybe it can be left out (and maybe it can not)


Scott

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



From daemon@optimus.ietf.org  Fri Jan 18 05:35: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 FAA05764
	for <nsis-archive@odin.ietf.org>; Fri, 18 Jan 2002 05:35:19 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id FAA04581
	for nsis-archive@odin.ietf.org; Fri, 18 Jan 2002 05:35: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 FAA03483;
	Fri, 18 Jan 2002 05:21: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 FAA03452
	for <nsis@optimus.ietf.org>; Fri, 18 Jan 2002 05:21:31 -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 FAA05485
	for <nsis@ietf.org>; Fri, 18 Jan 2002 05:21:26 -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.34)
	  id 16RW8h-0006GS-00; Fri, 18 Jan 2002 11:20:51 +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 g0IAKpa13882;
	Fri, 18 Jan 2002 11:20:51 +0100
Message-ID: <3C47F702.3B23EF48@ee.tu-berlin.de>
Date: Fri, 18 Jan 2002 11:20:50 +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: "Georgios Karagiannis (ELN)" <Georgios.Karagiannis@eln.ericsson.se>
CC: nsis@ietf.org, "'Scott Bradner'" <sob@harvard.edu>,
        john.loughney@nokia.com,
        "David Partain (ERA)" <david.partain@era.ericsson.se>
Subject: Re: [NSIS] Two kinds of requirements
References: <E244E44D6AB85E40AEEF7EAABE3545FA823378@enleent104.nl.eu.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

Hi,

I fully agree Georgios and David's comments on this issue. Since we have 
a consensus that the modularity is a necesity then a few SHOULDs(even MAYs)
will be brought up. In rfc1812 "Requirements for IP Version 4 Routers", 
for example,

(4.2.3.1 IP Broadcast Addresses)
   For historical reasons, there are a number of IP addresses (some
   standard and some not) which are used to indicate that an IP packet
   is an IP broadcast.  A router

   (1) MUST treat as IP broadcasts packets addressed to 255.255.255.255
        or { <Network-prefix>, -1 }.

   (2) SHOULD silently discard on receipt (i.e., do not even deliver to
        applications in the router) any packet addressed to 0.0.0.0 or {
        <Network-prefix>, 0 }.  If these packets are not silently
        discarded, they MUST be treated as IP broadcasts (see Section
        [5.3.5]).  There MAY be a configuration option to allow receipt
        of these packets.  This option SHOULD default to discarding
        them.
    ...

Also I would favor some "DISCUSSION" under some requirements like rfc1812
to record the reasoning of the final text.

Regards,
Xiaoming

"Georgios Karagiannis (ELN)" wrote:
> 
> Hi,
> 
> Actually I agree with the comment of Scott regarding the MUST feature.
> 
> Furthermore, I would like to emphasize that what I meant
> by modularity is exactly what David Partain mentioned in
> his last NSIS e-mail:
> "There are environments where a
> certain kind of feature make sense and is considered mandatory.
> There are others where that same feature would be considered
> a waste of memory and cpu cycles.  I think we need to get
> away from the discussion about words being used to describe
> this issue.  I believe the issue certainly exists, and it
> would be best if what we are working on allows us to have
> "domain-specific features" and the "everyone-has it features".
> If we don't do this, then vendors are certain to invent
> non-standard ways to have their "domain-specific features".
> That wouldn't be good."
> 
> Best Regards,
> Georgios
> 
> -----Original Message-----
> From: Scott Bradner [mailto:sob@harvard.edu]
> Sent: donderdag 17 januari 2002 19:42
> To: Cornelia.Kappler@icn.siemens.de;
> Georgios.Karagiannis@eln.ericsson.se; gkenward@nortelnetworks.com;
> john.loughney@nokia.com
> Cc: nsis@ietf.org
> Subject: RE: [NSIS] Two kinds of requirements
> 
> > I don't see how you can make all the requirements MUST.
> 
> I agree, but it is good to think hard about a feature that is not needed
> in most cases - maybe it can be left out (and maybe it can not)
> 
> Scott
> 
> _______________________________________________
> 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 Jan 18 06:27: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 GAA06582
	for <nsis-archive@odin.ietf.org>; Fri, 18 Jan 2002 06:27:56 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id GAA05927
	for nsis-archive@odin.ietf.org; Fri, 18 Jan 2002 06: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 GAA05700;
	Fri, 18 Jan 2002 06:13: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 GAA05667
	for <nsis@optimus.ietf.org>; Fri, 18 Jan 2002 06:13:01 -0500 (EST)
Received: from cbibipnt05.hc.bt.com (saturn.bt.com [193.113.57.20])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06387
	for <nsis@ietf.org>; Fri, 18 Jan 2002 06:12:56 -0500 (EST)
From: dick.rr.knight@bt.com
Received: by cbibipnt05.hc.bt.com with Internet Mail Service (5.5.2652.35)
	id <DA1VSYJG>; Fri, 18 Jan 2002 11:12:28 -0000
Message-ID: <451D45016C2CD2119DA50000F8FE7F07080E5A33@mlngcbnt01.hc.bt.com>
To: schneider@tri.sbc.com, Georgios.Karagiannis@eln.ericsson.se,
        dick.rr.knight@bt.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements (priority on the boundary be
	tween a customer and the network)
Date: Fri, 18 Jan 2002 11:12:15 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
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


I do not agree.

What is the point of completing the work enabling the customer to signal to
the network, if the network cannot signal between domains? The network can
never satisfy the request.

Dick

-----Original Message-----
From: Schneider, Marco [mailto:schneider@tri.sbc.com]
Sent: 18 January 2002 01:44
To: 'Georgios Karagiannis (ELN)'; 'dick.rr.knight@bt.com'
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


Hi Georgios,

While I agree NSIS could be used to support Interior to Interior (of one
carrier) or Edge to Core, I think that we need to prioritize on a signaling
protocol across the boundary between a customer and the network. Note that
the customer could be an individual, an ISP or another Carrier.

Marco Schneider

-----Original Message-----
From: Georgios Karagiannis (ELN)
[mailto:Georgios.Karagiannis@eln.ericsson.se]
Sent: Thursday, January 17, 2002 3:39 AM
To: 'dick.rr.knight@bt.com'
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


Hi Dick 

In principle I agree with your comment (see below).

[DK] >> To be more precise, I am suggesting a new protocol that is 
[DK] >> independent of the underlying transport technology and the QoS 
[DK] >> implemented and is also independent of the session control protocol.


However, a very important point here is that we need to 
specify a protocol that can be used independent of the underlying transport 
technology, but that can satisfy the QoS requirements imposed by these 
underlying transport technologies. Otherwise the protocol will not be
suitable
and useful.

A way of achieving this is by first creating a modular QoS signaling toolkit

that will contain mandatory and optional QoS requirements;
Second, specify how the protocol functionality should be separated in 
building blocks (protocol components) and define a minimum set 
of mandatory reservation options/features that should be 
processed by any network nodes, e.g., end-hosts,
proxies, edges and interior nodes.
An example of such a protocol decomposition is given below!
In this way each node will only process (check and use) the protocol 
components of interest.


|---------|
|---------|
|everyhost|<------------------------------------------------------->|everyho
st|
|---------|
|---------|
|         |                                                         |
|
|---------|   |---------|                             |---------|
|---------|
|everyedge|<->|everyedge|<--------------------------->|everyedge|<->|everyed
ge|
|---------|   |---------|                             |---------|
|---------|
|         |   |         |                             |         |   |
|
|---------|   |---------|   |--------|   |--------|   |---------|
|---------|
|everyhop |<->|everyhop |<->|everyhop|<->|everyhop|<->|everyhop
|<->|everyhop |
|---------|   |---------|   |--------|   |--------|   |---------|
|---------| 
    host          edge        interior    interior       edge          host


  NSIS protocol decomposition (building blocks): 
 *  "everyhost", "everyedge" and "everyhop" are protocol components;
 *  host: can be an end-host or a proxy and it can process and use the
"everyhost", 
    "everyedge", and "everyhop" protocol components;

 *  edge: can be a Diffserv edge, MPLS edge, etc., and it can process and
use 
    the "everyedge", and "everyhop" protocol components. The "everyhost" 
    protocol component is not processed (used or checked);

 *  interior: can be any router within a domain and it can process and use 
    only the "everyhop" protocol component.
    The "everyhost" and "everyedge" protocol components are not 
    processed (used or checked);


Best Regards,
Georgios

-----Original Message-----
From: dick.rr.knight@bt.com [mailto:dick.rr.knight@bt.com]
Sent: woensdag 16 januari 2002 13:00
To: brian.williams@ericsson.com.au; lieve.bos@alcatel.be
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


I was waiting for some reaction to Brian's comments, but as there aren't
any, here are my thoughts on the requirements:

I agree with the analysis that discussion has been based around
application-related signalling for QoS (at session level) and QoS signalling
protocols used to actually provision the QoS at the transport level.
Brian is right that there will never be an enhancement to a single session
protocol that will satisfy all applications.
However, for similar reasons, it is never going to be possible to prescribe
a single QoS mechanism to be used in all networks. Existing networks (or
domains) will not be changed overnight and new networks already face several
workable mechanisms to deploy QoS.

I think that what is needed is a new protocol that can signal the
requirements of any session and can be satisfied by any QoS mechanism,
existing or new.
To be more precise, I am suggesting a new protocol that is independent of
the underlying transport technology and the QoS implemented and is also
independent of the session control protocol. Such a new protocol would be
generic, optionally implemented by applications that would benefit from
end-to-end QoS, and would be complimentary to the QoS mechanisms deployed
(and of course other mechanisms, such as the routing).

I think that this implies a more abstract definition of the QoS mechanism
and may lend itself to the signalling of pre-defined QoS classes rather than
parameters.

Dick Knight

-----Original Message-----
From: Brian Williams [mailto:brian.williams@ericsson.com.au]
Sent: 22 December 2001 23:57
To: lieve.bos@alcatel.be
Cc: nsis@ietf.org
Subject: Re: [NSIS] Two kinds of requirements


Hi.
While the two types of signalling may be related, I think there is a
need to develop a QoS bearer mechanism which is independent of any
specific session signalling, and thus can be used for any application. I
believe many of the applications which have identified requirements to
the working group have their own specific session layer signalling (ie
it is not end-to-end SIP).  

Having the session and transport protocols developed separately of
course does not prohibit the two being used in conjunction for a
specific application.
/brian
 
On Fri, 2001-12-21 at 22:24, lieve.bos@alcatel.be wrote:
> Hello all,
> 
> >From the discussion in Salt Lake city and the drafts submitted, one can
> easily see that people are suggesting improvements to QoS signalling at
> two totally different levels (some at session level and some at
> transport level).
> 
> First of all, there are drafts suggesting some improvements in the
> session setup procedures (i.e. the ability to negotiate the preferred
> QoS level between end users during SDP negotiation in SIP, so before the
> actual resources are being setup). The QoS information negotiated at the
> session layer determines the QoS level both endusers have to use for 
> their local access connection. This first kind of 'session level QoS
> negotiation' happens end-to-end between the two end-users.
> 
> Secondly, there are drafts suggesting that we need
> improvements/alternatives for the QoS signalling protocols (e.g. RSVP)
> used to actually provision the QoS at the transport level between two
> endusers. This second kind of 'transport level QoS signalling' can
> consist of several phases: end-to-edge and edge-to-edge. 
> 
> It's important that everybody realises that, in order to give endusers
> true end-to-end Quality of Service, we need improvements for QoS both at
> session and transport level. Also its important to understand that they
> are not uncorrelated. Providers want to be able to control (e.g. via
> policy control mechanisms) that the QoS requested at the transport level
> is not exceeding the QoS negotiated/authorised previously at session
> level. So, what about developing in NSIS a modular framework
> incorporating both session and transport level QoS signalling with
> possible hooks between the two layers (e.g. for policy enforcement).
> 
> Lieve
> 
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis



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

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

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

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



From daemon@optimus.ietf.org  Fri Jan 18 06:39: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 GAA06794
	for <nsis-archive@odin.ietf.org>; Fri, 18 Jan 2002 06:39:19 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id GAA06545
	for nsis-archive@odin.ietf.org; Fri, 18 Jan 2002 06:39: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 GAA05907;
	Fri, 18 Jan 2002 06:27: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 GAA05880
	for <nsis@optimus.ietf.org>; Fri, 18 Jan 2002 06:27:11 -0500 (EST)
Received: from cbibipnt03.HC.BT.COM (saturn.bt.com [193.113.57.20])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06561
	for <nsis@ietf.org>; Fri, 18 Jan 2002 06:27:08 -0500 (EST)
From: dick.rr.knight@bt.com
Received: by cbibipnt03.hc.bt.com with Internet Mail Service (5.5.2652.35)
	id <DA1W1SR8>; Fri, 18 Jan 2002 11:26:29 -0000
Message-ID: <451D45016C2CD2119DA50000F8FE7F07080E5A34@mlngcbnt01.hc.bt.com>
To: john.loughney@nokia.com, brunner@ccrle.nec.de, ykahana@comgates.co.il,
        Ruediger.Geib@t-systems.com, dick.rr.knight@bt.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements
Date: Fri, 18 Jan 2002 11:26:15 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
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 is almost right. Service Providers sell QoS as part of a service
package and not as a separate service. Look at the existing phone/mobile
phone/internet service. Here is a silly example.

---
On my desk I have a landline telephone connected to the PSTN. I can make
calls all around the world to other landline phones and the quality is
almost always the same. The price depends on how far away the destination
is. If I make a call limited to about 20 miles it is rather cheap. I can
only use voice communication from my phone.

Also on my desk is a computer. I have internet acces (no surprise), but as I
have an office at home I use the phone system to connect to the internet.
Once connected I can communicate using a variety of applications to
communicate (and I am deliberately including information retrival as a means
of communication). The only price I pay is the same as the above telephone
call limited to 20 miles radius. I don't use it for voice. The quality of
service varies enormously. One thing that I have noticed is that I get very
good response times when (for example) downloading internet drafts in the
morning. I live in the UK and during my morning, the USA sleeps.

I also have a mobile phone. Yesterday I was down in Bristol, and drove home.
When I was about 20 miles from home, I rang my wife on the mobile - I had to
repeat what I was saying several times as the quality was rather bad, worse
than usual because of the wet weather. I pay rather more for the this call
than either of the other two means of communication.
----

We need QoS for good communications. We will put up with adequate
communications if it gives us other benefits (like mobility), but it doesn't
set the price. The other factors are the service differentiators.


Dick


-----Original Message-----
From: Loughney John (NRC/Helsinki) [mailto:john.loughney@nokia.com]
Sent: 17 January 2002 11:16
To: brunner; Yaron Kahana; Geib, Ruediger; dick.rr.knight
Cc: nsis
Subject: RE: [NSIS] Two kinds of requirements


Hi all,

> Good point, my question is whether the operator more likely opt for a 
> simple solution, with little flexibility, which implies no 
> competition in the type of services offered, since these are
standardized 
> (I assume there is still a lot of differentiation possible with weaker

> service parameters)

I've been wondering if this is a spurious argument.  I cannot think of 
how service providers could use QoS as a service.  What I have been 
hearing from service providers is that they would like to be able
to provide certain QoS levels for customers, but they would like
to be free to deploy / allocate resources as they see fit.  

With the PSTN, there SHOULD be only one quality, but in practice,
when calling overseas, I tend to get quite variable quality - of course
I still pay the same price ...

Additionally, I think we need to start somewhere, and I think that we 
need to be able to set some base line for signaling QoS. This does not
mean that we cannot allow more to be done / offered, but we want
to start with a minimum.  One option could be that we allow a simple
solution that supports optional extras.  These extras could be used
by service providers for enhanced services, but we don't specify 
them.

best regards,
John

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



From daemon@optimus.ietf.org  Fri Jan 18 06:41: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 GAA06864
	for <nsis-archive@odin.ietf.org>; Fri, 18 Jan 2002 06:41:28 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id GAA06592
	for nsis-archive@odin.ietf.org; Fri, 18 Jan 2002 06:41: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 GAA06039;
	Fri, 18 Jan 2002 06: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 GAA05954
	for <nsis@optimus.ietf.org>; Fri, 18 Jan 2002 06:29:59 -0500 (EST)
Received: from cbibipnt05.hc.bt.com (saturn.bt.com [193.113.57.20])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06619
	for <nsis@ietf.org>; Fri, 18 Jan 2002 06:29:56 -0500 (EST)
From: dick.rr.knight@bt.com
Received: by cbibipnt05.hc.bt.com with Internet Mail Service (5.5.2652.35)
	id <DA1VSZXH>; Fri, 18 Jan 2002 11:29:28 -0000
Message-ID: <451D45016C2CD2119DA50000F8FE7F07080E5A35@mlngcbnt01.hc.bt.com>
To: Georgios.Karagiannis@eln.ericsson.se, dick.rr.knight@bt.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements
Date: Fri, 18 Jan 2002 11:29:08 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
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

This is an excellent framework and just what I was thinking of.

The everyhost and everyedge are where the NSIS signalling is important
because it doesn't exist. We have solutions for everyhop. The everyhop needs
to be linked to the everyhost and everyedge - but this can be done in a node
and doesn't necessarily need a protocol.

Dick
-----Original Message-----
From: Georgios Karagiannis (ELN)
[mailto:Georgios.Karagiannis@eln.ericsson.se]
Sent: 17 January 2002 09:39
To: 'dick.rr.knight@bt.com'
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


Hi Dick 

In principle I agree with your comment (see below).

[DK] >> To be more precise, I am suggesting a new protocol that is 
[DK] >> independent of the underlying transport technology and the QoS 
[DK] >> implemented and is also independent of the session control protocol.


However, a very important point here is that we need to 
specify a protocol that can be used independent of the underlying transport 
technology, but that can satisfy the QoS requirements imposed by these 
underlying transport technologies. Otherwise the protocol will not be
suitable
and useful.

A way of achieving this is by first creating a modular QoS signaling toolkit

that will contain mandatory and optional QoS requirements;
Second, specify how the protocol functionality should be separated in 
building blocks (protocol components) and define a minimum set 
of mandatory reservation options/features that should be 
processed by any network nodes, e.g., end-hosts,
proxies, edges and interior nodes.
An example of such a protocol decomposition is given below!
In this way each node will only process (check and use) the protocol 
components of interest.


|---------|
|---------|
|everyhost|<------------------------------------------------------->|everyho
st|
|---------|
|---------|
|         |                                                         |
|
|---------|   |---------|                             |---------|
|---------|
|everyedge|<->|everyedge|<--------------------------->|everyedge|<->|everyed
ge|
|---------|   |---------|                             |---------|
|---------|
|         |   |         |                             |         |   |
|
|---------|   |---------|   |--------|   |--------|   |---------|
|---------|
|everyhop |<->|everyhop |<->|everyhop|<->|everyhop|<->|everyhop
|<->|everyhop |
|---------|   |---------|   |--------|   |--------|   |---------|
|---------| 
    host          edge        interior    interior       edge          host


  NSIS protocol decomposition (building blocks): 
 *  "everyhost", "everyedge" and "everyhop" are protocol components;
 *  host: can be an end-host or a proxy and it can process and use the
"everyhost", 
    "everyedge", and "everyhop" protocol components;

 *  edge: can be a Diffserv edge, MPLS edge, etc., and it can process and
use 
    the "everyedge", and "everyhop" protocol components. The "everyhost" 
    protocol component is not processed (used or checked);

 *  interior: can be any router within a domain and it can process and use 
    only the "everyhop" protocol component.
    The "everyhost" and "everyedge" protocol components are not 
    processed (used or checked);


Best Regards,
Georgios

-----Original Message-----
From: dick.rr.knight@bt.com [mailto:dick.rr.knight@bt.com]
Sent: woensdag 16 januari 2002 13:00
To: brian.williams@ericsson.com.au; lieve.bos@alcatel.be
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


I was waiting for some reaction to Brian's comments, but as there aren't
any, here are my thoughts on the requirements:

I agree with the analysis that discussion has been based around
application-related signalling for QoS (at session level) and QoS signalling
protocols used to actually provision the QoS at the transport level.
Brian is right that there will never be an enhancement to a single session
protocol that will satisfy all applications.
However, for similar reasons, it is never going to be possible to prescribe
a single QoS mechanism to be used in all networks. Existing networks (or
domains) will not be changed overnight and new networks already face several
workable mechanisms to deploy QoS.

I think that what is needed is a new protocol that can signal the
requirements of any session and can be satisfied by any QoS mechanism,
existing or new.
To be more precise, I am suggesting a new protocol that is independent of
the underlying transport technology and the QoS implemented and is also
independent of the session control protocol. Such a new protocol would be
generic, optionally implemented by applications that would benefit from
end-to-end QoS, and would be complimentary to the QoS mechanisms deployed
(and of course other mechanisms, such as the routing).

I think that this implies a more abstract definition of the QoS mechanism
and may lend itself to the signalling of pre-defined QoS classes rather than
parameters.

Dick Knight

-----Original Message-----
From: Brian Williams [mailto:brian.williams@ericsson.com.au]
Sent: 22 December 2001 23:57
To: lieve.bos@alcatel.be
Cc: nsis@ietf.org
Subject: Re: [NSIS] Two kinds of requirements


Hi.
While the two types of signalling may be related, I think there is a
need to develop a QoS bearer mechanism which is independent of any
specific session signalling, and thus can be used for any application. I
believe many of the applications which have identified requirements to
the working group have their own specific session layer signalling (ie
it is not end-to-end SIP).  

Having the session and transport protocols developed separately of
course does not prohibit the two being used in conjunction for a
specific application.
/brian
 
On Fri, 2001-12-21 at 22:24, lieve.bos@alcatel.be wrote:
> Hello all,
> 
> >From the discussion in Salt Lake city and the drafts submitted, one can
> easily see that people are suggesting improvements to QoS signalling at
> two totally different levels (some at session level and some at
> transport level).
> 
> First of all, there are drafts suggesting some improvements in the
> session setup procedures (i.e. the ability to negotiate the preferred
> QoS level between end users during SDP negotiation in SIP, so before the
> actual resources are being setup). The QoS information negotiated at the
> session layer determines the QoS level both endusers have to use for 
> their local access connection. This first kind of 'session level QoS
> negotiation' happens end-to-end between the two end-users.
> 
> Secondly, there are drafts suggesting that we need
> improvements/alternatives for the QoS signalling protocols (e.g. RSVP)
> used to actually provision the QoS at the transport level between two
> endusers. This second kind of 'transport level QoS signalling' can
> consist of several phases: end-to-edge and edge-to-edge. 
> 
> It's important that everybody realises that, in order to give endusers
> true end-to-end Quality of Service, we need improvements for QoS both at
> session and transport level. Also its important to understand that they
> are not uncorrelated. Providers want to be able to control (e.g. via
> policy control mechanisms) that the QoS requested at the transport level
> is not exceeding the QoS negotiated/authorised previously at session
> level. So, what about developing in NSIS a modular framework
> incorporating both session and transport level QoS signalling with
> possible hooks between the two layers (e.g. for policy enforcement).
> 
> Lieve
> 
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis



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

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

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



From daemon@optimus.ietf.org  Fri Jan 18 06:51: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 GAA07035
	for <nsis-archive@odin.ietf.org>; Fri, 18 Jan 2002 06:51:33 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id GAA07496
	for nsis-archive@odin.ietf.org; Fri, 18 Jan 2002 06:51: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 GAA06482;
	Fri, 18 Jan 2002 06:31: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 GAA06447
	for <nsis@optimus.ietf.org>; Fri, 18 Jan 2002 06:31:11 -0500 (EST)
Received: from cbibipnt08.hc.bt.com (saturn.bt.com [193.113.57.20])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06662
	for <nsis@ietf.org>; Fri, 18 Jan 2002 06:31:08 -0500 (EST)
From: dick.rr.knight@bt.com
Received: by cbibipnt08.hc.bt.com with Internet Mail Service (5.5.2654.89)
	id <DA1W4BGV>; Fri, 18 Jan 2002 11:30:40 -0000
Message-ID: <451D45016C2CD2119DA50000F8FE7F07080E5A36@mlngcbnt01.hc.bt.com>
To: john.loughney@nokia.com, rrroy@att.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements
Date: Fri, 18 Jan 2002 11:30:28 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2654.89)
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

If you concentrate on RFC2998, aren't you going down the technology-specific
solutions rather than a generic signalling mechanism?

-----Original Message-----
From: Loughney John (NRC/Helsinki) [mailto:john.loughney@nokia.com]
Sent: 17 January 2002 06:35
To: ext Roy, Radhika R, ALASO
Cc: nsis
Subject: RE: [NSIS] Two kinds of requirements


Hi Radhika,

> I think this was adequately addressed in RFC 2998, ``A Framework for 
> Integrated Services Operation over Diffserv Networks'' by Bernet, et 
> al.
> 
> [RRR] It is a good point. If we look into RFC 2998, we will 
> see that it will provide a good insight to develop our 
> end-to-end application layer QOS (generic) signaling 
> protocol. What we need to do to make it evolve in such a way 
> that the end-to-end QOS signaling will be able satisfy any 
> combinations of network layer QOS that has been implemented 
> using RSVP, DiffServ, MPLS, and/or other means while testing 
> RFC 2998's end-to-end scheme as one of the implementation schemes.

What would be good to do is document if something like RFC 2998 
can be expanded / extended / (reduced?) so that it supports
different combos of network layer QoS.

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  Fri Jan 18 06:56: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 GAA07266
	for <nsis-archive@odin.ietf.org>; Fri, 18 Jan 2002 06:56:49 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id GAA07792
	for nsis-archive@odin.ietf.org; Fri, 18 Jan 2002 06:56: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 GAA06668;
	Fri, 18 Jan 2002 06:46: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 GAA06637
	for <nsis@optimus.ietf.org>; Fri, 18 Jan 2002 06:46:28 -0500 (EST)
Received: from cbibipnt03.HC.BT.COM (saturn.bt.com [193.113.57.20])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06920
	for <nsis@ietf.org>; Fri, 18 Jan 2002 06:46:23 -0500 (EST)
From: dick.rr.knight@bt.com
Received: by cbibipnt03.hc.bt.com with Internet Mail Service (5.5.2652.35)
	id <DA1W1T9F>; Fri, 18 Jan 2002 11:45:21 -0000
Message-ID: <451D45016C2CD2119DA50000F8FE7F07080E5A37@mlngcbnt01.hc.bt.com>
To: wchen@tri.sbc.com, rrroy@att.com, berson@isi.edu
Cc: mat@cisco.com, dick.rr.knight@bt.com, brian.williams@ericsson.com.au,
        lieve.bos@alcatel.be, nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements
Date: Fri, 18 Jan 2002 11:45:07 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
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

I love the comparison with DTMF. I have inserted some comments (marked [dk])

-----Original Message-----
From: Chen, Weijing [mailto:wchen@tri.sbc.com]
Sent: 17 January 2002 04:20
To: 'Roy, Radhika R, ALASO'; Steven Berson
Cc: Michael Thomas; dick.rr.knight@bt.com;
brian.williams@ericsson.com.au; lieve.bos@alcatel.be; nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


Roy, Dick, etc

Let me re-phrase the requirements from a telco-head (or bell-head) point of
view to see if this is the right stuff in your mind:

What we need is a signaling protocol simply from user to network (edge) for
user to tell network where he wants to go and what QoS associated with it.
The network can accommodate the QoS through whichever means, e.g. set up an
ATM SVC, MPLS LSP path, route through IP network, route with IP reservation,
etc. And this signaling protocol message must be deliverable through a
multiprotocol network. It also must be able to carry different QoS
parameters with proper data flow classifier (IP flow, MPLS LSP path, SVC
VPI/VCI, etc.)
[dk] I am not sure what you mean by multiprotocol network. I am thinking in
terms of a network that consists of a number of concatenated domains.
Alternatively you can consider this to be a number of concatenated networks
(e.g. a connection across access network, corporate Lan network, Internet,
ISP Network, access network). If the latter is what you mean then I think
that multiple domains is a better term. Are we both talking about the same
thing but using different terminology? 

This signaling protocol is more like DTMF in POTS network. It is universal
and simple, yet effective. Once dialing digits getting into network,
different network will have different SS7 (North America SS7, Europe SS7,
Illinois SS7, China SS7) to handle the request. Same with this signaling
protocol, different network will have different NNI (CR-LDP, RSVP-TE, PNNI,
etc) for it. The signaling between the network could be solved through
signaling gateway.

Therefore this signaling protocol is end-to-end from service aspect, but is
only end-to-network and network-to-end from network aspect. The
network-to-network part is intentionally left out.
[dk] I am not sure that the network part should be left out. Intra-domain is
not needed as that is where the technology specific part resides (or the
"everyhop" part in Georgios Karagiannis framework). But you still need the
inter-domain generic solution (the everyedge solution) as this guarantees
interworking.


Up to recently, most of QoS effort is focusing on QoS parameters mapping
among different network layer. It is a necessary work, but not enough. It
has missed half of equation, which is how the user explicitly tells the
network what QoS he need. After that, let the network worry about how to
satisfy the QoS for which there are a lot of available solutions. 
[dk] I agree. QoS parameters merely add complication, especially as they
tend to be specific to a QoS solution rather than an indication of what the
user wants.

--
Weijing Chen
SBC Technology Resources
9505 Arboretum Blvd.
Austin, TX 78759
512 372 5710
wchen@tri.sbc.com



 -----Original Message-----
From: 	Roy, Radhika R, ALASO [mailto:rrroy@att.com] 
Sent:	Wednesday, January 16, 2002 2:18 PM
To:	Steven Berson
Cc:	Michael Thomas; dick.rr.knight@bt.com;
brian.williams@ericsson.com.au; lieve.bos@alcatel.be; nsis@ietf.org
Subject:	RE: [NSIS] Two kinds of requirements



-----Original Message-----
From: Steven Berson [mailto:berson@isi.edu]
Sent: Wednesday, January 16, 2002 2:08 PM
To: Roy, Radhika R, ALASO
Cc: Michael Thomas; dick.rr.knight@bt.com;
brian.williams@ericsson.com.au; lieve.bos@alcatel.be; nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


On Wed, 16 Jan 2002, Roy, Radhika R, ALASO wrote:

> Hi, Mike:
> 
> Let me try.
> 
> For (a), RSVP has definitely some characteristics that can be used
> at the application layer on end-to-end basis. In fact, we have to
> look into RSVP, like SDPng, to examine all its features how we can
> exploit it for using in the application layer. We can then
> determine what we do when think that we need to develop a new QOS
> protocol.
> 
> However, it requires that RSVP needs to be used on end-to-end
> basis. If RSVP is used on end-to-end basis and if we all agree we
> do not need additional features (e.g., SDPng and/or others
> provide), it is definitely a good candidate to examine whether it
> meets all requirements.
> 
> What do we do when RSVP is not end-to-end? For example domain 1 =
> RSVP, domain 2 = DiffServ, and domain 3= RSVP. I guess that here
> it breaks down. One solution may be translation between RSVP and
> DiffServ. Then we loose the end-to-end picture.

I think this was adequately addressed in RFC 2998, ``A Framework for 
Integrated Services Operation over Diffserv Networks'' by Bernet, et 
al.

[RRR] It is a good point. If we look into RFC 2998, we will see that it will
provide a good insight to develop our end-to-end application layer QOS
(generic) signaling protocol. What we need to do to make it evolve in such a
way that the end-to-end QOS signaling will be able satisfy any combinations
of network layer QOS that has been implemented using RSVP, DiffServ, MPLS,
and/or other means while testing RFC 2998's end-to-end scheme as one of the
implementation schemes.

Regards,
Steve


 
> Hope this may help to answer your questions.
> 
> Radhika
> 
> -----Original Message-----
> From: Michael Thomas [mailto:mat@cisco.com]
> Sent: Wednesday, January 16, 2002 11:31 AM
> To: dick.rr.knight@bt.com
> Cc: brian.williams@ericsson.com.au; lieve.bos@alcatel.be; nsis@ietf.org
> Subject: RE: [NSIS] Two kinds of requirements
> 
> 
> 
> So, I'm really dumb here. Can somebody enumerate
> the *specific* things that are broken with RSVP?
> Before we run off designing new protocols, it
> would be nice to know a) what things the current
> protocols have problems with and b) whether the
> current protocols are fatally flawed in the face
> of those problems.
> 
> I know some in (a). I don't think they meet (b).
> 
> 	Mike
> 
> 
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis
> 

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

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

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



From daemon@optimus.ietf.org  Fri Jan 18 07:13: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 HAA07810
	for <nsis-archive@odin.ietf.org>; Fri, 18 Jan 2002 07:13:10 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id HAA08822
	for nsis-archive@odin.ietf.org; Fri, 18 Jan 2002 07:13: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 HAA08688;
	Fri, 18 Jan 2002 07:08: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 HAA08660
	for <nsis@optimus.ietf.org>; Fri, 18 Jan 2002 07:08:24 -0500 (EST)
Received: from cbibipnt05.hc.bt.com (saturn.bt.com [193.113.57.20])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07685
	for <nsis@ietf.org>; Fri, 18 Jan 2002 07:08:21 -0500 (EST)
From: dick.rr.knight@bt.com
Received: by cbibipnt05.hc.bt.com with Internet Mail Service (5.5.2652.35)
	id <DA1VS763>; Fri, 18 Jan 2002 12:07:59 -0000
Message-ID: <451D45016C2CD2119DA50000F8FE7F07080E5A38@mlngcbnt01.hc.bt.com>
To: ykahana@comgates.co.il
Cc: brunner@ccrle.nec.de, Ruediger.Geib@t-systems.com, nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements (unsupported domains + chick
	en and eggs)
Date: Fri, 18 Jan 2002 12:07:39 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
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


I agree with Yaron's comments. USe QoS classes to keep it simple (the KISS
approach is rather well known to me). On the face of it QoS calsses look as
though they lose flexibility - but I don't think it is true.
 
Middleboxes support - needs thinking about. 
For example: if we carry addresses of requested connections, then NATS need
to understand the protocol, but if we don't carry the addresses, then the
NATS don't have to understand it.

Concerning the Chicken and Eggs: Yes I thought about a domain (or chunk of
network) that doesn't support the protocol: there are two cases:
The protocol reaches a node at the edge of a domain/network (an everyedge
node) and knows that the best routing from here is through a chunk of
besteffort (the routing tables tell it so). The node needs to decide whether
or not to progress or to refuse. This gives us a requirement on the
protocol: we need to include a class that says "I'd rather get my comms link
up with a reduced QoS than get a refusal". We also need a class that says
"don't down downgrade me" or "don't down downgrade me below [classX]". If it
does progress across this network domain, we can still signal into the next
NSIS-aware domain (as I am hoping the domain without support can still route
packets).
Note: Best effort means that there are no guarantees because NSIS is not
supported. It might be overprovisioned and providing a superior service, but
it doesn't have a CAC.

Second case: The protocol reaches a node at the edge of a domain/network (an
everyedge node) and knows that the best routing from here is through a chunk
of QoS enabled network that doesn't support the NSIS protocol. It knows it
is QoS enabled because it is aware of (for example) an MPLS route through
the network/domain. So this node might be able to perform a kind of proxying
job on behalf of the other network.

Dick

-----Original Message-----
From: Yaron Kahana [mailto:ykahana@comgates.co.il]
Sent: 16 January 2002 21:16
To: brunner@ccrle.nec.de; Geib, Ruediger; dick.rr.knight@bt.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


Hello Ruediger, Marcus, 

I agree with your comments. One of the crucial elements is the
pre-definition of the provider's policy - admission control decision tree,
QoS budgeting guides, CDR generation and considerations. Those could be done
in a practical manner only if there will be a rather small number of Service
classes (standardized services). I believe that this is by far the most
practical approach in a multi-providers environment. This QoS protocol
should be supported not only by the applications, the call control elements,
and transport routers but by the middleboxes, as well as the SLA/QoS
verification entities along the way and the billing elements.

We should try to keep it simple, even on the expense of full flexibility. 

By the way - did anyone considered the problem of a non-cooperative IP
domain "in the middle" ? for example, Suppose I'm making a call from Los
Angeles to Munich through 3 domains - LA-NY, NY-London, London-Munich. What
will happen if the best/cheapest carrier along the NY-London domain won't
support this new protocol? Will he be condemned/ignored? When will he
upgrade his infrastructure, before the chicken or after the egg?

Yaron Kahana 
COGITO Project Manager, 
COMGATES 

 -----Original Message----- 
From:   Marcus Brunner [mailto:brunner@ccrle.nec.de] 
Sent:   Wednesday, January 16, 2002 5:35 PM 
To:     Geib, Ruediger; dick.rr.knight@bt.com 
Cc:     nsis@ietf.org 
Subject:        RE: [NSIS] Two kinds of requirements 

Ruediger, 

The service needs to be defined anyway. Then there are IMO two 
possibilities 
- the provider defines the services and offers them. In this case the 
provider needs to describe the offers in a machine readable form (most 
likely with parameter names and values) 
- the consumer requests a particular service (this means the consumer has 
to describe the service he wants in a machine readable form) 

So it seams one has to move around service specifications which are 
understandable by the other party anyway, what is now your point? Is it 
that you want to limit/fix as many parameters as possible? Or are you more 
think about standardized services everybody understands? 

Marcus 

--On Wednesday, January 16, 2002 3:45 PM +0100 "Geib, Ruediger" 
<Ruediger.Geib@t-systems.com> wrote: 

> Hello Dick, 
> 
> your suggestion is quite reasonable. I also favour an architecture where 
> a QoS request by and large is predefined in terms of the resources 
> required from the available transport mechanism. Service specific 
> parameters to be signaled during reservation should be strictly limited. 
> The more mapping and evaluation of QoS parameters is required during 
> reservation, the more complex the service gets. Complex services are hard 
> to sell and hard to provide. 
> 
> Regards, 
> 
> Rüdiger 
> 
> Rüdiger Geib 
> Senior Project Manager 
> T-Systems Nova GmbH 
> 
>> I think that what is needed is a new protocol that can signal the 
>> requirements of any session and can be satisfied by any QoS 
>> mechanism, existing or new. 
>> To be more precise, I am suggesting a new protocol that is 
>> independent of the underlying transport technology and the QoS 
>> implemented and is also independent of the session control 
>> protocol. Such a new protocol would be generic, optionally 
>> implemented by applications that would benefit from 
>> end-to-end QoS, and would be complimentary to the QoS 
>> mechanisms deployed (and of course other mechanisms, 
>> such as the routing). 
>> 
>> I think that this implies a more abstract definition of the 
>> QoS mechanism and may lend itself to the signalling of 
>> pre-defined QoS classes rather than parameters. 
>> 
>> Dick Knight 
> 
> 
> _______________________________________________ 
> 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  Fri Jan 18 07:23: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 HAA08048
	for <nsis-archive@odin.ietf.org>; Fri, 18 Jan 2002 07:23:54 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id HAA09154
	for nsis-archive@odin.ietf.org; Fri, 18 Jan 2002 07:23: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 HAA09020;
	Fri, 18 Jan 2002 07:19: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 HAA08989
	for <nsis@optimus.ietf.org>; Fri, 18 Jan 2002 07:19:55 -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 HAA07971
	for <nsis@ietf.org>; Fri, 18 Jan 2002 07:19:45 -0500 (EST)
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 g0ICJW916958
	for <nsis@ietf.org>; Fri, 18 Jan 2002 14:19:32 +0200 (EET)
Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T588660095aac158f240c7@esvir04nok.ntc.nokia.com>;
 Fri, 18 Jan 2002 14:19:22 +0200
Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779);
	 Fri, 18 Jan 2002 14:19:20 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [NSIS] Two kinds of requirements
Date: Fri, 18 Jan 2002 14:19:20 +0200
Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF5D93A2@esebe004.NOE.Nokia.com>
Thread-Topic: [NSIS] Two kinds of requirements
Thread-Index: AcGgE5KKXUaRiiPDTmmSDr57Ae9qfgABqE3Q
From: "Loughney John (NRC/Helsinki)" <john.loughney@nokia.com>
To: <dick.rr.knight@bt.com>, <rrroy@att.com>
Cc: <nsis@ietf.org>
X-OriginalArrivalTime: 18 Jan 2002 12:19:20.0837 (UTC) FILETIME=[5B88CB50:01C1A01A]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id HAA08990
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 Dick,

> If you concentrate on RFC2998, aren't you going down the 
> technology-specific solutions rather than a generic signalling
mechanism?

No, I don't mean that we will focus on 2998 as a solution, but
as an example or a specific instantiation of what we want to
do.  I think we would like to take 2998 one step further
and remove the tech specific solution from it.

best regards,
John

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



From daemon@optimus.ietf.org  Fri Jan 18 07:32: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 HAA08361
	for <nsis-archive@odin.ietf.org>; Fri, 18 Jan 2002 07:32:16 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id HAA09855
	for nsis-archive@odin.ietf.org; Fri, 18 Jan 2002 07:32: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 HAA09288;
	Fri, 18 Jan 2002 07:28: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 HAA09253
	for <nsis@optimus.ietf.org>; Fri, 18 Jan 2002 07:28:07 -0500 (EST)
Received: from albatross-ext.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 HAA08223
	for <nsis@ietf.org>; Fri, 18 Jan 2002 07:28:03 -0500 (EST)
Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g0ICS3J01484
	for <nsis@ietf.org>; Fri, 18 Jan 2002 13:28:03 +0100 (MET)
Received: FROM esealnt746.al.sw.ericsson.se BY esealnt461 ; Fri Jan 18 13:27:46 2002 +0100
Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <YHLJL3YJ>; Fri, 18 Jan 2002 13:28:03 +0100
Message-ID: <E244E44D6AB85E40AEEF7EAABE3545FA82337A@enleent104.nl.eu.ericsson.se>
From: "Georgios Karagiannis (ELN)" <Georgios.Karagiannis@eln.ericsson.se>
To: "'dick.rr.knight@bt.com'" <dick.rr.knight@bt.com>
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements
Date: Fri, 18 Jan 2002 13:27:44 +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 Dick

DK >> This is an excellent framework and just what I was thinking of.

Thank you!


DK >> The everyhost and everyedge are where the NSIS signalling 
DK >> is important
DK >> because it doesn't exist. 

Agree!

DK >> We have solutions for everyhop. 

Agree, but there are scenarios, e.g., an IP based RAN, Mobile IP, etc.,
where existing solutions might not be satisfactory.
Therefore, I think that the [everyhop] feature should only be used
within domains that need this feature.
The "edges" (or the "host" in some cases) can specify the content 
of [everyhop]. Note that in some situations this content can be 
empty, meaning that it will not be used by the nodes that receive 
this information.
 

>> The everyhop needs
>> to be linked to the everyhost and everyedge - but this can be done in a node
>> and doesn't necessarily need a protocol.

In my opinion, the protocol must be able to carry 
the [everyhop] container.
However, please note that probably it is not necessary to 
standardise the contents of this [everyhop] container.

Best Regards,
Georgios

-----Original Message-----
From: dick.rr.knight@bt.com [mailto:dick.rr.knight@bt.com]
Sent: vrijdag 18 januari 2002 12:29
To: Georgios.Karagiannis@eln.ericsson.se; dick.rr.knight@bt.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


This is an excellent framework and just what I was thinking of.

The everyhost and everyedge are where the NSIS signalling is important
because it doesn't exist. We have solutions for everyhop. The everyhop needs
to be linked to the everyhost and everyedge - but this can be done in a node
and doesn't necessarily need a protocol.

Dick
-----Original Message-----
From: Georgios Karagiannis (ELN)
[mailto:Georgios.Karagiannis@eln.ericsson.se]
Sent: 17 January 2002 09:39
To: 'dick.rr.knight@bt.com'
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


Hi Dick 

In principle I agree with your comment (see below).

[DK] >> To be more precise, I am suggesting a new protocol that is 
[DK] >> independent of the underlying transport technology and the QoS 
[DK] >> implemented and is also independent of the session control protocol.


However, a very important point here is that we need to 
specify a protocol that can be used independent of the underlying transport 
technology, but that can satisfy the QoS requirements imposed by these 
underlying transport technologies. Otherwise the protocol will not be
suitable
and useful.

A way of achieving this is by first creating a modular QoS signaling toolkit

that will contain mandatory and optional QoS requirements;
Second, specify how the protocol functionality should be separated in 
building blocks (protocol components) and define a minimum set 
of mandatory reservation options/features that should be 
processed by any network nodes, e.g., end-hosts,
proxies, edges and interior nodes.
An example of such a protocol decomposition is given below!
In this way each node will only process (check and use) the protocol 
components of interest.


|---------|
|---------|
|everyhost|<------------------------------------------------------->|everyho
st|
|---------|
|---------|
|         |                                                         |
|
|---------|   |---------|                             |---------|
|---------|
|everyedge|<->|everyedge|<--------------------------->|everyedge|<->|everyed
ge|
|---------|   |---------|                             |---------|
|---------|
|         |   |         |                             |         |   |
|
|---------|   |---------|   |--------|   |--------|   |---------|
|---------|
|everyhop |<->|everyhop |<->|everyhop|<->|everyhop|<->|everyhop
|<->|everyhop |
|---------|   |---------|   |--------|   |--------|   |---------|
|---------| 
    host          edge        interior    interior       edge          host


  NSIS protocol decomposition (building blocks): 
 *  "everyhost", "everyedge" and "everyhop" are protocol components;
 *  host: can be an end-host or a proxy and it can process and use the
"everyhost", 
    "everyedge", and "everyhop" protocol components;

 *  edge: can be a Diffserv edge, MPLS edge, etc., and it can process and
use 
    the "everyedge", and "everyhop" protocol components. The "everyhost" 
    protocol component is not processed (used or checked);

 *  interior: can be any router within a domain and it can process and use 
    only the "everyhop" protocol component.
    The "everyhost" and "everyedge" protocol components are not 
    processed (used or checked);


Best Regards,
Georgios

-----Original Message-----
From: dick.rr.knight@bt.com [mailto:dick.rr.knight@bt.com]
Sent: woensdag 16 januari 2002 13:00
To: brian.williams@ericsson.com.au; lieve.bos@alcatel.be
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


I was waiting for some reaction to Brian's comments, but as there aren't
any, here are my thoughts on the requirements:

I agree with the analysis that discussion has been based around
application-related signalling for QoS (at session level) and QoS signalling
protocols used to actually provision the QoS at the transport level.
Brian is right that there will never be an enhancement to a single session
protocol that will satisfy all applications.
However, for similar reasons, it is never going to be possible to prescribe
a single QoS mechanism to be used in all networks. Existing networks (or
domains) will not be changed overnight and new networks already face several
workable mechanisms to deploy QoS.

I think that what is needed is a new protocol that can signal the
requirements of any session and can be satisfied by any QoS mechanism,
existing or new.
To be more precise, I am suggesting a new protocol that is independent of
the underlying transport technology and the QoS implemented and is also
independent of the session control protocol. Such a new protocol would be
generic, optionally implemented by applications that would benefit from
end-to-end QoS, and would be complimentary to the QoS mechanisms deployed
(and of course other mechanisms, such as the routing).

I think that this implies a more abstract definition of the QoS mechanism
and may lend itself to the signalling of pre-defined QoS classes rather than
parameters.

Dick Knight

-----Original Message-----
From: Brian Williams [mailto:brian.williams@ericsson.com.au]
Sent: 22 December 2001 23:57
To: lieve.bos@alcatel.be
Cc: nsis@ietf.org
Subject: Re: [NSIS] Two kinds of requirements


Hi.
While the two types of signalling may be related, I think there is a
need to develop a QoS bearer mechanism which is independent of any
specific session signalling, and thus can be used for any application. I
believe many of the applications which have identified requirements to
the working group have their own specific session layer signalling (ie
it is not end-to-end SIP).  

Having the session and transport protocols developed separately of
course does not prohibit the two being used in conjunction for a
specific application.
/brian
 
On Fri, 2001-12-21 at 22:24, lieve.bos@alcatel.be wrote:
> Hello all,
> 
> >From the discussion in Salt Lake city and the drafts submitted, one can
> easily see that people are suggesting improvements to QoS signalling at
> two totally different levels (some at session level and some at
> transport level).
> 
> First of all, there are drafts suggesting some improvements in the
> session setup procedures (i.e. the ability to negotiate the preferred
> QoS level between end users during SDP negotiation in SIP, so before the
> actual resources are being setup). The QoS information negotiated at the
> session layer determines the QoS level both endusers have to use for 
> their local access connection. This first kind of 'session level QoS
> negotiation' happens end-to-end between the two end-users.
> 
> Secondly, there are drafts suggesting that we need
> improvements/alternatives for the QoS signalling protocols (e.g. RSVP)
> used to actually provision the QoS at the transport level between two
> endusers. This second kind of 'transport level QoS signalling' can
> consist of several phases: end-to-edge and edge-to-edge. 
> 
> It's important that everybody realises that, in order to give endusers
> true end-to-end Quality of Service, we need improvements for QoS both at
> session and transport level. Also its important to understand that they
> are not uncorrelated. Providers want to be able to control (e.g. via
> policy control mechanisms) that the QoS requested at the transport level
> is not exceeding the QoS negotiated/authorised previously at session
> level. So, what about developing in NSIS a modular framework
> incorporating both session and transport level QoS signalling with
> possible hooks between the two layers (e.g. for policy enforcement).
> 
> Lieve
> 
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis



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

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

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



From daemon@optimus.ietf.org  Fri Jan 18 07:34: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 HAA08386
	for <nsis-archive@odin.ietf.org>; Fri, 18 Jan 2002 07:34:24 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id HAA09886
	for nsis-archive@odin.ietf.org; Fri, 18 Jan 2002 07:34: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 HAA09075;
	Fri, 18 Jan 2002 07:21: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 HAA09044
	for <nsis@optimus.ietf.org>; Fri, 18 Jan 2002 07:21:42 -0500 (EST)
Received: from cbibipnt08.hc.bt.com (saturn.bt.com [193.113.57.20])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08014
	for <nsis@ietf.org>; Fri, 18 Jan 2002 07:21:38 -0500 (EST)
From: dick.rr.knight@bt.com
Received: by cbibipnt08.hc.bt.com with Internet Mail Service (5.5.2654.89)
	id <DA1W41S1>; Fri, 18 Jan 2002 12:21:11 -0000
Message-ID: <451D45016C2CD2119DA50000F8FE7F07080E5A3A@mlngcbnt01.hc.bt.com>
To: Hemant.Chaskar@nokia.com, rrroy@att.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements
Date: Fri, 18 Jan 2002 12:21:05 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2654.89)
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

I don't think SDP (ng or otherwise) is a good starting point.

SDP is really a media description and is therefore application specific.

I have suggested (and seem to have seen quite a lot of support) a generic
mechanism that is agnostic on transport technology, QoS mechansim,
application and call/session protocol.

Dick

-----Original Message-----
From: Chaskar Hemant (NRC/Boston) [mailto:Hemant.Chaskar@nokia.com]
Sent: 16 January 2002 16:45
To: 'ext Roy, Radhika R, ALASO'
Cc: nsis
Subject: RE: [NSIS] Two kinds of requirements


Hi Radhika:

Just one comment below [HC].

--------------------------------------snip------------------------------
-----------------
[RRR] The thing that we need to do is to develop the end-to-end
application layer QOS signaling protocol. This will only deal with the
universal QOS characteristics of the application.

[HC] The easiest way to do this is to look at SDPng which is XML based,
and hence, will easily provide containers for the application QoS
parameters.

Hemant

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

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

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



From daemon@optimus.ietf.org  Fri Jan 18 07:53:58 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08902
	for <nsis-archive@odin.ietf.org>; Fri, 18 Jan 2002 07:53:57 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id HAA10311
	for nsis-archive@odin.ietf.org; Fri, 18 Jan 2002 07:54: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 HAA10021;
	Fri, 18 Jan 2002 07:40: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 HAA09994
	for <nsis@optimus.ietf.org>; Fri, 18 Jan 2002 07:40:04 -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 HAA08552
	for <nsis@ietf.org>; Fri, 18 Jan 2002 07:40:00 -0500 (EST)
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 g0ICdku21379
	for <nsis@ietf.org>; Fri, 18 Jan 2002 14:39:46 +0200 (EET)
Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T588672e949ac158f2515f@esvir05nok.ntc.nokia.com>;
 Fri, 18 Jan 2002 14:39:59 +0200
Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779);
	 Fri, 18 Jan 2002 14:39:58 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [NSIS] Two kinds of requirements
Date: Fri, 18 Jan 2002 14:39:58 +0200
Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF09BC5A@esebe004.NOE.Nokia.com>
Thread-Topic: [NSIS] Two kinds of requirements
Thread-Index: AcGfbyTrfkHfKwtfEdajbgCQJ60IGQAAbFDgACrbGmA=
From: "Loughney John (NRC/Helsinki)" <john.loughney@nokia.com>
To: "'ext Roy, Radhika R, ALASO'" <rrroy@att.com>,
        "Chen, Weijing" <wchen@tri.sbc.com>,
        "Georgios Karagiannis (ELN)" <Georgios.Karagiannis@eln.ericsson.se>
Cc: <nsis@ietf.org>
X-OriginalArrivalTime: 18 Jan 2002 12:39:58.0671 (UTC) FILETIME=[3D5745F0:01C1A01D]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id HAA09995
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 Radhika,

> [RRR] Host will only express its needs to satisfy the 
> applications. We can standardize in a simple way how a host 
> can express its needs.

I can agree with this, we should discuss how to do this
as part of the NSIS work.
 
> [RRR] Edge is where the actual implementation starts: Complex 
> signaling to reserve the resources. An edge might have to 
> work with an entity (e.g., proxy/bandwidth broker) that has 
> the global knowledge for the end-to-end topology and can 
> implement QOS dynamically. 

This may be out of scope of the current charter - it depends
on how detailed we get into this.  I think that we may wish
to address this within the framework, but how reservations
are made are out of scope.  After we get the main work done,
we could always recharter to work on tihs.
 
> [RRR] In other cases, SLAs will help to ensure what needs to 
> be done in each domain/segment where the end-to-end path/QOS 
> allocation is priori known. Each domain will implement its own part.

Agreed.  There are those who might want to use contractual methods
to reserve bandwidth as opposed to protocol methods ..

John

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



From daemon@optimus.ietf.org  Fri Jan 18 08:21: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 IAA09704
	for <nsis-archive@odin.ietf.org>; Fri, 18 Jan 2002 08:21:11 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id IAA11296
	for nsis-archive@odin.ietf.org; Fri, 18 Jan 2002 08:21: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 IAA11078;
	Fri, 18 Jan 2002 08:10: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 IAA11011
	for <nsis@optimus.ietf.org>; Fri, 18 Jan 2002 08:10:33 -0500 (EST)
Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09390
	for <nsis@ietf.org>; Fri, 18 Jan 2002 08:10:29 -0500 (EST)
Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85])
	by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g0IDC3Q24110
	for <nsis@ietf.org>; Fri, 18 Jan 2002 07:12:03 -0600 (CST)
Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T5884d76211ac12f2550ef@davir02nok.americas.nokia.com>;
 Fri, 18 Jan 2002 07:10:29 -0600
Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Fri, 18 Jan 2002 07:10:24 -0600
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [NSIS] Two kinds of requirements
Date: Fri, 18 Jan 2002 08:10:22 -0500
Message-ID: <E320A8529CF07E4C967ECC2F380B0CF942E689@bsebe001.NOE.Nokia.com>
Thread-Topic: [NSIS] Two kinds of requirements
Thread-Index: AcGfgtcDnx2N2wtzEdanAgCQJ3s5nwAAEimgABO/thA=
From: "Chaskar Hemant (NRC/Boston)" <Hemant.Chaskar@nokia.com>
To: "ext Roy, Radhika R, ALASO" <rrroy@att.com>
Cc: <nsis@ietf.org>
X-OriginalArrivalTime: 18 Jan 2002 13:10:24.0208 (UTC) FILETIME=[7D721D00:01C1A021]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id IAA11012
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:

I think the following comments is worth considering when trying to scope
the NSIS work. What we need is a "messaging model" for QoS from user to
network. We can come up with this messaging model to satisfy the
requirements being expressed by various people. One would then ask, why
RSVP is not a good messaging model. It could be if it satisfies all the
requirements expressed so far. If not, we need a messaging model with
more flexibility. 

 
-------------------------------excerpt--------------------------------- 
[Roy, Radhika R, ALARC]  I would say that it is the QOS needs of the
application (e.g., SIP-based VoIP) that the user likes to express (as
opposed to "service"). Similarly, instead of network services, we would
say network layer QOS services (e.g., RSVP, DiffServ, MPLS). We would
develop the end-to-end (application layer) QOS signaling protocol (say,
NSIS QOS). Now, there needs to have some kinds of standards how NSIS QOS
will be mapped over RSVP, DiffServ, MPLS, etc.
 
-----------------------------------------------------------------------
 
Hemant

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



From daemon@optimus.ietf.org  Fri Jan 18 08:35:26 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10023
	for <nsis-archive@odin.ietf.org>; Fri, 18 Jan 2002 08:35:26 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id IAA12193
	for nsis-archive@odin.ietf.org; Fri, 18 Jan 2002 08:35: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 IAA11423;
	Fri, 18 Jan 2002 08:25: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 IAA11388
	for <nsis@optimus.ietf.org>; Fri, 18 Jan 2002 08:24:58 -0500 (EST)
Received: from cbibipnt05.hc.bt.com (saturn.bt.com [193.113.57.20])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09788
	for <nsis@ietf.org>; Fri, 18 Jan 2002 08:24:56 -0500 (EST)
From: dick.rr.knight@bt.com
Received: by cbibipnt05.hc.bt.com with Internet Mail Service (5.5.2652.35)
	id <DA1VTBSB>; Fri, 18 Jan 2002 13:24:30 -0000
Message-ID: <451D45016C2CD2119DA50000F8FE7F07080E5A3F@mlngcbnt01.hc.bt.com>
To: Hemant.Chaskar@nokia.com, rrroy@att.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements
Date: Fri, 18 Jan 2002 13:24:07 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
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


This is a good approach. We need to concentrate on the requirements and the
framework.

There have been too many interventions saying "why is RSVP not good enough".

The answer, of couse, is that until we have the requirements, how can we
tell whether the "new" signalling protocol that will satisfy the
requirements is RSVP or RSVP enhancements or something else entirely?

Dick

-----Original Message-----
From: Chaskar Hemant (NRC/Boston) [mailto:Hemant.Chaskar@nokia.com]
Sent: 18 January 2002 13:10
To: ext Roy, Radhika R, ALASO
Cc: nsis
Subject: RE: [NSIS] Two kinds of requirements


Hi:

I think the following comments is worth considering when trying to scope
the NSIS work. What we need is a "messaging model" for QoS from user to
network. We can come up with this messaging model to satisfy the
requirements being expressed by various people. One would then ask, why
RSVP is not a good messaging model. It could be if it satisfies all the
requirements expressed so far. If not, we need a messaging model with
more flexibility. 

 
-------------------------------excerpt--------------------------------- 
[Roy, Radhika R, ALARC]  I would say that it is the QOS needs of the
application (e.g., SIP-based VoIP) that the user likes to express (as
opposed to "service"). Similarly, instead of network services, we would
say network layer QOS services (e.g., RSVP, DiffServ, MPLS). We would
develop the end-to-end (application layer) QOS signaling protocol (say,
NSIS QOS). Now, there needs to have some kinds of standards how NSIS QOS
will be mapped over RSVP, DiffServ, MPLS, etc.
 
-----------------------------------------------------------------------
 
Hemant

_______________________________________________
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 Jan 18 08:50: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 IAA10730
	for <nsis-archive@odin.ietf.org>; Fri, 18 Jan 2002 08:50:32 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id IAA12663
	for nsis-archive@odin.ietf.org; Fri, 18 Jan 2002 08:50: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 IAA12264;
	Fri, 18 Jan 2002 08:36:37 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA12235
	for <nsis@optimus.ietf.org>; Fri, 18 Jan 2002 08:36:35 -0500 (EST)
Received: from Morgana.Elet.PoliMi.IT (bianchi@morgana.elet.polimi.it [131.175.120.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10046
	for <nsis@ietf.org>; Fri, 18 Jan 2002 08:36:32 -0500 (EST)
Received: from host localhost and sender bianchi@localhost;
	by mail relay Morgana.Elet.PoliMi.IT (Sendmail Ver. 8.x.x / 2 Nov. 1998);
	with protocol ESMTP and identifier OAA00917;
	on date and time Fri, 18 Jan 2002 14:36:29 +0100 (MET).
Date: Fri, 18 Jan 2002 14:36:28 +0100 (MET)
From: Giuseppe Bianchi <bianchi@morgana.elet.polimi.it>
To: dick.rr.knight@bt.com, <blefari@diei.unipg.it>
cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements (unsupported domains + chick
 en and eggs)
In-Reply-To: <451D45016C2CD2119DA50000F8FE7F07080E5A38@mlngcbnt01.hc.bt.com>
Message-ID: <Pine.OSF.4.44.0201181358200.19151-100000@morgana.elet.polimi.it>
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


Extending Dick's comment:

On Fri, 18 Jan 2002 dick.rr.knight@bt.com wrote:
> [...]
> The protocol reaches a node at the edge of a domain/network (aneveryedge
> node) and knows that the best routing from here is through a chunk of
> besteffort (the routing tables tell it so). The node needs to decide whether
> or not to progress or to refuse. This gives us a requirement on the
> protocol: we need to include a class that says "I'd rather get my comms link
> up with a reduced QoS than get a refusal". We also need a class that says
> "don't down downgrade me" or "don't down downgrade me below [classX]". If it
> does progress across this network domain, we can still signal into the next
> NSIS-aware domain (as I am hoping the domain without support can still route
> packets).
> Note: Best effort means that there are no guarantees because NSIS is not
> supported. It might be overprovisioned and providing a superior service, but
> it doesn't have a CAC.

Why leaving this decision up to the node? An alternative (which may
actually coexist with Dick's idea) is to use a form of marking, and take
back to the user the information that one domain along the path is Best
Effort... Depending on its requirements, the user will know whether to
progress or to refuse.

On a more general point of view, and in the spirit of the Internet, I'd
recommend to keep as much as possible the intelligence at the edge of the
network. In this sense, NSIS should be designed as a protocol that allows
end nodes to discover the state of the nodes/domains along the path and to
react accordingly.

To make a simple example: I need to set up a call with some requirements.
I (or my access router) send an NSIS signalling packet including some form
of specifications & requirements. This packet is locally handled by each
network node (domain) as follow: if the node (domain) can guarantee the
reqs, it just forwards the NSIS packet along; If it cannot guarantee the
reqs, but it can accept the request with some downgraded form of of
support, it marks the packet; if, finally, it cannot accept the request,
it just says no (by, e.g. suitably marking the NSIS packet, or, as we
suggested in an earlier internet draft to make this idea compatible with
DiffServ domains, blocking it - timeouts at the end points will do the
rest). When the NSIS signalling packet gets back to the sender, it
contains all the relevant information to proceed.

Giuseppe Bianchi
bianchi@elet.polimi.it
http://cerbero.elet.polimi.it/people/bianchi



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



From daemon@optimus.ietf.org  Fri Jan 18 08:58:27 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11003
	for <nsis-archive@odin.ietf.org>; Fri, 18 Jan 2002 08:58:18 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id IAA12892
	for nsis-archive@odin.ietf.org; Fri, 18 Jan 2002 08:58: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 IAA12450;
	Fri, 18 Jan 2002 08:42: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 IAA12415
	for <nsis@optimus.ietf.org>; Fri, 18 Jan 2002 08:42:22 -0500 (EST)
Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10362
	for <nsis@ietf.org>; Fri, 18 Jan 2002 08:42:20 -0500 (EST)
Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85])
	by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g0IDhtQ26094
	for <nsis@ietf.org>; Fri, 18 Jan 2002 07:43:55 -0600 (CST)
Received: from daebh002.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T5884f487adac12f2550ef@davir02nok.americas.nokia.com> for <nsis@ietf.org>;
 Fri, 18 Jan 2002 07:42:20 -0600
Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Fri, 18 Jan 2002 07:42:19 -0600
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [NSIS] Two kinds of requirements
Date: Fri, 18 Jan 2002 08:42:18 -0500
Message-ID: <E320A8529CF07E4C967ECC2F380B0CF9064BD1@bsebe001.NOE.Nokia.com>
Thread-Topic: [NSIS] Two kinds of requirements
Thread-Index: AcGgE6EmyXRLe1FoTfShPbRMl/6BfAAEgirA
From: "Chaskar Hemant (NRC/Boston)" <Hemant.Chaskar@nokia.com>
To: <nsis@ietf.org>
X-OriginalArrivalTime: 18 Jan 2002 13:42:19.0629 (UTC) FILETIME=[F32029D0:01C1A025]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id IAA12416
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,

I think Georgios's diagram is an excellent description of the scope of
messaging model we should be discussing in NSIS.

Hemant

-----Original Message-----
From: ext dick.rr.knight@bt.com [mailto:dick.rr.knight@bt.com]
Sent: Friday, January 18, 2002 6:29 AM
To: Georgios.Karagiannis@eln.ericsson.se; dick.rr.knight@bt.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


This is an excellent framework and just what I was thinking of.

The everyhost and everyedge are where the NSIS signalling is important
because it doesn't exist. We have solutions for everyhop. The everyhop
needs
to be linked to the everyhost and everyedge - but this can be done in a
node
and doesn't necessarily need a protocol.

Dick
-----Original Message-----
From: Georgios Karagiannis (ELN)
[mailto:Georgios.Karagiannis@eln.ericsson.se]
Sent: 17 January 2002 09:39
To: 'dick.rr.knight@bt.com'
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


Hi Dick 

In principle I agree with your comment (see below).

[DK] >> To be more precise, I am suggesting a new protocol that is 
[DK] >> independent of the underlying transport technology and the QoS 
[DK] >> implemented and is also independent of the session control
protocol.


However, a very important point here is that we need to 
specify a protocol that can be used independent of the underlying
transport 
technology, but that can satisfy the QoS requirements imposed by these 
underlying transport technologies. Otherwise the protocol will not be
suitable
and useful.

A way of achieving this is by first creating a modular QoS signaling
toolkit

that will contain mandatory and optional QoS requirements;
Second, specify how the protocol functionality should be separated in 
building blocks (protocol components) and define a minimum set 
of mandatory reservation options/features that should be 
processed by any network nodes, e.g., end-hosts,
proxies, edges and interior nodes.
An example of such a protocol decomposition is given below!
In this way each node will only process (check and use) the protocol 
components of interest.


|---------|
|---------|
|everyhost|<------------------------------------------------------->|eve
ryho
st|
|---------|
|---------|
|         |                                                         |
|
|---------|   |---------|                             |---------|
|---------|
|everyedge|<->|everyedge|<--------------------------->|everyedge|<->|eve
ryed
ge|
|---------|   |---------|                             |---------|
|---------|
|         |   |         |                             |         |   |
|
|---------|   |---------|   |--------|   |--------|   |---------|
|---------|
|everyhop |<->|everyhop |<->|everyhop|<->|everyhop|<->|everyhop
|<->|everyhop |
|---------|   |---------|   |--------|   |--------|   |---------|
|---------| 
    host          edge        interior    interior       edge
host


  NSIS protocol decomposition (building blocks): 
 *  "everyhost", "everyedge" and "everyhop" are protocol components;
 *  host: can be an end-host or a proxy and it can process and use the
"everyhost", 
    "everyedge", and "everyhop" protocol components;

 *  edge: can be a Diffserv edge, MPLS edge, etc., and it can process
and
use 
    the "everyedge", and "everyhop" protocol components. The "everyhost"

    protocol component is not processed (used or checked);

 *  interior: can be any router within a domain and it can process and
use 
    only the "everyhop" protocol component.
    The "everyhost" and "everyedge" protocol components are not 
    processed (used or checked);


Best Regards,
Georgios

-----Original Message-----
From: dick.rr.knight@bt.com [mailto:dick.rr.knight@bt.com]
Sent: woensdag 16 januari 2002 13:00
To: brian.williams@ericsson.com.au; lieve.bos@alcatel.be
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


I was waiting for some reaction to Brian's comments, but as there aren't
any, here are my thoughts on the requirements:

I agree with the analysis that discussion has been based around
application-related signalling for QoS (at session level) and QoS
signalling
protocols used to actually provision the QoS at the transport level.
Brian is right that there will never be an enhancement to a single
session
protocol that will satisfy all applications.
However, for similar reasons, it is never going to be possible to
prescribe
a single QoS mechanism to be used in all networks. Existing networks (or
domains) will not be changed overnight and new networks already face
several
workable mechanisms to deploy QoS.

I think that what is needed is a new protocol that can signal the
requirements of any session and can be satisfied by any QoS mechanism,
existing or new.
To be more precise, I am suggesting a new protocol that is independent
of
the underlying transport technology and the QoS implemented and is also
independent of the session control protocol. Such a new protocol would
be
generic, optionally implemented by applications that would benefit from
end-to-end QoS, and would be complimentary to the QoS mechanisms
deployed
(and of course other mechanisms, such as the routing).

I think that this implies a more abstract definition of the QoS
mechanism
and may lend itself to the signalling of pre-defined QoS classes rather
than
parameters.

Dick Knight

-----Original Message-----
From: Brian Williams [mailto:brian.williams@ericsson.com.au]
Sent: 22 December 2001 23:57
To: lieve.bos@alcatel.be
Cc: nsis@ietf.org
Subject: Re: [NSIS] Two kinds of requirements


Hi.
While the two types of signalling may be related, I think there is a
need to develop a QoS bearer mechanism which is independent of any
specific session signalling, and thus can be used for any application. I
believe many of the applications which have identified requirements to
the working group have their own specific session layer signalling (ie
it is not end-to-end SIP).  

Having the session and transport protocols developed separately of
course does not prohibit the two being used in conjunction for a
specific application.
/brian
 
On Fri, 2001-12-21 at 22:24, lieve.bos@alcatel.be wrote:
> Hello all,
> 
> >From the discussion in Salt Lake city and the drafts submitted, one
can
> easily see that people are suggesting improvements to QoS signalling
at
> two totally different levels (some at session level and some at
> transport level).
> 
> First of all, there are drafts suggesting some improvements in the
> session setup procedures (i.e. the ability to negotiate the preferred
> QoS level between end users during SDP negotiation in SIP, so before
the
> actual resources are being setup). The QoS information negotiated at
the
> session layer determines the QoS level both endusers have to use for 
> their local access connection. This first kind of 'session level QoS
> negotiation' happens end-to-end between the two end-users.
> 
> Secondly, there are drafts suggesting that we need
> improvements/alternatives for the QoS signalling protocols (e.g. RSVP)
> used to actually provision the QoS at the transport level between two
> endusers. This second kind of 'transport level QoS signalling' can
> consist of several phases: end-to-edge and edge-to-edge. 
> 
> It's important that everybody realises that, in order to give endusers
> true end-to-end Quality of Service, we need improvements for QoS both
at
> session and transport level. Also its important to understand that
they
> are not uncorrelated. Providers want to be able to control (e.g. via
> policy control mechanisms) that the QoS requested at the transport
level
> is not exceeding the QoS negotiated/authorised previously at session
> level. So, what about developing in NSIS a modular framework
> incorporating both session and transport level QoS signalling with
> possible hooks between the two layers (e.g. for policy enforcement).
> 
> Lieve
> 
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis



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

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

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

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



From daemon@optimus.ietf.org  Fri Jan 18 09:21: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 JAA11951
	for <nsis-archive@odin.ietf.org>; Fri, 18 Jan 2002 09:21:19 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id JAA13977
	for nsis-archive@odin.ietf.org; Fri, 18 Jan 2002 09:21: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 JAA13459;
	Fri, 18 Jan 2002 09:04: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 JAA13426
	for <nsis@optimus.ietf.org>; Fri, 18 Jan 2002 09:04:48 -0500 (EST)
Received: from cbibipnt05.hc.bt.com (saturn.bt.com [193.113.57.20])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11256
	for <nsis@ietf.org>; Fri, 18 Jan 2002 09:04:45 -0500 (EST)
From: dick.rr.knight@bt.com
Received: by cbibipnt05.hc.bt.com with Internet Mail Service (5.5.2652.35)
	id <DA1VT1FM>; Fri, 18 Jan 2002 14:03:37 -0000
Message-ID: <451D45016C2CD2119DA50000F8FE7F07080E5A41@mlngcbnt01.hc.bt.com>
To: bianchi@morgana.elet.polimi.it, dick.rr.knight@bt.com,
        blefari@diei.unipg.it
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements  (unsupported domains + chic
	k en and eggs)
Date: Fri, 18 Jan 2002 14:03:23 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
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

I think that you agree with me but didn't quite understand what I was
suggesting.

I agree that it is the user that makes the decision about a chunk of network
that cannot support the requested QoS.

But why mark the packet and continue on all the way to the destination and
back? It is simpler for a user to indicate in the original request:
1. Don't downgrade
2. Downgrade to no lower than [x]
3. I'd prefer QoS [n] but I'll accept Best Efoort if I have to.

Then you can set up the connection in one go.

It is also slightly better, if you accept (and we haven't discussed this
yet) that the choice of route can be influenced by the requested QoS. If the
user has marked 1 (above) you might route differently to 2 or 3, as an
alternative to just failing the connection.

Dick


-----Original Message-----
From: Giuseppe Bianchi [mailto:bianchi@morgana.elet.polimi.it]
Sent: 18 January 2002 13:36
To: dick.rr.knight@bt.com; blefari
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements (unsupported domains +
chick en and eggs)



Extending Dick's comment:

On Fri, 18 Jan 2002 dick.rr.knight@bt.com wrote:
> [...]
> The protocol reaches a node at the edge of a domain/network (aneveryedge
> node) and knows that the best routing from here is through a chunk of
> besteffort (the routing tables tell it so). The node needs to decide
whether
> or not to progress or to refuse. This gives us a requirement on the
> protocol: we need to include a class that says "I'd rather get my comms
link
> up with a reduced QoS than get a refusal". We also need a class that says
> "don't down downgrade me" or "don't down downgrade me below [classX]". If
it
> does progress across this network domain, we can still signal into the
next
> NSIS-aware domain (as I am hoping the domain without support can still
route
> packets).
> Note: Best effort means that there are no guarantees because NSIS is not
> supported. It might be overprovisioned and providing a superior service,
but
> it doesn't have a CAC.

Why leaving this decision up to the node? An alternative (which may
actually coexist with Dick's idea) is to use a form of marking, and take
back to the user the information that one domain along the path is Best
Effort... Depending on its requirements, the user will know whether to
progress or to refuse.

On a more general point of view, and in the spirit of the Internet, I'd
recommend to keep as much as possible the intelligence at the edge of the
network. In this sense, NSIS should be designed as a protocol that allows
end nodes to discover the state of the nodes/domains along the path and to
react accordingly.

To make a simple example: I need to set up a call with some requirements.
I (or my access router) send an NSIS signalling packet including some form
of specifications & requirements. This packet is locally handled by each
network node (domain) as follow: if the node (domain) can guarantee the
reqs, it just forwards the NSIS packet along; If it cannot guarantee the
reqs, but it can accept the request with some downgraded form of of
support, it marks the packet; if, finally, it cannot accept the request,
it just says no (by, e.g. suitably marking the NSIS packet, or, as we
suggested in an earlier internet draft to make this idea compatible with
DiffServ domains, blocking it - timeouts at the end points will do the
rest). When the NSIS signalling packet gets back to the sender, it
contains all the relevant information to proceed.

Giuseppe Bianchi
bianchi@elet.polimi.it
http://cerbero.elet.polimi.it/people/bianchi


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



From daemon@optimus.ietf.org  Fri Jan 18 09:39: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 JAA12720
	for <nsis-archive@odin.ietf.org>; Fri, 18 Jan 2002 09:39:25 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id JAA14968
	for nsis-archive@odin.ietf.org; Fri, 18 Jan 2002 09:39: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 JAA13956;
	Fri, 18 Jan 2002 09:20: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 JAA13928
	for <nsis@optimus.ietf.org>; Fri, 18 Jan 2002 09:20:42 -0500 (EST)
Received: from almso1.proxy.att.com (almso1.att.com [192.128.167.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11855
	for <nsis@ietf.org>; Fri, 18 Jan 2002 09:20:27 -0500 (EST)
Received: from attrh3i.attrh.att.com ([135.71.62.12])
	by almso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id g0IEJsW01116
	for <nsis@ietf.org>; Fri, 18 Jan 2002 09:19:54 -0500 (EST)
Received: from occlust04evs1.ugd.att.com (135.71.164.12) by attrh3i.attrh.att.com (5.5.029)
        id 3C06950500AFE582; Fri, 18 Jan 2002 09:18:43 -0500
content-class: urn:content-classes:message
Subject: RE: [NSIS] Two kinds of requirements
Date: Fri, 18 Jan 2002 09:19:24 -0500
Message-ID: <62DA45D4963FA747BA1B253E266760F9011E73F0@OCCLUST04EVS1.ugd.att.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Thread-Topic: [NSIS] Two kinds of requirements
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
Thread-Index: AcGgHUTWIxaNvQwLEdazmACQJ2FUNwADaZyw
From: "Roy, Radhika R, ALASO" <rrroy@att.com>
To: "Loughney John (NRC/Helsinki)" <john.loughney@nokia.com>,
        "Chen, Weijing" <wchen@tri.sbc.com>,
        "Georgios Karagiannis (ELN)" <Georgios.Karagiannis@eln.ericsson.se>
Cc: <nsis@ietf.org>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id JAA13929
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, John:

I agree with you. 

Thanks,
Radhika

-----Original Message-----
From: Loughney John (NRC/Helsinki) [mailto:john.loughney@nokia.com]
Sent: Friday, January 18, 2002 7:40 AM
To: Roy, Radhika R, ALASO; Chen, Weijing; Georgios Karagiannis (ELN)
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


Hi Radhika,

> [RRR] Host will only express its needs to satisfy the 
> applications. We can standardize in a simple way how a host 
> can express its needs.

I can agree with this, we should discuss how to do this
as part of the NSIS work.
 
> [RRR] Edge is where the actual implementation starts: Complex 
> signaling to reserve the resources. An edge might have to 
> work with an entity (e.g., proxy/bandwidth broker) that has 
> the global knowledge for the end-to-end topology and can 
> implement QOS dynamically. 

This may be out of scope of the current charter - it depends
on how detailed we get into this.  I think that we may wish
to address this within the framework, but how reservations
are made are out of scope.  After we get the main work done,
we could always recharter to work on tihs.
 
> [RRR] In other cases, SLAs will help to ensure what needs to 
> be done in each domain/segment where the end-to-end path/QOS 
> allocation is priori known. Each domain will implement its own part.

Agreed.  There are those who might want to use contractual methods
to reserve bandwidth as opposed to protocol methods ..

John

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



From daemon@optimus.ietf.org  Fri Jan 18 10:06: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 KAA13795
	for <nsis-archive@odin.ietf.org>; Fri, 18 Jan 2002 10:06:28 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id KAA16352
	for nsis-archive@odin.ietf.org; Fri, 18 Jan 2002 10:06:30 -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 JAA15283;
	Fri, 18 Jan 2002 09:53: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 JAA15251
	for <nsis@optimus.ietf.org>; Fri, 18 Jan 2002 09:53:38 -0500 (EST)
Received: from almso1.proxy.att.com (almso1.att.com [192.128.167.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13369
	for <nsis@ietf.org>; Fri, 18 Jan 2002 09:53:30 -0500 (EST)
Received: from attrh3i.attrh.att.com ([135.71.62.12])
	by almso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id g0IEqcW22137
	for <nsis@ietf.org>; Fri, 18 Jan 2002 09:52:38 -0500 (EST)
Received: from occlust04evs1.ugd.att.com (135.71.164.12) by attrh3i.attrh.att.com (5.5.029)
        id 3C06950500B010A5; Fri, 18 Jan 2002 09:51:09 -0500
content-class: urn:content-classes:message
Subject: RE: [NSIS] Two kinds of requirements
Date: Fri, 18 Jan 2002 09:51:51 -0500
Message-ID: <62DA45D4963FA747BA1B253E266760F9011E745E@OCCLUST04EVS1.ugd.att.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Thread-Topic: [NSIS] Two kinds of requirements
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
Thread-Index: AcGgGp6c1HU4lQwLEda1uADgKSaxKgAEpMXg
From: "Roy, Radhika R, ALASO" <rrroy@att.com>
To: <dick.rr.knight@bt.com>, <Hemant.Chaskar@nokia.com>
Cc: <nsis@ietf.org>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id JAA15252
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, Dick:

You probably did not get my points. SDPng has used some QOS parameters for audio, video, and data. These parameters need to be examined for our NSIS works.

There is another aspect of SDPng: QOS parameters are sent on end-to-end basis using a signaling protocol (e.g., SIP). This notion of end-to-end communications is also needed in NSIS.

All I have pointed out is to examine all aspects SDPng to find out how NSIS QOS can be developed examining the SDPng. In the same token, we can also examine RFC 2998 and others.

Examining SDPng, RFC 2998, RSVP, and other proposals will be advancing our understanding so that we can develop the NSIS QOS satisfying all the needs.

You are right when you say we should NOT concentrate only on those things because we need to develop our own NSIS QOS protocol.

Best regards,

Radhika R. Roy
rrroy@att.com

-----Original Message-----
From: dick.rr.knight@bt.com [mailto:dick.rr.knight@bt.com]
Sent: Friday, January 18, 2002 7:21 AM
To: Hemant.Chaskar@nokia.com; Roy, Radhika R, ALASO
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


I don't think SDP (ng or otherwise) is a good starting point.

SDP is really a media description and is therefore application specific.

I have suggested (and seem to have seen quite a lot of support) a generic
mechanism that is agnostic on transport technology, QoS mechansim,
application and call/session protocol.

Dick

-----Original Message-----
From: Chaskar Hemant (NRC/Boston) [mailto:Hemant.Chaskar@nokia.com]
Sent: 16 January 2002 16:45
To: 'ext Roy, Radhika R, ALASO'
Cc: nsis
Subject: RE: [NSIS] Two kinds of requirements


Hi Radhika:

Just one comment below [HC].

--------------------------------------snip------------------------------
-----------------
[RRR] The thing that we need to do is to develop the end-to-end
application layer QOS signaling protocol. This will only deal with the
universal QOS characteristics of the application.

[HC] The easiest way to do this is to look at SDPng which is XML based,
and hence, will easily provide containers for the application QoS
parameters.

Hemant

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

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

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



From daemon@optimus.ietf.org  Fri Jan 18 10:07: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 KAA13834
	for <nsis-archive@odin.ietf.org>; Fri, 18 Jan 2002 10:07:37 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id KAA16432
	for nsis-archive@odin.ietf.org; Fri, 18 Jan 2002 10:07: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 JAA15327;
	Fri, 18 Jan 2002 09:54: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 JAA15295
	for <nsis@optimus.ietf.org>; Fri, 18 Jan 2002 09:54:31 -0500 (EST)
Received: from almso1.proxy.att.com (almso1.att.com [192.128.167.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13405
	for <nsis@ietf.org>; Fri, 18 Jan 2002 09:54:27 -0500 (EST)
Received: from attrh1i.attrh.att.com ([135.71.62.10])
	by almso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id g0IErNW22602
	for <nsis@ietf.org>; Fri, 18 Jan 2002 09:53:32 -0500 (EST)
Received: from occlust04evs1.ugd.att.com (135.71.164.12) by attrh1i.attrh.att.com (5.5.029)
        id 3C0BA3A500228C3D; Fri, 18 Jan 2002 09:52:16 -0500
content-class: urn:content-classes:message
Subject: RE: [NSIS] Two kinds of requirements
Date: Fri, 18 Jan 2002 09:52:16 -0500
Message-ID: <62DA45D4963FA747BA1B253E266760F9011E7460@OCCLUST04EVS1.ugd.att.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Thread-Topic: [NSIS] Two kinds of requirements
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
Thread-Index: AcGgIYgDI+eIyQwTEdazmACQJ2FUNwACciEw
From: "Roy, Radhika R, ALASO" <rrroy@att.com>
To: "Chaskar Hemant (NRC/Boston)" <Hemant.Chaskar@nokia.com>
Cc: <nsis@ietf.org>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id JAA15296
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

Inputs inline [RRR].

-----Original Message-----
From: Chaskar Hemant (NRC/Boston) [mailto:Hemant.Chaskar@nokia.com]
Sent: Friday, January 18, 2002 8:10 AM
To: Roy, Radhika R, ALASO
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


Hi:

I think the following comments is worth considering when trying to scope
the NSIS work. What we need is a "messaging model" for QoS from user to
network. We can come up with this messaging model to satisfy the
requirements being expressed by various people. One would then ask, why
RSVP is not a good messaging model. It could be if it satisfies all the
requirements expressed so far. If not, we need a messaging model with
more flexibility. 

[RRR] Many of us have expressed the views that we need to define the requirements of NSIS WG, we will then see whether the protocol like RSVP needs to examine to satisfy the requirements.

([RRR] My views have been expressed earlier related to RSVP considering the NSIS. I like to provide more inputs along the line. RSVP has tightly coupled the two things: 1. End-to-end QOS needs in the application layer and 2. Resource reservation in the network layer. NSIS is chartered with item 1 to work in the application layer that will remain unchanged on end-to-end. One can easily see that the network layer may employ different QOS schemes to reserve/allocate the resources: RSVP, DiffServ, and/or MPLS. Here RSVP breaks down. RSVP may work, if it is employed on end-to-end basis. Let us not start the debate right now. We can address this later once we define NSIS requirements.)
 
-------------------------------excerpt--------------------------------- 
[Roy, Radhika R, ALARC]  I would say that it is the QOS needs of the
application (e.g., SIP-based VoIP) that the user likes to express (as
opposed to "service"). Similarly, instead of network services, we would
say network layer QOS services (e.g., RSVP, DiffServ, MPLS). We would
develop the end-to-end (application layer) QOS signaling protocol (say,
NSIS QOS). Now, there needs to have some kinds of standards how NSIS QOS
will be mapped over RSVP, DiffServ, MPLS, etc.
 
-----------------------------------------------------------------------
 
Hemant

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



From daemon@optimus.ietf.org  Fri Jan 18 10:33: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 KAA14731
	for <nsis-archive@odin.ietf.org>; Fri, 18 Jan 2002 10:33:54 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id KAA18186
	for nsis-archive@odin.ietf.org; Fri, 18 Jan 2002 10:33: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 KAA17133;
	Fri, 18 Jan 2002 10:21: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 KAA17100
	for <nsis@optimus.ietf.org>; Fri, 18 Jan 2002 10:21:32 -0500 (EST)
Received: from ckmso1.proxy.att.com (ckmso1.att.com [12.20.58.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14380
	for <nsis@ietf.org>; Fri, 18 Jan 2002 10:21:26 -0500 (EST)
Received: from attrh3i.attrh.att.com ([135.71.62.12])
	by ckmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id g0IFKVZ19405
	for <nsis@ietf.org>; Fri, 18 Jan 2002 10:20:48 -0500 (EST)
Received: from occlust04evs1.ugd.att.com (135.71.164.12) by attrh3i.attrh.att.com (5.5.029)
        id 3C06950500B033EC; Fri, 18 Jan 2002 10:17:22 -0500
content-class: urn:content-classes:message
Subject: RE: [NSIS] Two kinds of requirements
Date: Fri, 18 Jan 2002 10:18:04 -0500
Message-ID: <62DA45D4963FA747BA1B253E266760F9011E74AD@OCCLUST04EVS1.ugd.att.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Thread-Topic: [NSIS] Two kinds of requirements
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
Thread-Index: AcGfwikK+hB+gwuyEdaVVQCQJ2GH0wAcINbw
From: "Roy, Radhika R, ALASO" <rrroy@att.com>
To: "Schneider, Marco" <schneider@tri.sbc.com>,
        "Gary Kenward" <gkenward@nortelnetworks.com>,
        "Loughney John (NRC/Helsinki)" <john.loughney@nokia.com>,
        <brunner@ccrle.nec.de>, "Yaron Kahana" <ykahana@comgates.co.il>,
        "Geib, Ruediger" <Ruediger.Geib@t-systems.com>,
        <dick.rr.knight@bt.com>
Cc: <nsis@ietf.org>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id KAA17101
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

Defined below [RRR]

-----Original Message-----
From: Schneider, Marco [mailto:schneider@tri.sbc.com]
Sent: Thursday, January 17, 2002 8:47 PM
To: Roy, Radhika R, ALASO; Gary Kenward; Loughney John (NRC/Helsinki);
brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
dick.rr.knight@bt.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


Hi Roy,

Can you please define what you mean by "End-to-End Application Layer QOS
Signaling". Thanks.

[RRR] Suppose an user is initiation a SIP call to another user with audio, video, and data. The use needs to express the needs of QOS for audio, video, and data to another user. 

[RRR] The signaling mechanism that allows to express the QOS parameters of audio, video, and data is termed as the "End-to-End Application Layer QOS Signaling."

Marco Schneider


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



From daemon@optimus.ietf.org  Fri Jan 18 10: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 KAA15864
	for <nsis-archive@odin.ietf.org>; Fri, 18 Jan 2002 10:58:50 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id KAA19318
	for nsis-archive@odin.ietf.org; Fri, 18 Jan 2002 10: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 KAA18794;
	Fri, 18 Jan 2002 10:46: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 KAA18725
	for <nsis@optimus.ietf.org>; Fri, 18 Jan 2002 10:46:09 -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 KAA15274
	for <nsis@ietf.org>; Fri, 18 Jan 2002 10:46:03 -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 g0IFm7T18269;
	Fri, 18 Jan 2002 09:48:07 -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 g0IFjPe00798;
	Fri, 18 Jan 2002 09:45:25 -0600 (CST)
Received: by TRIMAIL2.ad.tri.sbc.com with Internet Mail Service (5.5.2653.19)
	id <ZND32LDW>; Fri, 18 Jan 2002 09:45:51 -0600
Message-ID: <905A1C4ABF353F4C8CC16FA9F53DD0D6322422@TRIMAIL2.ad.tri.sbc.com>
From: "Chen, Weijing" <wchen@tri.sbc.com>
To: "'dick.rr.knight@bt.com'" <dick.rr.knight@bt.com>, rrroy@att.com,
        berson@isi.edu
Cc: mat@cisco.com, brian.williams@ericsson.com.au, lieve.bos@alcatel.be,
        nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements
Date: Fri, 18 Jan 2002 09:45:40 -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


--
Weijing Chen
SBC Technology Resources
9505 Arboretum Blvd.
Austin, TX 78759
512 372 5710
wchen@tri.sbc.com


 -----Original Message-----
From: 	dick.rr.knight@bt.com [mailto:dick.rr.knight@bt.com] 
Sent:	Friday, January 18, 2002 5:45 AM
To:	Chen, Weijing; rrroy@att.com; berson@isi.edu
Cc:	mat@cisco.com; dick.rr.knight@bt.com;
brian.williams@ericsson.com.au; lieve.bos@alcatel.be; nsis@ietf.org
Subject:	RE: [NSIS] Two kinds of requirements

I love the comparison with DTMF. I have inserted some comments (marked [dk])

-----Original Message-----
From: Chen, Weijing [mailto:wchen@tri.sbc.com]
Sent: 17 January 2002 04:20
To: 'Roy, Radhika R, ALASO'; Steven Berson
Cc: Michael Thomas; dick.rr.knight@bt.com;
brian.williams@ericsson.com.au; lieve.bos@alcatel.be; nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


Roy, Dick, etc

Let me re-phrase the requirements from a telco-head (or bell-head) point of
view to see if this is the right stuff in your mind:

What we need is a signaling protocol simply from user to network (edge) for
user to tell network where he wants to go and what QoS associated with it.
The network can accommodate the QoS through whichever means, e.g. set up an
ATM SVC, MPLS LSP path, route through IP network, route with IP reservation,
etc. And this signaling protocol message must be deliverable through a
multiprotocol network. It also must be able to carry different QoS
parameters with proper data flow classifier (IP flow, MPLS LSP path, SVC
VPI/VCI, etc.)
[dk] I am not sure what you mean by multiprotocol network. I am thinking in
terms of a network that consists of a number of concatenated domains.
Alternatively you can consider this to be a number of concatenated networks
(e.g. a connection across access network, corporate Lan network, Internet,
ISP Network, access network). If the latter is what you mean then I think
that multiple domains is a better term. Are we both talking about the same
thing but using different terminology? 

[wj] I think we are talking about the same thing. Yes, it is a connection
from user to network across LAN network, access network, etc. So it is
multi-domain.

This signaling protocol is more like DTMF in POTS network. It is universal
and simple, yet effective. Once dialing digits getting into network,
different network will have different SS7 (North America SS7, Europe SS7,
Illinois SS7, China SS7) to handle the request. Same with this signaling
protocol, different network will have different NNI (CR-LDP, RSVP-TE, PNNI,
etc) for it. The signaling between the network could be solved through
signaling gateway.

Therefore this signaling protocol is end-to-end from service aspect, but is
only end-to-network and network-to-end from network aspect. The
network-to-network part is intentionally left out.
[dk] I am not sure that the network part should be left out. Intra-domain is
not needed as that is where the technology specific part resides (or the
"everyhop" part in Georgios Karagiannis framework). But you still need the
inter-domain generic solution (the everyedge solution) as this guarantees
interworking.

[wj] The interworking among different networks is needed but it can be
treated as customer-to-network with customer-to-network solution.


Up to recently, most of QoS effort is focusing on QoS parameters mapping
among different network layer. It is a necessary work, but not enough. It
has missed half of equation, which is how the user explicitly tells the
network what QoS he need. After that, let the network worry about how to
satisfy the QoS for which there are a lot of available solutions. 
[dk] I agree. QoS parameters merely add complication, especially as they
tend to be specific to a QoS solution rather than an indication of what the
user wants.

--
Weijing Chen
SBC Technology Resources
9505 Arboretum Blvd.
Austin, TX 78759
512 372 5710
wchen@tri.sbc.com



 -----Original Message-----
From: 	Roy, Radhika R, ALASO [mailto:rrroy@att.com] 
Sent:	Wednesday, January 16, 2002 2:18 PM
To:	Steven Berson
Cc:	Michael Thomas; dick.rr.knight@bt.com;
brian.williams@ericsson.com.au; lieve.bos@alcatel.be; nsis@ietf.org
Subject:	RE: [NSIS] Two kinds of requirements



-----Original Message-----
From: Steven Berson [mailto:berson@isi.edu]
Sent: Wednesday, January 16, 2002 2:08 PM
To: Roy, Radhika R, ALASO
Cc: Michael Thomas; dick.rr.knight@bt.com;
brian.williams@ericsson.com.au; lieve.bos@alcatel.be; nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


On Wed, 16 Jan 2002, Roy, Radhika R, ALASO wrote:

> Hi, Mike:
> 
> Let me try.
> 
> For (a), RSVP has definitely some characteristics that can be used
> at the application layer on end-to-end basis. In fact, we have to
> look into RSVP, like SDPng, to examine all its features how we can
> exploit it for using in the application layer. We can then
> determine what we do when think that we need to develop a new QOS
> protocol.
> 
> However, it requires that RSVP needs to be used on end-to-end
> basis. If RSVP is used on end-to-end basis and if we all agree we
> do not need additional features (e.g., SDPng and/or others
> provide), it is definitely a good candidate to examine whether it
> meets all requirements.
> 
> What do we do when RSVP is not end-to-end? For example domain 1 =
> RSVP, domain 2 = DiffServ, and domain 3= RSVP. I guess that here
> it breaks down. One solution may be translation between RSVP and
> DiffServ. Then we loose the end-to-end picture.

I think this was adequately addressed in RFC 2998, ``A Framework for 
Integrated Services Operation over Diffserv Networks'' by Bernet, et 
al.

[RRR] It is a good point. If we look into RFC 2998, we will see that it will
provide a good insight to develop our end-to-end application layer QOS
(generic) signaling protocol. What we need to do to make it evolve in such a
way that the end-to-end QOS signaling will be able satisfy any combinations
of network layer QOS that has been implemented using RSVP, DiffServ, MPLS,
and/or other means while testing RFC 2998's end-to-end scheme as one of the
implementation schemes.

Regards,
Steve


 
> Hope this may help to answer your questions.
> 
> Radhika
> 
> -----Original Message-----
> From: Michael Thomas [mailto:mat@cisco.com]
> Sent: Wednesday, January 16, 2002 11:31 AM
> To: dick.rr.knight@bt.com
> Cc: brian.williams@ericsson.com.au; lieve.bos@alcatel.be; nsis@ietf.org
> Subject: RE: [NSIS] Two kinds of requirements
> 
> 
> 
> So, I'm really dumb here. Can somebody enumerate
> the *specific* things that are broken with RSVP?
> Before we run off designing new protocols, it
> would be nice to know a) what things the current
> protocols have problems with and b) whether the
> current protocols are fatally flawed in the face
> of those problems.
> 
> I know some in (a). I don't think they meet (b).
> 
> 	Mike
> 
> 
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis
> 

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

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

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

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



From daemon@optimus.ietf.org  Fri Jan 18 11: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 LAA16328
	for <nsis-archive@odin.ietf.org>; Fri, 18 Jan 2002 11:04:31 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id LAA20116
	for nsis-archive@odin.ietf.org; Fri, 18 Jan 2002 11:04:34 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA18999;
	Fri, 18 Jan 2002 10:50: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 KAA18964
	for <nsis@optimus.ietf.org>; Fri, 18 Jan 2002 10:50:25 -0500 (EST)
Received: from Morgana.Elet.PoliMi.IT (bianchi@morgana.elet.polimi.it [131.175.120.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15500
	for <nsis@ietf.org>; Fri, 18 Jan 2002 10:50:20 -0500 (EST)
Received: from host localhost and sender bianchi@localhost;
	by mail relay Morgana.Elet.PoliMi.IT (Sendmail Ver. 8.x.x / 2 Nov. 1998);
	with protocol ESMTP and identifier QAA12158;
	on date and time Fri, 18 Jan 2002 16:50:12 +0100 (MET).
Date: Fri, 18 Jan 2002 16:50:11 +0100 (MET)
From: Giuseppe Bianchi <bianchi@morgana.elet.polimi.it>
To: dick.rr.knight@bt.com
cc: blefari@diei.unipg.it, <nsis@ietf.org>
Subject: RE: [NSIS] Two kinds of requirements  (unsupported domains + chic
 k en and eggs)
In-Reply-To: <451D45016C2CD2119DA50000F8FE7F07080E5A41@mlngcbnt01.hc.bt.com>
Message-ID: <Pine.OSF.4.44.0201181617550.11506-100000@morgana.elet.polimi.it>
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


Right, I had misread your email, and I definitely agree with your solution
when specifically dealing with connection setup.

Indeed, if we consider using NSIS refreshes as a mean to allow
application's adaptation (e.g. rate reduction), some forms of feedbacks
from the network via packet marking appear necessary (actually, is this
issue within the scopes of NSIS?)

Giuseppe.


On Fri, 18 Jan 2002 dick.rr.knight@bt.com wrote:

> I think that you agree with me but didn't quite understand what I was
> suggesting.
>
> I agree that it is the user that makes the decision about a chunk of network
> that cannot support the requested QoS.
>
> But why mark the packet and continue on all the way to the destination and
> back? It is simpler for a user to indicate in the original request:
> 1. Don't downgrade
> 2. Downgrade to no lower than [x]
> 3. I'd prefer QoS [n] but I'll accept Best Efoort if I have to.
>
> Then you can set up the connection in one go.
>
> It is also slightly better, if you accept (and we haven't discussed this
> yet) that the choice of route can be influenced by the requested QoS. If the
> user has marked 1 (above) you might route differently to 2 or 3, as an
> alternative to just failing the connection.
>
> Dick
>
>
> -----Original Message-----
> From: Giuseppe Bianchi [mailto:bianchi@morgana.elet.polimi.it]
> Sent: 18 January 2002 13:36
> To: dick.rr.knight@bt.com; blefari
> Cc: nsis@ietf.org
> Subject: RE: [NSIS] Two kinds of requirements (unsupported domains +
> chick en and eggs)
>
>
>
> Extending Dick's comment:
>
> On Fri, 18 Jan 2002 dick.rr.knight@bt.com wrote:
> > [...]
> > The protocol reaches a node at the edge of a domain/network (aneveryedge
> > node) and knows that the best routing from here is through a chunk of
> > besteffort (the routing tables tell it so). The node needs to decide
> whether
> > or not to progress or to refuse. This gives us a requirement on the
> > protocol: we need to include a class that says "I'd rather get my comms
> link
> > up with a reduced QoS than get a refusal". We also need a class that says
> > "don't down downgrade me" or "don't down downgrade me below [classX]". If
> it
> > does progress across this network domain, we can still signal into the
> next
> > NSIS-aware domain (as I am hoping the domain without support can still
> route
> > packets).
> > Note: Best effort means that there are no guarantees because NSIS is not
> > supported. It might be overprovisioned and providing a superior service,
> but
> > it doesn't have a CAC.
>
> Why leaving this decision up to the node? An alternative (which may
> actually coexist with Dick's idea) is to use a form of marking, and take
> back to the user the information that one domain along the path is Best
> Effort... Depending on its requirements, the user will know whether to
> progress or to refuse.
>
> On a more general point of view, and in the spirit of the Internet, I'd
> recommend to keep as much as possible the intelligence at the edge of the
> network. In this sense, NSIS should be designed as a protocol that allows
> end nodes to discover the state of the nodes/domains along the path and to
> react accordingly.
>
> To make a simple example: I need to set up a call with some requirements.
> I (or my access router) send an NSIS signalling packet including some form
> of specifications & requirements. This packet is locally handled by each
> network node (domain) as follow: if the node (domain) can guarantee the
> reqs, it just forwards the NSIS packet along; If it cannot guarantee the
> reqs, but it can accept the request with some downgraded form of of
> support, it marks the packet; if, finally, it cannot accept the request,
> it just says no (by, e.g. suitably marking the NSIS packet, or, as we
> suggested in an earlier internet draft to make this idea compatible with
> DiffServ domains, blocking it - timeouts at the end points will do the
> rest). When the NSIS signalling packet gets back to the sender, it
> contains all the relevant information to proceed.
>
> Giuseppe Bianchi
> bianchi@elet.polimi.it
> http://cerbero.elet.polimi.it/people/bianchi
>


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



From daemon@optimus.ietf.org  Fri Jan 18 11:04: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 LAA16344
	for <nsis-archive@odin.ietf.org>; Fri, 18 Jan 2002 11:04:33 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id LAA20137
	for nsis-archive@odin.ietf.org; Fri, 18 Jan 2002 11:04: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 KAA18942;
	Fri, 18 Jan 2002 10:50: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 KAA18915
	for <nsis@optimus.ietf.org>; Fri, 18 Jan 2002 10:50:02 -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 KAA15463
	for <nsis@ietf.org>; Fri, 18 Jan 2002 10:49:57 -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 g0IFq1T18300;
	Fri, 18 Jan 2002 09:52:01 -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 g0IFnPl00986;
	Fri, 18 Jan 2002 09:49:25 -0600 (CST)
Received: by TRIMAIL2.ad.tri.sbc.com with Internet Mail Service (5.5.2653.19)
	id <ZND32L1X>; Fri, 18 Jan 2002 09:49:51 -0600
Message-ID: <905A1C4ABF353F4C8CC16FA9F53DD0D6322423@TRIMAIL2.ad.tri.sbc.com>
From: "Chen, Weijing" <wchen@tri.sbc.com>
To: "'Roy, Radhika R, ALASO'" <rrroy@att.com>,
        "Loughney John (NRC/Helsinki)" <john.loughney@nokia.com>,
        "Georgios Karagiannis (ELN)" <Georgios.Karagiannis@eln.ericsson.se>
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements
Date: Fri, 18 Jan 2002 09:49:46 -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

Yes, yes! This is what we must do first.

* [RRR] Host will only express its needs 
* [wj] >> to network >> to satisfy the 
> applications. We can standardize in a simple way how a host 
> can express its needs. [wj] >> to edge of the network.


--
Weijing Chen
SBC Technology Resources
9505 Arboretum Blvd.
Austin, TX 78759
512 372 5710
wchen@tri.sbc.com


 -----Original Message-----
From: 	Roy, Radhika R, ALASO [mailto:rrroy@att.com] 
Sent:	Friday, January 18, 2002 8:19 AM
To:	Loughney John (NRC/Helsinki); Chen, Weijing; Georgios Karagiannis
(ELN)
Cc:	nsis@ietf.org
Subject:	RE: [NSIS] Two kinds of requirements

Hi, John:

I agree with you. 

Thanks,
Radhika

-----Original Message-----
From: Loughney John (NRC/Helsinki) [mailto:john.loughney@nokia.com]
Sent: Friday, January 18, 2002 7:40 AM
To: Roy, Radhika R, ALASO; Chen, Weijing; Georgios Karagiannis (ELN)
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


Hi Radhika,

> [RRR] Host will only express its needs to satisfy the 
> applications. We can standardize in a simple way how a host 
> can express its needs.

I can agree with this, we should discuss how to do this
as part of the NSIS work.
 
> [RRR] Edge is where the actual implementation starts: Complex 
> signaling to reserve the resources. An edge might have to 
> work with an entity (e.g., proxy/bandwidth broker) that has 
> the global knowledge for the end-to-end topology and can 
> implement QOS dynamically. 

This may be out of scope of the current charter - it depends
on how detailed we get into this.  I think that we may wish
to address this within the framework, but how reservations
are made are out of scope.  After we get the main work done,
we could always recharter to work on tihs.
 
> [RRR] In other cases, SLAs will help to ensure what needs to 
> be done in each domain/segment where the end-to-end path/QOS 
> allocation is priori known. Each domain will implement its own part.

Agreed.  There are those who might want to use contractual methods
to reserve bandwidth as opposed to protocol methods ..

John

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



From daemon@optimus.ietf.org  Fri Jan 18 11:14: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 LAA16777
	for <nsis-archive@odin.ietf.org>; Fri, 18 Jan 2002 11:14:18 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id LAA20585
	for nsis-archive@odin.ietf.org; Fri, 18 Jan 2002 11:14: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 LAA19777;
	Fri, 18 Jan 2002 11:00: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 LAA19747
	for <nsis@optimus.ietf.org>; Fri, 18 Jan 2002 11:00:52 -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 LAA16079
	for <nsis@ietf.org>; Fri, 18 Jan 2002 11:00:47 -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 g0IG2pT18401;
	Fri, 18 Jan 2002 10:02:51 -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 g0IG0FT01516;
	Fri, 18 Jan 2002 10:00:15 -0600 (CST)
Received: by TRIMAIL2.ad.tri.sbc.com with Internet Mail Service (5.5.2653.19)
	id <ZND32LHZ>; Fri, 18 Jan 2002 10:00:41 -0600
Message-ID: <905A1C4ABF353F4C8CC16FA9F53DD0D6322424@TRIMAIL2.ad.tri.sbc.com>
From: "Chen, Weijing" <wchen@tri.sbc.com>
To: "'dick.rr.knight@bt.com'" <dick.rr.knight@bt.com>,
        "Schneider, Marco"
	 <schneider@tri.sbc.com>,
        Georgios.Karagiannis@eln.ericsson.se
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements (priority on the boundary be
	 tween a customer and the network)
Date: Fri, 18 Jan 2002 10:00:37 -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

Let's look at this picture again:


                       1                                  2
1
[host]
<------[hop]------>[edge]<------[hop]------>[edge]<------[hop]------->[host]
              access network            core network               access
network

                                                        3
[host]<---------------------------------------------------------------------
------------->[host]


The 3 is comprised of 1 and 2. As we know, there are solutions for 2 (MPLS,
DiffServ, PNNI, over-provisioning, etc). What we need to solve is the 1.
Now what about translation (or mapping) between 1 and 2? Do we need to
standardize it? 

The objective of 1 is KISS and universal. The complexity of 1 and 2 mapping
will be born by the [edge].


--
Weijing Chen
SBC Technology Resources
9505 Arboretum Blvd.
Austin, TX 78759
512 372 5710
wchen@tri.sbc.com


 -----Original Message-----
From: 	dick.rr.knight@bt.com [mailto:dick.rr.knight@bt.com] 
Sent:	Friday, January 18, 2002 5:12 AM
To:	Schneider, Marco; Georgios.Karagiannis@eln.ericsson.se;
dick.rr.knight@bt.com
Cc:	nsis@ietf.org
Subject:	RE: [NSIS] Two kinds of requirements (priority on the
boundary be tween a customer and the network)


I do not agree.

What is the point of completing the work enabling the customer to signal to
the network, if the network cannot signal between domains? The network can
never satisfy the request.

Dick

-----Original Message-----
From: Schneider, Marco [mailto:schneider@tri.sbc.com]
Sent: 18 January 2002 01:44
To: 'Georgios Karagiannis (ELN)'; 'dick.rr.knight@bt.com'
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


Hi Georgios,

While I agree NSIS could be used to support Interior to Interior (of one
carrier) or Edge to Core, I think that we need to prioritize on a signaling
protocol across the boundary between a customer and the network. Note that
the customer could be an individual, an ISP or another Carrier.

Marco Schneider

-----Original Message-----
From: Georgios Karagiannis (ELN)
[mailto:Georgios.Karagiannis@eln.ericsson.se]
Sent: Thursday, January 17, 2002 3:39 AM
To: 'dick.rr.knight@bt.com'
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


Hi Dick 

In principle I agree with your comment (see below).

[DK] >> To be more precise, I am suggesting a new protocol that is 
[DK] >> independent of the underlying transport technology and the QoS 
[DK] >> implemented and is also independent of the session control protocol.


However, a very important point here is that we need to 
specify a protocol that can be used independent of the underlying transport 
technology, but that can satisfy the QoS requirements imposed by these 
underlying transport technologies. Otherwise the protocol will not be
suitable
and useful.

A way of achieving this is by first creating a modular QoS signaling toolkit

that will contain mandatory and optional QoS requirements;
Second, specify how the protocol functionality should be separated in 
building blocks (protocol components) and define a minimum set 
of mandatory reservation options/features that should be 
processed by any network nodes, e.g., end-hosts,
proxies, edges and interior nodes.
An example of such a protocol decomposition is given below!
In this way each node will only process (check and use) the protocol 
components of interest.


|---------|
|---------|
|everyhost|<------------------------------------------------------->|everyho
st|
|---------|
|---------|
|         |                                                         |
|
|---------|   |---------|                             |---------|
|---------|
|everyedge|<->|everyedge|<--------------------------->|everyedge|<->|everyed
ge|
|---------|   |---------|                             |---------|
|---------|
|         |   |         |                             |         |   |
|
|---------|   |---------|   |--------|   |--------|   |---------|
|---------|
|everyhop |<->|everyhop |<->|everyhop|<->|everyhop|<->|everyhop
|<->|everyhop |
|---------|   |---------|   |--------|   |--------|   |---------|
|---------| 
    host          edge        interior    interior       edge          host


  NSIS protocol decomposition (building blocks): 
 *  "everyhost", "everyedge" and "everyhop" are protocol components;
 *  host: can be an end-host or a proxy and it can process and use the
"everyhost", 
    "everyedge", and "everyhop" protocol components;

 *  edge: can be a Diffserv edge, MPLS edge, etc., and it can process and
use 
    the "everyedge", and "everyhop" protocol components. The "everyhost" 
    protocol component is not processed (used or checked);

 *  interior: can be any router within a domain and it can process and use 
    only the "everyhop" protocol component.
    The "everyhost" and "everyedge" protocol components are not 
    processed (used or checked);


Best Regards,
Georgios

-----Original Message-----
From: dick.rr.knight@bt.com [mailto:dick.rr.knight@bt.com]
Sent: woensdag 16 januari 2002 13:00
To: brian.williams@ericsson.com.au; lieve.bos@alcatel.be
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


I was waiting for some reaction to Brian's comments, but as there aren't
any, here are my thoughts on the requirements:

I agree with the analysis that discussion has been based around
application-related signalling for QoS (at session level) and QoS signalling
protocols used to actually provision the QoS at the transport level.
Brian is right that there will never be an enhancement to a single session
protocol that will satisfy all applications.
However, for similar reasons, it is never going to be possible to prescribe
a single QoS mechanism to be used in all networks. Existing networks (or
domains) will not be changed overnight and new networks already face several
workable mechanisms to deploy QoS.

I think that what is needed is a new protocol that can signal the
requirements of any session and can be satisfied by any QoS mechanism,
existing or new.
To be more precise, I am suggesting a new protocol that is independent of
the underlying transport technology and the QoS implemented and is also
independent of the session control protocol. Such a new protocol would be
generic, optionally implemented by applications that would benefit from
end-to-end QoS, and would be complimentary to the QoS mechanisms deployed
(and of course other mechanisms, such as the routing).

I think that this implies a more abstract definition of the QoS mechanism
and may lend itself to the signalling of pre-defined QoS classes rather than
parameters.

Dick Knight

-----Original Message-----
From: Brian Williams [mailto:brian.williams@ericsson.com.au]
Sent: 22 December 2001 23:57
To: lieve.bos@alcatel.be
Cc: nsis@ietf.org
Subject: Re: [NSIS] Two kinds of requirements


Hi.
While the two types of signalling may be related, I think there is a
need to develop a QoS bearer mechanism which is independent of any
specific session signalling, and thus can be used for any application. I
believe many of the applications which have identified requirements to
the working group have their own specific session layer signalling (ie
it is not end-to-end SIP).  

Having the session and transport protocols developed separately of
course does not prohibit the two being used in conjunction for a
specific application.
/brian
 
On Fri, 2001-12-21 at 22:24, lieve.bos@alcatel.be wrote:
> Hello all,
> 
> >From the discussion in Salt Lake city and the drafts submitted, one can
> easily see that people are suggesting improvements to QoS signalling at
> two totally different levels (some at session level and some at
> transport level).
> 
> First of all, there are drafts suggesting some improvements in the
> session setup procedures (i.e. the ability to negotiate the preferred
> QoS level between end users during SDP negotiation in SIP, so before the
> actual resources are being setup). The QoS information negotiated at the
> session layer determines the QoS level both endusers have to use for 
> their local access connection. This first kind of 'session level QoS
> negotiation' happens end-to-end between the two end-users.
> 
> Secondly, there are drafts suggesting that we need
> improvements/alternatives for the QoS signalling protocols (e.g. RSVP)
> used to actually provision the QoS at the transport level between two
> endusers. This second kind of 'transport level QoS signalling' can
> consist of several phases: end-to-edge and edge-to-edge. 
> 
> It's important that everybody realises that, in order to give endusers
> true end-to-end Quality of Service, we need improvements for QoS both at
> session and transport level. Also its important to understand that they
> are not uncorrelated. Providers want to be able to control (e.g. via
> policy control mechanisms) that the QoS requested at the transport level
> is not exceeding the QoS negotiated/authorised previously at session
> level. So, what about developing in NSIS a modular framework
> incorporating both session and transport level QoS signalling with
> possible hooks between the two layers (e.g. for policy enforcement).
> 
> Lieve
> 
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis



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

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

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

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

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



From daemon@optimus.ietf.org  Fri Jan 18 11:14: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 LAA16794
	for <nsis-archive@odin.ietf.org>; Fri, 18 Jan 2002 11:14:23 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id LAA20599
	for nsis-archive@odin.ietf.org; Fri, 18 Jan 2002 11:14:26 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA19841;
	Fri, 18 Jan 2002 11:01: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 LAA19807
	for <nsis@optimus.ietf.org>; Fri, 18 Jan 2002 11:01:16 -0500 (EST)
Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16100
	for <nsis@ietf.org>; Fri, 18 Jan 2002 11:01:12 -0500 (EST)
Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87])
	by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g0IG2mQ09553
	for <nsis@ietf.org>; Fri, 18 Jan 2002 10:02:48 -0600 (CST)
Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T588573b73cac12f2570d5@davir04nok.americas.nokia.com> for <nsis@ietf.org>;
 Fri, 18 Jan 2002 10:01:15 -0600
Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Fri, 18 Jan 2002 10:01:15 -0600
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: Re: [NSIS] Two kinds of requirements  (unsupported domains + chick en and eggs)
Date: Fri, 18 Jan 2002 11:01:14 -0500
Message-ID: <E320A8529CF07E4C967ECC2F380B0CF9064BD8@bsebe001.NOE.Nokia.com>
Thread-Topic: [NSIS] Two kinds of requirements  (unsupported domains + chick en and eggs)
Thread-Index: AcGgOA6mh92zHYhBSZW3w4BC71Y2UQAAQeTAAAAOnUA=
From: "Chaskar Hemant (NRC/Boston)" <Hemant.Chaskar@nokia.com>
To: <nsis@ietf.org>
X-OriginalArrivalTime: 18 Jan 2002 16:01:15.0180 (UTC) FILETIME=[5B804EC0:01C1A039]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA19808
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

IMHO, this shouldn't be in NSIS scope. It is congestion control issue.
Of course, if one wants to do congestion control by tear-down and new
set-up of QoS call, he may use NSIS protocols :-)

-----Original Message-----
From: ext Giuseppe Bianchi [mailto:bianchi@morgana.elet.polimi.it]
Sent: Friday, January 18, 2002 10:50 AM
To: dick.rr.knight@bt.com
Cc: blefari@diei.unipg.it; nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements (unsupported domains +
chick en and eggs)



Right, I had misread your email, and I definitely agree with your
solution
when specifically dealing with connection setup.

Indeed, if we consider using NSIS refreshes as a mean to allow
application's adaptation (e.g. rate reduction), some forms of feedbacks
from the network via packet marking appear necessary (actually, is this
issue within the scopes of NSIS?)

Giuseppe.


On Fri, 18 Jan 2002 dick.rr.knight@bt.com wrote:

> I think that you agree with me but didn't quite understand what I was
> suggesting.
>
> I agree that it is the user that makes the decision about a chunk of
network
> that cannot support the requested QoS.
>
> But why mark the packet and continue on all the way to the destination
and
> back? It is simpler for a user to indicate in the original request:
> 1. Don't downgrade
> 2. Downgrade to no lower than [x]
> 3. I'd prefer QoS [n] but I'll accept Best Efoort if I have to.
>
> Then you can set up the connection in one go.
>
> It is also slightly better, if you accept (and we haven't discussed
this
> yet) that the choice of route can be influenced by the requested QoS.
If the
> user has marked 1 (above) you might route differently to 2 or 3, as an
> alternative to just failing the connection.
>
> Dick
>
>
> -----Original Message-----
> From: Giuseppe Bianchi [mailto:bianchi@morgana.elet.polimi.it]
> Sent: 18 January 2002 13:36
> To: dick.rr.knight@bt.com; blefari
> Cc: nsis@ietf.org
> Subject: RE: [NSIS] Two kinds of requirements (unsupported domains +
> chick en and eggs)
>
>
>
> Extending Dick's comment:
>
> On Fri, 18 Jan 2002 dick.rr.knight@bt.com wrote:
> > [...]
> > The protocol reaches a node at the edge of a domain/network
(aneveryedge
> > node) and knows that the best routing from here is through a chunk
of
> > besteffort (the routing tables tell it so). The node needs to decide
> whether
> > or not to progress or to refuse. This gives us a requirement on the
> > protocol: we need to include a class that says "I'd rather get my
comms
> link
> > up with a reduced QoS than get a refusal". We also need a class that
says
> > "don't down downgrade me" or "don't down downgrade me below
[classX]". If
> it
> > does progress across this network domain, we can still signal into
the
> next
> > NSIS-aware domain (as I am hoping the domain without support can
still
> route
> > packets).
> > Note: Best effort means that there are no guarantees because NSIS is
not
> > supported. It might be overprovisioned and providing a superior
service,
> but
> > it doesn't have a CAC.
>
> Why leaving this decision up to the node? An alternative (which may
> actually coexist with Dick's idea) is to use a form of marking, and
take
> back to the user the information that one domain along the path is
Best
> Effort... Depending on its requirements, the user will know whether to
> progress or to refuse.
>
> On a more general point of view, and in the spirit of the Internet,
I'd
> recommend to keep as much as possible the intelligence at the edge of
the
> network. In this sense, NSIS should be designed as a protocol that
allows
> end nodes to discover the state of the nodes/domains along the path
and to
> react accordingly.
>
> To make a simple example: I need to set up a call with some
requirements.
> I (or my access router) send an NSIS signalling packet including some
form
> of specifications & requirements. This packet is locally handled by
each
> network node (domain) as follow: if the node (domain) can guarantee
the
> reqs, it just forwards the NSIS packet along; If it cannot guarantee
the
> reqs, but it can accept the request with some downgraded form of of
> support, it marks the packet; if, finally, it cannot accept the
request,
> it just says no (by, e.g. suitably marking the NSIS packet, or, as we
> suggested in an earlier internet draft to make this idea compatible
with
> DiffServ domains, blocking it - timeouts at the end points will do the
> rest). When the NSIS signalling packet gets back to the sender, it
> contains all the relevant information to proceed.
>
> Giuseppe Bianchi
> bianchi@elet.polimi.it
> http://cerbero.elet.polimi.it/people/bianchi
>


_______________________________________________
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 Jan 18 11:21: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 LAA17050
	for <nsis-archive@odin.ietf.org>; Fri, 18 Jan 2002 11:21:47 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id LAA20839
	for nsis-archive@odin.ietf.org; Fri, 18 Jan 2002 11:21: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 LAA20449;
	Fri, 18 Jan 2002 11:12: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 LAA20376
	for <nsis@optimus.ietf.org>; Fri, 18 Jan 2002 11:12:08 -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 LAA16687
	for <nsis@ietf.org>; Fri, 18 Jan 2002 11:12:05 -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 g0IGEBT18487;
	Fri, 18 Jan 2002 10:14:11 -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 g0IGBZm01991;
	Fri, 18 Jan 2002 10:11:35 -0600 (CST)
Received: by TRIMAIL2.ad.tri.sbc.com with Internet Mail Service (5.5.2653.19)
	id <ZND32LKT>; Fri, 18 Jan 2002 10:12:01 -0600
Message-ID: <905A1C4ABF353F4C8CC16FA9F53DD0D6322425@TRIMAIL2.ad.tri.sbc.com>
From: "Chen, Weijing" <wchen@tri.sbc.com>
To: "'dick.rr.knight@bt.com'" <dick.rr.knight@bt.com>,
        "Schneider, Marco"
	 <schneider@tri.sbc.com>,
        Georgios.Karagiannis@eln.ericsson.se
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements (priority on the boundary be
	 tween a customer and the network)
Date: Fri, 18 Jan 2002 10:11:57 -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

Sorry, previous picture is garbled by mailer. 


[host]<--1--[hop]-->[edge]<---2---[hop]-->[edge]<--1--[hop]-->[host]

[host]<-------------------3------------------------------------------------>
[host]


The 3 is our goal and is comprised of 1 and 2. As we know, there are
solutions for 2 (MPLS, DiffServ, PNNI, over-provisioning, etc). What we need
to solve is the 1.  Now what about translation (or mapping) between 1 and 2?
Do we need to standardize it?  If yes, where? In NSIS group or elsewhere?

Regardless, the objective of 1 is KISS and universal. The complexity of 1
and 2 mapping must be born by the [edge].



--
Weijing Chen
SBC Technology Resources
9505 Arboretum Blvd.
Austin, TX 78759
512 372 5710
wchen@tri.sbc.com



 -----Original Message-----
From: 	dick.rr.knight@bt.com [mailto:dick.rr.knight@bt.com] 
Sent:	Friday, January 18, 2002 5:12 AM
To:	Schneider, Marco; Georgios.Karagiannis@eln.ericsson.se;
dick.rr.knight@bt.com
Cc:	nsis@ietf.org
Subject:	RE: [NSIS] Two kinds of requirements (priority on the
boundary be tween a customer and the network)


I do not agree.

What is the point of completing the work enabling the customer to signal to
the network, if the network cannot signal between domains? The network can
never satisfy the request.

Dick

-----Original Message-----
From: Schneider, Marco [mailto:schneider@tri.sbc.com]
Sent: 18 January 2002 01:44
To: 'Georgios Karagiannis (ELN)'; 'dick.rr.knight@bt.com'
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


Hi Georgios,

While I agree NSIS could be used to support Interior to Interior (of one
carrier) or Edge to Core, I think that we need to prioritize on a signaling
protocol across the boundary between a customer and the network. Note that
the customer could be an individual, an ISP or another Carrier.

Marco Schneider

-----Original Message-----
From: Georgios Karagiannis (ELN)
[mailto:Georgios.Karagiannis@eln.ericsson.se]
Sent: Thursday, January 17, 2002 3:39 AM
To: 'dick.rr.knight@bt.com'
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


Hi Dick 

In principle I agree with your comment (see below).

[DK] >> To be more precise, I am suggesting a new protocol that is 
[DK] >> independent of the underlying transport technology and the QoS 
[DK] >> implemented and is also independent of the session control protocol.


However, a very important point here is that we need to 
specify a protocol that can be used independent of the underlying transport 
technology, but that can satisfy the QoS requirements imposed by these 
underlying transport technologies. Otherwise the protocol will not be
suitable
and useful.

A way of achieving this is by first creating a modular QoS signaling toolkit

that will contain mandatory and optional QoS requirements;
Second, specify how the protocol functionality should be separated in 
building blocks (protocol components) and define a minimum set 
of mandatory reservation options/features that should be 
processed by any network nodes, e.g., end-hosts,
proxies, edges and interior nodes.
An example of such a protocol decomposition is given below!
In this way each node will only process (check and use) the protocol 
components of interest.


|---------|
|---------|
|everyhost|<------------------------------------------------------->|everyho
st|
|---------|
|---------|
|         |                                                         |
|
|---------|   |---------|                             |---------|
|---------|
|everyedge|<->|everyedge|<--------------------------->|everyedge|<->|everyed
ge|
|---------|   |---------|                             |---------|
|---------|
|         |   |         |                             |         |   |
|
|---------|   |---------|   |--------|   |--------|   |---------|
|---------|
|everyhop |<->|everyhop |<->|everyhop|<->|everyhop|<->|everyhop
|<->|everyhop |
|---------|   |---------|   |--------|   |--------|   |---------|
|---------| 
    host          edge        interior    interior       edge          host


  NSIS protocol decomposition (building blocks): 
 *  "everyhost", "everyedge" and "everyhop" are protocol components;
 *  host: can be an end-host or a proxy and it can process and use the
"everyhost", 
    "everyedge", and "everyhop" protocol components;

 *  edge: can be a Diffserv edge, MPLS edge, etc., and it can process and
use 
    the "everyedge", and "everyhop" protocol components. The "everyhost" 
    protocol component is not processed (used or checked);

 *  interior: can be any router within a domain and it can process and use 
    only the "everyhop" protocol component.
    The "everyhost" and "everyedge" protocol components are not 
    processed (used or checked);


Best Regards,
Georgios

-----Original Message-----
From: dick.rr.knight@bt.com [mailto:dick.rr.knight@bt.com]
Sent: woensdag 16 januari 2002 13:00
To: brian.williams@ericsson.com.au; lieve.bos@alcatel.be
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


I was waiting for some reaction to Brian's comments, but as there aren't
any, here are my thoughts on the requirements:

I agree with the analysis that discussion has been based around
application-related signalling for QoS (at session level) and QoS signalling
protocols used to actually provision the QoS at the transport level.
Brian is right that there will never be an enhancement to a single session
protocol that will satisfy all applications.
However, for similar reasons, it is never going to be possible to prescribe
a single QoS mechanism to be used in all networks. Existing networks (or
domains) will not be changed overnight and new networks already face several
workable mechanisms to deploy QoS.

I think that what is needed is a new protocol that can signal the
requirements of any session and can be satisfied by any QoS mechanism,
existing or new.
To be more precise, I am suggesting a new protocol that is independent of
the underlying transport technology and the QoS implemented and is also
independent of the session control protocol. Such a new protocol would be
generic, optionally implemented by applications that would benefit from
end-to-end QoS, and would be complimentary to the QoS mechanisms deployed
(and of course other mechanisms, such as the routing).

I think that this implies a more abstract definition of the QoS mechanism
and may lend itself to the signalling of pre-defined QoS classes rather than
parameters.

Dick Knight

-----Original Message-----
From: Brian Williams [mailto:brian.williams@ericsson.com.au]
Sent: 22 December 2001 23:57
To: lieve.bos@alcatel.be
Cc: nsis@ietf.org
Subject: Re: [NSIS] Two kinds of requirements


Hi.
While the two types of signalling may be related, I think there is a
need to develop a QoS bearer mechanism which is independent of any
specific session signalling, and thus can be used for any application. I
believe many of the applications which have identified requirements to
the working group have their own specific session layer signalling (ie
it is not end-to-end SIP).  

Having the session and transport protocols developed separately of
course does not prohibit the two being used in conjunction for a
specific application.
/brian
 
On Fri, 2001-12-21 at 22:24, lieve.bos@alcatel.be wrote:
> Hello all,
> 
> >From the discussion in Salt Lake city and the drafts submitted, one can
> easily see that people are suggesting improvements to QoS signalling at
> two totally different levels (some at session level and some at
> transport level).
> 
> First of all, there are drafts suggesting some improvements in the
> session setup procedures (i.e. the ability to negotiate the preferred
> QoS level between end users during SDP negotiation in SIP, so before the
> actual resources are being setup). The QoS information negotiated at the
> session layer determines the QoS level both endusers have to use for 
> their local access connection. This first kind of 'session level QoS
> negotiation' happens end-to-end between the two end-users.
> 
> Secondly, there are drafts suggesting that we need
> improvements/alternatives for the QoS signalling protocols (e.g. RSVP)
> used to actually provision the QoS at the transport level between two
> endusers. This second kind of 'transport level QoS signalling' can
> consist of several phases: end-to-edge and edge-to-edge. 
> 
> It's important that everybody realises that, in order to give endusers
> true end-to-end Quality of Service, we need improvements for QoS both at
> session and transport level. Also its important to understand that they
> are not uncorrelated. Providers want to be able to control (e.g. via
> policy control mechanisms) that the QoS requested at the transport level
> is not exceeding the QoS negotiated/authorised previously at session
> level. So, what about developing in NSIS a modular framework
> incorporating both session and transport level QoS signalling with
> possible hooks between the two layers (e.g. for policy enforcement).
> 
> Lieve
> 
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis



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

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

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

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

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



From daemon@optimus.ietf.org  Fri Jan 18 11:30:06 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17407
	for <nsis-archive@odin.ietf.org>; Fri, 18 Jan 2002 11:30:06 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id LAA21184
	for nsis-archive@odin.ietf.org; Fri, 18 Jan 2002 11:30: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 LAA20806;
	Fri, 18 Jan 2002 11:20: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 LAA20777
	for <nsis@optimus.ietf.org>; Fri, 18 Jan 2002 11:20:50 -0500 (EST)
Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17010
	for <nsis@ietf.org>; Fri, 18 Jan 2002 11:20:46 -0500 (EST)
Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate3.mot.com (motgate3 2.1) with ESMTP id JAA09293 for <nsis@ietf.org>; Fri, 18 Jan 2002 09:10:35 -0700 (MST)]
Received: [from samichlaus.rsch.comm.mot.com (samichlaus.rsch.comm.mot.com [145.1.80.28]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id JAA11266 for <nsis@ietf.org>; Fri, 18 Jan 2002 09:20:48 -0700 (MST)]
Received: (from gilbert@localhost)
	by samichlaus.rsch.comm.mot.com (8.9.3+Sun/8.8.8) id KAA13558;
	Fri, 18 Jan 2002 10:20:50 -0600 (CST)
Date: Fri, 18 Jan 2002 10:20:50 -0600 (CST)
Message-Id: <200201181620.KAA13558@samichlaus.rsch.comm.mot.com>
X-Authentication-Warning: samichlaus.rsch.comm.mot.com: gilbert set sender to gilbert@samichlaus.rsch.comm.mot.com using -f
To: nsis@ietf.org
From: "Steve Gilbert" <gilbert@rsch.comm.mot.com>
Reply-to: gilbert@rsch.comm.mot.com
User-Agent: SEMI/1.13.7 (Awazu) FLIM/1.13.2 (Kasanui) Emacs/20.5 (sparc-sun-solaris2.6) MULE/4.0 (HANANOEN)
MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu")
Content-Type: text/plain; charset=US-ASCII
Subject: [NSIS] Support needed for Throughput Adaptive QoS in wireless
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



I tend to agree with the need which Herman identifies (below) for throughput
adaptive capabilities in a wireless QoS system.

The cellular wireless QoS problem is very different than that of wired QoS
because of the need to handle the case of a user with a QoS "guarantee" handing
off into a different cell.  In the worst case, the cell which it is entering may
have its resources fully allocated to existing users. Dropping the session of
the user being handed off is not a good idea. This points out the need for some
rational way to accommodate such calls. The approach taken in some wireless
voice systems is to reserve resources for use only by sessions which are handing
off into the cell. This may suffice if the resource needs of the hand off
session are predictable. However, in a system in which arbitrary applications
can utilize a wide range of throughput values, reserving enough capacity to
handle the range of throughputs which could potentially be needed by a single
flow may not be practical.

What is needed is the use of throughput adaptive applications and the ability
for a traffic flow to express its QoS preferences with regard to the throughput
values which it may be allocated. Upon handing off into the new cell, the QoS
preferences of the handoff traffic flow and of the existing traffic flows in
that cell would be considered and resources reallocated to best meet their
preferences. Some of the existing traffic flows may have their throughput
allocations reduced in order to free up resources to be allocated to the handoff
traffic flow.

The QoS signaling needs of this approach include the ability of the system to
notify traffic flows of their new allocations, and the ability for a new traffic
flow requesting "admission" to express its QoS preferences, possibly in terms of
a list of throughput values and the benefit it receives from each. A
non-adaptive real-time application would indicate a single throughput value
which it desires rather than a list of throughput values.

One could argue that this provides no throughput "guarantee" and changes what it
means to have a QoS request "admitted". This is true. But in wireless, it is
difficult and sometimes impractical to provide the same QoS guarantees that
could be provided in a wireline system which doesn't have to deal with
handoff. In a wireless system, there is the possibility that the user will drive
into a tunnel or take the elevator to a sub-basement of a building where the
wireless signal is lost. Radio coverage and QoS can not be guaranteed under all
possible situations.  Wireless channel resources are often more scarce or
expensive than those of a wired channel. This generally results in the
motivation to utilize them more efficiently. What is more realistic than trying
to provide wireless QoS identical to that of wire-line is to come up with a
useful approach for "QoS management" and "resource allocation" which can be
applied in a wireless system.

If efficient utilization of the resources by QoS flows is not a major concern,
the QoS of admitted users could be increased (or at least made less prone to
reductions) through over-provisioning or preventing admission of new calls even
when the level of congestion is still low. The resources not guaranteed to QoS
traffic flows could be used by best effort traffic. Systems with significant
best effort traffic would be able to increase the overall utilization of the
channel without negatively effecting QoS traffic flows.

Steve



> Date: Thu, 17 Jan 2002 19:49:13 +0000
> To: "Georgios Karagiannis (ELN)" <Georgios.Karagiannis@eln.ericsson.se>,
>    "'Loughney John (NRC/Helsinki)'" <john.loughney@nokia.com>,
>    "'ext Kappler Cornelia'" <Cornelia.Kappler@icn.siemens.de>
> From: Hermann De Meer <h.demeer@ee.ucl.ac.uk>
> Cc: <nsis@ietf.org>
> Subject: RE: [NSIS] Two kinds of requirements
> 
> Hi Georgios and all
> 
> At 14:09 17/01/2002 +0100, Georgios Karagiannis (ELN) wrote:
> >Hi John and Cornelia
> >
> >I think that one of the requirements that should be included
> >in the NSIS WG requirements document is that the NSIS protocol
> >should be modular. Modular in the context of having
> >a toolkit from which one can choose the applicable tools
> >in order to manage QoS in a particular networking environment.
> 
> I believe you are raising a very important issue with the emphasis on 
> modularity
> of QoS architectures/signalling.
> 
> But one can generalize that: it's all about flexibility,
> namely flexibility of signalling/control/provisioning vs. flexibility of 
> applications/users.
> 
> Flexibility does not necessarily mean complexity, often on the contrary:
> one side being flexible makes the life for the other side easier (think of 
> airline ticket pricing:
> the price for the *same seat* can vary in an order of magnitude simply
> depending on how flexible you are!)
> 
> QoS signalling is about indicating of how "inflexible" you are from that 
> perspective.
> But looking at IntServ (RSVP) or DiffServ,  an interpretation of these signals
> have traditionally been seen rather statically:
> 
> - a "one-size-fits-all"  "end-to-end" implementation of the mechanisms
> - a "take-it-or-leave-it" approach: statically defined QoS classes.
> 
> this makes QoS provisioning cumbersome, complex, expensive (unnecessarily)
> (and it may be a good deal the reason for the "failure/insufficiency" of 
> current QoS solutions/
> signalling techniques).
> 
> Remember, the success of IP networking has to a larger extend been due to 
> the fact of
> relying on flexibility and cooperation, for example, for congestion handling.
> (or "exception" handling, if you want, by TCP-similar schemes)
> 
> in <draft-demeer-nsis-analyis-00.txt> we therefore make a point to extend 
> QoS signalling for:
> 
> 1) explicitly dealing with such "QoS exceptions" (there is also an economic 
> argument for this)
>      that is, not only signaling QoS preferences from applications to the 
> network, but also
>      QoS exceptions back from networks to applications or to between networks,
>      and an expected cooperative adaptation.
> 
> 2) allowing for flexible interpretations in different domains (core, 
> access, mobile, wireless,
>       administrative conditions, ....)
> 
> 
> The "trick" may be to modify signalling (including RSVP) such that most 
> flexibility/cooperation
> can be re-gained by assuring a minimum support of inflexibility 
> (intentionally not using the
> the term QoS guarantee here).
> 
> 
> --Hermann
> 
...

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



From daemon@optimus.ietf.org  Fri Jan 18 11:53:58 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18522
	for <nsis-archive@odin.ietf.org>; Fri, 18 Jan 2002 11:53:58 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id LAA22271
	for nsis-archive@odin.ietf.org; Fri, 18 Jan 2002 11:54: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 LAA21829;
	Fri, 18 Jan 2002 11:42: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 LAA21797
	for <nsis@optimus.ietf.org>; Fri, 18 Jan 2002 11:42:54 -0500 (EST)
Received: from cbibipnt08.hc.bt.com (saturn.bt.com [193.113.57.20])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18025
	for <nsis@ietf.org>; Fri, 18 Jan 2002 11:42:49 -0500 (EST)
From: dick.rr.knight@bt.com
Received: by cbibipnt08.hc.bt.com with Internet Mail Service (5.5.2654.89)
	id <DA1W4TBJ>; Fri, 18 Jan 2002 16:36:42 -0000
Message-ID: <451D45016C2CD2119DA50000F8FE7F07080E5A43@mlngcbnt01.hc.bt.com>
To: Hemant.Chaskar@nokia.com, nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements   (unsupported domains + chi
	ck en and eggs)
Date: Fri, 18 Jan 2002 16:36:31 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2654.89)
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

It doesn't really matter, but it isn't congestion control either. It is
traffic shaping.

If you don't have any QoS, and all users traffic is equal (in terms of
priority) then when a single user's traffic eats up "too much" of the buffer
space, then you throttle them back by using rate reduction. TCP does this.
SCTP uses other means.

Interesting though this is, I don't think that this is what NSIS is all
about.

Dick

-----Original Message-----
From: Chaskar Hemant (NRC/Boston) [mailto:Hemant.Chaskar@nokia.com]
Sent: 18 January 2002 16:01
To: nsis
Subject: Re: [NSIS] Two kinds of requirements (unsupported domains +
chick en and eggs)


IMHO, this shouldn't be in NSIS scope. It is congestion control issue.
Of course, if one wants to do congestion control by tear-down and new
set-up of QoS call, he may use NSIS protocols :-)

-----Original Message-----
From: ext Giuseppe Bianchi [mailto:bianchi@morgana.elet.polimi.it]
Sent: Friday, January 18, 2002 10:50 AM
To: dick.rr.knight@bt.com
Cc: blefari@diei.unipg.it; nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements (unsupported domains +
chick en and eggs)



Right, I had misread your email, and I definitely agree with your
solution
when specifically dealing with connection setup.

Indeed, if we consider using NSIS refreshes as a mean to allow
application's adaptation (e.g. rate reduction), some forms of feedbacks
from the network via packet marking appear necessary (actually, is this
issue within the scopes of NSIS?)

Giuseppe.


On Fri, 18 Jan 2002 dick.rr.knight@bt.com wrote:

> I think that you agree with me but didn't quite understand what I was
> suggesting.
>
> I agree that it is the user that makes the decision about a chunk of
network
> that cannot support the requested QoS.
>
> But why mark the packet and continue on all the way to the destination
and
> back? It is simpler for a user to indicate in the original request:
> 1. Don't downgrade
> 2. Downgrade to no lower than [x]
> 3. I'd prefer QoS [n] but I'll accept Best Efoort if I have to.
>
> Then you can set up the connection in one go.
>
> It is also slightly better, if you accept (and we haven't discussed
this
> yet) that the choice of route can be influenced by the requested QoS.
If the
> user has marked 1 (above) you might route differently to 2 or 3, as an
> alternative to just failing the connection.
>
> Dick
>
>
> -----Original Message-----
> From: Giuseppe Bianchi [mailto:bianchi@morgana.elet.polimi.it]
> Sent: 18 January 2002 13:36
> To: dick.rr.knight@bt.com; blefari
> Cc: nsis@ietf.org
> Subject: RE: [NSIS] Two kinds of requirements (unsupported domains +
> chick en and eggs)
>
>
>
> Extending Dick's comment:
>
> On Fri, 18 Jan 2002 dick.rr.knight@bt.com wrote:
> > [...]
> > The protocol reaches a node at the edge of a domain/network
(aneveryedge
> > node) and knows that the best routing from here is through a chunk
of
> > besteffort (the routing tables tell it so). The node needs to decide
> whether
> > or not to progress or to refuse. This gives us a requirement on the
> > protocol: we need to include a class that says "I'd rather get my
comms
> link
> > up with a reduced QoS than get a refusal". We also need a class that
says
> > "don't down downgrade me" or "don't down downgrade me below
[classX]". If
> it
> > does progress across this network domain, we can still signal into
the
> next
> > NSIS-aware domain (as I am hoping the domain without support can
still
> route
> > packets).
> > Note: Best effort means that there are no guarantees because NSIS is
not
> > supported. It might be overprovisioned and providing a superior
service,
> but
> > it doesn't have a CAC.
>
> Why leaving this decision up to the node? An alternative (which may
> actually coexist with Dick's idea) is to use a form of marking, and
take
> back to the user the information that one domain along the path is
Best
> Effort... Depending on its requirements, the user will know whether to
> progress or to refuse.
>
> On a more general point of view, and in the spirit of the Internet,
I'd
> recommend to keep as much as possible the intelligence at the edge of
the
> network. In this sense, NSIS should be designed as a protocol that
allows
> end nodes to discover the state of the nodes/domains along the path
and to
> react accordingly.
>
> To make a simple example: I need to set up a call with some
requirements.
> I (or my access router) send an NSIS signalling packet including some
form
> of specifications & requirements. This packet is locally handled by
each
> network node (domain) as follow: if the node (domain) can guarantee
the
> reqs, it just forwards the NSIS packet along; If it cannot guarantee
the
> reqs, but it can accept the request with some downgraded form of of
> support, it marks the packet; if, finally, it cannot accept the
request,
> it just says no (by, e.g. suitably marking the NSIS packet, or, as we
> suggested in an earlier internet draft to make this idea compatible
with
> DiffServ domains, blocking it - timeouts at the end points will do the
> rest). When the NSIS signalling packet gets back to the sender, it
> contains all the relevant information to proceed.
>
> Giuseppe Bianchi
> bianchi@elet.polimi.it
> http://cerbero.elet.polimi.it/people/bianchi
>


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

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

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



From daemon@optimus.ietf.org  Fri Jan 18 12:08: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 MAA19066
	for <nsis-archive@odin.ietf.org>; Fri, 18 Jan 2002 12:08:12 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id MAA24574
	for nsis-archive@odin.ietf.org; Fri, 18 Jan 2002 12:08: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 LAA22412;
	Fri, 18 Jan 2002 11:55: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 LAA22377
	for <nsis@optimus.ietf.org>; Fri, 18 Jan 2002 11:55:36 -0500 (EST)
Received: from cbibipnt08.hc.bt.com (saturn.bt.com [193.113.57.20])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18581
	for <nsis@ietf.org>; Fri, 18 Jan 2002 11:55:31 -0500 (EST)
From: dick.rr.knight@bt.com
Received: by cbibipnt08.hc.bt.com with Internet Mail Service (5.5.2654.89)
	id <DA1W4TKG>; Fri, 18 Jan 2002 16:42:42 -0000
Message-ID: <451D45016C2CD2119DA50000F8FE7F07080E5A44@mlngcbnt01.hc.bt.com>
To: rrroy@att.com, dick.rr.knight@bt.com, Hemant.Chaskar@nokia.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements
Date: Fri, 18 Jan 2002 16:42:38 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2654.89)
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


I agree. Except that we ought not to state the conclusion until we have done
the work. (I mean we write the requirements and then see if any of these
things fit. If we can convince ourselves, the IESG and the rest of the world
that they don't fit, *then* we invent a new protocol).

I see now how SDPng and RFC2998 are relvant. I was reading the latter and
puzzling it. Thanks Roy.

-----Original Message-----
From: Roy, Radhika R, ALASO [mailto:rrroy@att.com]
Sent: 18 January 2002 14:52
To: dick.rr.knight; Hemant.Chaskar
Cc: nsis
Subject: RE: [NSIS] Two kinds of requirements


Hi, Dick:

You probably did not get my points. SDPng has used some QOS parameters for
audio, video, and data. These parameters need to be examined for our NSIS
works.

There is another aspect of SDPng: QOS parameters are sent on end-to-end
basis using a signaling protocol (e.g., SIP). This notion of end-to-end
communications is also needed in NSIS.

All I have pointed out is to examine all aspects SDPng to find out how NSIS
QOS can be developed examining the SDPng. In the same token, we can also
examine RFC 2998 and others.

Examining SDPng, RFC 2998, RSVP, and other proposals will be advancing our
understanding so that we can develop the NSIS QOS satisfying all the needs.

You are right when you say we should NOT concentrate only on those things
because we need to develop our own NSIS QOS protocol.

Best regards,

Radhika R. Roy
rrroy@att.com

-----Original Message-----
From: dick.rr.knight@bt.com [mailto:dick.rr.knight@bt.com]
Sent: Friday, January 18, 2002 7:21 AM
To: Hemant.Chaskar@nokia.com; Roy, Radhika R, ALASO
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


I don't think SDP (ng or otherwise) is a good starting point.

SDP is really a media description and is therefore application specific.

I have suggested (and seem to have seen quite a lot of support) a generic
mechanism that is agnostic on transport technology, QoS mechansim,
application and call/session protocol.

Dick

-----Original Message-----
From: Chaskar Hemant (NRC/Boston) [mailto:Hemant.Chaskar@nokia.com]
Sent: 16 January 2002 16:45
To: 'ext Roy, Radhika R, ALASO'
Cc: nsis
Subject: RE: [NSIS] Two kinds of requirements


Hi Radhika:

Just one comment below [HC].

--------------------------------------snip------------------------------
-----------------
[RRR] The thing that we need to do is to develop the end-to-end
application layer QOS signaling protocol. This will only deal with the
universal QOS characteristics of the application.

[HC] The easiest way to do this is to look at SDPng which is XML based,
and hence, will easily provide containers for the application QoS
parameters.

Hemant

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

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

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



From daemon@optimus.ietf.org  Fri Jan 18 12:26: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 MAA19685
	for <nsis-archive@odin.ietf.org>; Fri, 18 Jan 2002 12:26:39 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id MAA25104
	for nsis-archive@odin.ietf.org; Fri, 18 Jan 2002 12:26: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 MAA24026;
	Fri, 18 Jan 2002 12:01: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 MAA23997
	for <nsis@optimus.ietf.org>; Fri, 18 Jan 2002 12:01:45 -0500 (EST)
Received: from cbibipnt05.hc.bt.com (saturn.bt.com [193.113.57.20])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18789
	for <nsis@ietf.org>; Fri, 18 Jan 2002 12:01:40 -0500 (EST)
From: dick.rr.knight@bt.com
Received: by cbibipnt05.hc.bt.com with Internet Mail Service (5.5.2652.35)
	id <DA1VTQB2>; Fri, 18 Jan 2002 16:51:22 -0000
Message-ID: <451D45016C2CD2119DA50000F8FE7F07080E5A46@mlngcbnt01.hc.bt.com>
To: gilbert@rsch.comm.mot.com, nsis@ietf.org
Subject: RE: [NSIS] Support needed for Throughput Adaptive QoS in wireless
Date: Fri, 18 Jan 2002 16:51:07 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
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


There are some important points in this email. Probably obvious for people
with wireless backgrounds, but a bit more of a surprise for wired
backgrounds.

I personally don't see NSIS as trying to solve the rate adaptation needs of
the wireless access network. I can see that it is very much needed, but it
is rather more specialised than a generic signalling protocol for QoS
requests. This looks like a charter debate.

The wireless access network definitely needs some QoS signalling support,
but as you have shown, it is specific to the technology and the mobility
service.

Dick

-----Original Message-----
From: Steve Gilbert [mailto:gilbert@rsch.comm.mot.com]
Sent: 18 January 2002 16:21
To: nsis@ietf.org
Subject: [NSIS] Support needed for Throughput Adaptive QoS in wireless




I tend to agree with the need which Herman identifies (below) for throughput
adaptive capabilities in a wireless QoS system.

The cellular wireless QoS problem is very different than that of wired QoS
because of the need to handle the case of a user with a QoS "guarantee"
handing
off into a different cell.  In the worst case, the cell which it is entering
may
have its resources fully allocated to existing users. Dropping the session
of
the user being handed off is not a good idea. This points out the need for
some
rational way to accommodate such calls. The approach taken in some wireless
voice systems is to reserve resources for use only by sessions which are
handing
off into the cell. This may suffice if the resource needs of the hand off
session are predictable. However, in a system in which arbitrary
applications
can utilize a wide range of throughput values, reserving enough capacity to
handle the range of throughputs which could potentially be needed by a
single
flow may not be practical.

What is needed is the use of throughput adaptive applications and the
ability
for a traffic flow to express its QoS preferences with regard to the
throughput
values which it may be allocated. Upon handing off into the new cell, the
QoS
preferences of the handoff traffic flow and of the existing traffic flows in
that cell would be considered and resources reallocated to best meet their
preferences. Some of the existing traffic flows may have their throughput
allocations reduced in order to free up resources to be allocated to the
handoff
traffic flow.

The QoS signaling needs of this approach include the ability of the system
to
notify traffic flows of their new allocations, and the ability for a new
traffic
flow requesting "admission" to express its QoS preferences, possibly in
terms of
a list of throughput values and the benefit it receives from each. A
non-adaptive real-time application would indicate a single throughput value
which it desires rather than a list of throughput values.

One could argue that this provides no throughput "guarantee" and changes
what it
means to have a QoS request "admitted". This is true. But in wireless, it is
difficult and sometimes impractical to provide the same QoS guarantees that
could be provided in a wireline system which doesn't have to deal with
handoff. In a wireless system, there is the possibility that the user will
drive
into a tunnel or take the elevator to a sub-basement of a building where the
wireless signal is lost. Radio coverage and QoS can not be guaranteed under
all
possible situations.  Wireless channel resources are often more scarce or
expensive than those of a wired channel. This generally results in the
motivation to utilize them more efficiently. What is more realistic than
trying
to provide wireless QoS identical to that of wire-line is to come up with a
useful approach for "QoS management" and "resource allocation" which can be
applied in a wireless system.

If efficient utilization of the resources by QoS flows is not a major
concern,
the QoS of admitted users could be increased (or at least made less prone to
reductions) through over-provisioning or preventing admission of new calls
even
when the level of congestion is still low. The resources not guaranteed to
QoS
traffic flows could be used by best effort traffic. Systems with significant
best effort traffic would be able to increase the overall utilization of the
channel without negatively effecting QoS traffic flows.

Steve



> Date: Thu, 17 Jan 2002 19:49:13 +0000
> To: "Georgios Karagiannis (ELN)" <Georgios.Karagiannis@eln.ericsson.se>,
>    "'Loughney John (NRC/Helsinki)'" <john.loughney@nokia.com>,
>    "'ext Kappler Cornelia'" <Cornelia.Kappler@icn.siemens.de>
> From: Hermann De Meer <h.demeer@ee.ucl.ac.uk>
> Cc: <nsis@ietf.org>
> Subject: RE: [NSIS] Two kinds of requirements
> 
> Hi Georgios and all
> 
> At 14:09 17/01/2002 +0100, Georgios Karagiannis (ELN) wrote:
> >Hi John and Cornelia
> >
> >I think that one of the requirements that should be included
> >in the NSIS WG requirements document is that the NSIS protocol
> >should be modular. Modular in the context of having
> >a toolkit from which one can choose the applicable tools
> >in order to manage QoS in a particular networking environment.
> 
> I believe you are raising a very important issue with the emphasis on 
> modularity
> of QoS architectures/signalling.
> 
> But one can generalize that: it's all about flexibility,
> namely flexibility of signalling/control/provisioning vs. flexibility of 
> applications/users.
> 
> Flexibility does not necessarily mean complexity, often on the contrary:
> one side being flexible makes the life for the other side easier (think of

> airline ticket pricing:
> the price for the *same seat* can vary in an order of magnitude simply
> depending on how flexible you are!)
> 
> QoS signalling is about indicating of how "inflexible" you are from that 
> perspective.
> But looking at IntServ (RSVP) or DiffServ,  an interpretation of these
signals
> have traditionally been seen rather statically:
> 
> - a "one-size-fits-all"  "end-to-end" implementation of the mechanisms
> - a "take-it-or-leave-it" approach: statically defined QoS classes.
> 
> this makes QoS provisioning cumbersome, complex, expensive (unnecessarily)
> (and it may be a good deal the reason for the "failure/insufficiency" of 
> current QoS solutions/
> signalling techniques).
> 
> Remember, the success of IP networking has to a larger extend been due to 
> the fact of
> relying on flexibility and cooperation, for example, for congestion
handling.
> (or "exception" handling, if you want, by TCP-similar schemes)
> 
> in <draft-demeer-nsis-analyis-00.txt> we therefore make a point to extend 
> QoS signalling for:
> 
> 1) explicitly dealing with such "QoS exceptions" (there is also an
economic 
> argument for this)
>      that is, not only signaling QoS preferences from applications to the 
> network, but also
>      QoS exceptions back from networks to applications or to between
networks,
>      and an expected cooperative adaptation.
> 
> 2) allowing for flexible interpretations in different domains (core, 
> access, mobile, wireless,
>       administrative conditions, ....)
> 
> 
> The "trick" may be to modify signalling (including RSVP) such that most 
> flexibility/cooperation
> can be re-gained by assuring a minimum support of inflexibility 
> (intentionally not using the
> the term QoS guarantee here).
> 
> 
> --Hermann
> 
...

_______________________________________________
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 Jan 18 12:51: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 MAA20712
	for <nsis-archive@odin.ietf.org>; Fri, 18 Jan 2002 12:51:03 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id MAA26348
	for nsis-archive@odin.ietf.org; Fri, 18 Jan 2002 12:51: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 MAA25831;
	Fri, 18 Jan 2002 12:31:58 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA25759
	for <nsis@optimus.ietf.org>; Fri, 18 Jan 2002 12:31:54 -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 MAA19884
	for <nsis@ietf.org>; Fri, 18 Jan 2002 12:31:49 -0500 (EST)
Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56])
	by zcars0m9.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g0IHVLf29190;
	Fri, 18 Jan 2002 12:31:21 -0500 (EST)
Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7])
	by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g0IHVIO18723;
	Fri, 18 Jan 2002 12:31:18 -0500 (EST)
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19)
	id <C8PZWPKH>; Fri, 18 Jan 2002 12:31:19 -0500
Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA478B@zcard031.ca.nortel.com>
From: "Gary Kenward"<gkenward@nortelnetworks.com>
To: "'dick.rr.knight@bt.com'" <dick.rr.knight@bt.com>,
        gilbert@rsch.comm.mot.com, nsis@ietf.org
Subject: RE: [NSIS] Support needed for Throughput Adaptive QoS in wireless
Date: Fri, 18 Jan 2002 12:31:17 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C1A045.EF7BF370"
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_01C1A045.EF7BF370
Content-Type: text/plain;
	charset="ISO-8859-1"

Steve:

  I don't believe that Dick is proposing that NSIS accomodate 
rate adaption, I believe that the issue is QoS re-negotiation 
to allow better handoff performance.
 
  The situation is simply that if the admission control used
during a handoff is "all or nothing" then the likelihood the
flows of the mobile user will be dropped when a handoff occurs is 
much higher. "Re-negotiation" of QoS allows the network to reduce
the resource demands to the point that the new access router 
can handle the flows, at least to some degree.

  Re-negotiation can mean many different solution scenarios.
At the extremes, the solution could be an NSIS negotiation 
protocol between mobile and access network; a "minimum" QoS 
that the network that is allowed as a fallback to allow the 
handoff to occur. Note that in either case, the result may
mean dropping of specific flows that cannot be support (e.g.
the video portion of a multimedia session).

The second scenario does not necessarly require interaction 
with the mobile or other networks and thus may
not impact NSIS.  However, it might be a good thing for the
network to tell the mobile that the QoS had been degraded,
thus allowing the mobile application to "adapt". NSIS does not
need to participate in the adaption, it would simply provide
the information on the new QoS.

I think the requirement here is for the NSIS wg to consider
all the options.

Gary


> -----Original Message-----
> From: dick.rr.knight@bt.com [mailto:dick.rr.knight@bt.com]
> Sent: January 18, 2002 11:51
> To: gilbert@rsch.comm.mot.com; nsis@ietf.org
> Subject: RE: [NSIS] Support needed for Throughput Adaptive QoS in
> wireless
> 
> 
> 
> There are some important points in this email. Probably 
> obvious for people
> with wireless backgrounds, but a bit more of a surprise for wired
> backgrounds.
> 
> I personally don't see NSIS as trying to solve the rate 
> adaptation needs of
> the wireless access network. I can see that it is very much 
> needed, but it
> is rather more specialised than a generic signalling protocol for QoS
> requests. This looks like a charter debate.
> 
> The wireless access network definitely needs some QoS 
> signalling support,
> but as you have shown, it is specific to the technology and 
> the mobility
> service.
> 
> Dick
> 
> -----Original Message-----
> From: Steve Gilbert [mailto:gilbert@rsch.comm.mot.com]
> Sent: 18 January 2002 16:21
> To: nsis@ietf.org
> Subject: [NSIS] Support needed for Throughput Adaptive QoS in wireless
> 
> 
> 
> 
> I tend to agree with the need which Herman identifies (below) 
> for throughput
> adaptive capabilities in a wireless QoS system.
> 
> The cellular wireless QoS problem is very different than that 
> of wired QoS
> because of the need to handle the case of a user with a QoS 
> "guarantee"
> handing
> off into a different cell.  In the worst case, the cell which 
> it is entering
> may
> have its resources fully allocated to existing users. 
> Dropping the session
> of
> the user being handed off is not a good idea. This points out 
> the need for
> some
> rational way to accommodate such calls. The approach taken in 
> some wireless
> voice systems is to reserve resources for use only by 
> sessions which are
> handing
> off into the cell. This may suffice if the resource needs of 
> the hand off
> session are predictable. However, in a system in which arbitrary
> applications
> can utilize a wide range of throughput values, reserving 
> enough capacity to
> handle the range of throughputs which could potentially be needed by a
> single
> flow may not be practical.
> 
> What is needed is the use of throughput adaptive applications and the
> ability
> for a traffic flow to express its QoS preferences with regard to the
> throughput
> values which it may be allocated. Upon handing off into the 
> new cell, the
> QoS
> preferences of the handoff traffic flow and of the existing 
> traffic flows in
> that cell would be considered and resources reallocated to 
> best meet their
> preferences. Some of the existing traffic flows may have 
> their throughput
> allocations reduced in order to free up resources to be 
> allocated to the
> handoff
> traffic flow.
> 
> The QoS signaling needs of this approach include the ability 
> of the system
> to
> notify traffic flows of their new allocations, and the 
> ability for a new
> traffic
> flow requesting "admission" to express its QoS preferences, 
> possibly in
> terms of
> a list of throughput values and the benefit it receives from each. A
> non-adaptive real-time application would indicate a single 
> throughput value
> which it desires rather than a list of throughput values.
> 
> One could argue that this provides no throughput "guarantee" 
> and changes
> what it
> means to have a QoS request "admitted". This is true. But in 
> wireless, it is
> difficult and sometimes impractical to provide the same QoS 
> guarantees that
> could be provided in a wireline system which doesn't have to deal with
> handoff. In a wireless system, there is the possibility that 
> the user will
> drive
> into a tunnel or take the elevator to a sub-basement of a 
> building where the
> wireless signal is lost. Radio coverage and QoS can not be 
> guaranteed under
> all
> possible situations.  Wireless channel resources are often 
> more scarce or
> expensive than those of a wired channel. This generally results in the
> motivation to utilize them more efficiently. What is more 
> realistic than
> trying
> to provide wireless QoS identical to that of wire-line is to 
> come up with a
> useful approach for "QoS management" and "resource 
> allocation" which can be
> applied in a wireless system.
> 
> If efficient utilization of the resources by QoS flows is not a major
> concern,
> the QoS of admitted users could be increased (or at least 
> made less prone to
> reductions) through over-provisioning or preventing admission 
> of new calls
> even
> when the level of congestion is still low. The resources not 
> guaranteed to
> QoS
> traffic flows could be used by best effort traffic. Systems 
> with significant
> best effort traffic would be able to increase the overall 
> utilization of the
> channel without negatively effecting QoS traffic flows.
> 
> Steve
> 
> 
> 
> > Date: Thu, 17 Jan 2002 19:49:13 +0000
> > To: "Georgios Karagiannis (ELN)" 
> <Georgios.Karagiannis@eln.ericsson.se>,
> >    "'Loughney John (NRC/Helsinki)'" <john.loughney@nokia.com>,
> >    "'ext Kappler Cornelia'" <Cornelia.Kappler@icn.siemens.de>
> > From: Hermann De Meer <h.demeer@ee.ucl.ac.uk>
> > Cc: <nsis@ietf.org>
> > Subject: RE: [NSIS] Two kinds of requirements
> > 
> > Hi Georgios and all
> > 
> > At 14:09 17/01/2002 +0100, Georgios Karagiannis (ELN) wrote:
> > >Hi John and Cornelia
> > >
> > >I think that one of the requirements that should be included
> > >in the NSIS WG requirements document is that the NSIS protocol
> > >should be modular. Modular in the context of having
> > >a toolkit from which one can choose the applicable tools
> > >in order to manage QoS in a particular networking environment.
> > 
> > I believe you are raising a very important issue with the 
> emphasis on 
> > modularity
> > of QoS architectures/signalling.
> > 
> > But one can generalize that: it's all about flexibility,
> > namely flexibility of signalling/control/provisioning vs. 
> flexibility of 
> > applications/users.
> > 
> > Flexibility does not necessarily mean complexity, often on 
> the contrary:
> > one side being flexible makes the life for the other side 
> easier (think of
> 
> > airline ticket pricing:
> > the price for the *same seat* can vary in an order of 
> magnitude simply
> > depending on how flexible you are!)
> > 
> > QoS signalling is about indicating of how "inflexible" you 
> are from that 
> > perspective.
> > But looking at IntServ (RSVP) or DiffServ,  an 
> interpretation of these
> signals
> > have traditionally been seen rather statically:
> > 
> > - a "one-size-fits-all"  "end-to-end" implementation of the 
> mechanisms
> > - a "take-it-or-leave-it" approach: statically defined QoS classes.
> > 
> > this makes QoS provisioning cumbersome, complex, expensive 
> (unnecessarily)
> > (and it may be a good deal the reason for the 
> "failure/insufficiency" of 
> > current QoS solutions/
> > signalling techniques).
> > 
> > Remember, the success of IP networking has to a larger 
> extend been due to 
> > the fact of
> > relying on flexibility and cooperation, for example, for congestion
> handling.
> > (or "exception" handling, if you want, by TCP-similar schemes)
> > 
> > in <draft-demeer-nsis-analyis-00.txt> we therefore make a 
> point to extend 
> > QoS signalling for:
> > 
> > 1) explicitly dealing with such "QoS exceptions" (there is also an
> economic 
> > argument for this)
> >      that is, not only signaling QoS preferences from 
> applications to the 
> > network, but also
> >      QoS exceptions back from networks to applications or to between
> networks,
> >      and an expected cooperative adaptation.
> > 
> > 2) allowing for flexible interpretations in different 
> domains (core, 
> > access, mobile, wireless,
> >       administrative conditions, ....)
> > 
> > 
> > The "trick" may be to modify signalling (including RSVP) 
> such that most 
> > flexibility/cooperation
> > can be re-gained by assuring a minimum support of inflexibility 
> > (intentionally not using the
> > the term QoS guarantee here).
> > 
> > 
> > --Hermann
> > 
> ...
> 
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis
> 
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis
> 

------_=_NextPart_001_01C1A045.EF7BF370
Content-Type: text/html;
	charset="ISO-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2654.89">
<TITLE>RE: [NSIS] Support needed for Throughput Adaptive QoS in wireless</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Steve:</FONT>
</P>

<P><FONT SIZE=2>&nbsp; I don't believe that Dick is proposing that NSIS accomodate </FONT>
<BR><FONT SIZE=2>rate adaption, I believe that the issue is QoS re-negotiation </FONT>
<BR><FONT SIZE=2>to allow better handoff performance.</FONT>
<BR><FONT SIZE=2>&nbsp;</FONT>
<BR><FONT SIZE=2>&nbsp; The situation is simply that if the admission control used</FONT>
<BR><FONT SIZE=2>during a handoff is &quot;all or nothing&quot; then the likelihood the</FONT>
<BR><FONT SIZE=2>flows of the mobile user will be dropped when a handoff occurs is </FONT>
<BR><FONT SIZE=2>much higher. &quot;Re-negotiation&quot; of QoS allows the network to reduce</FONT>
<BR><FONT SIZE=2>the resource demands to the point that the new access router </FONT>
<BR><FONT SIZE=2>can handle the flows, at least to some degree.</FONT>
</P>

<P><FONT SIZE=2>&nbsp; Re-negotiation can mean many different solution scenarios.</FONT>
<BR><FONT SIZE=2>At the extremes, the solution could be an NSIS negotiation </FONT>
<BR><FONT SIZE=2>protocol between mobile and access network; a &quot;minimum&quot; QoS </FONT>
<BR><FONT SIZE=2>that the network that is allowed as a fallback to allow the </FONT>
<BR><FONT SIZE=2>handoff to occur. Note that in either case, the result may</FONT>
<BR><FONT SIZE=2>mean dropping of specific flows that cannot be support (e.g.</FONT>
<BR><FONT SIZE=2>the video portion of a multimedia session).</FONT>
</P>

<P><FONT SIZE=2>The second scenario does not necessarly require interaction </FONT>
<BR><FONT SIZE=2>with the mobile or other networks and thus may</FONT>
<BR><FONT SIZE=2>not impact NSIS.&nbsp; However, it might be a good thing for the</FONT>
<BR><FONT SIZE=2>network to tell the mobile that the QoS had been degraded,</FONT>
<BR><FONT SIZE=2>thus allowing the mobile application to &quot;adapt&quot;. NSIS does not</FONT>
<BR><FONT SIZE=2>need to participate in the adaption, it would simply provide</FONT>
<BR><FONT SIZE=2>the information on the new QoS.</FONT>
</P>

<P><FONT SIZE=2>I think the requirement here is for the NSIS wg to consider</FONT>
<BR><FONT SIZE=2>all the options.</FONT>
</P>

<P><FONT SIZE=2>Gary</FONT>
</P>
<BR>

<P><FONT SIZE=2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; From: dick.rr.knight@bt.com [<A HREF="mailto:dick.rr.knight@bt.com">mailto:dick.rr.knight@bt.com</A>]</FONT>
<BR><FONT SIZE=2>&gt; Sent: January 18, 2002 11:51</FONT>
<BR><FONT SIZE=2>&gt; To: gilbert@rsch.comm.mot.com; nsis@ietf.org</FONT>
<BR><FONT SIZE=2>&gt; Subject: RE: [NSIS] Support needed for Throughput Adaptive QoS in</FONT>
<BR><FONT SIZE=2>&gt; wireless</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; There are some important points in this email. Probably </FONT>
<BR><FONT SIZE=2>&gt; obvious for people</FONT>
<BR><FONT SIZE=2>&gt; with wireless backgrounds, but a bit more of a surprise for wired</FONT>
<BR><FONT SIZE=2>&gt; backgrounds.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; I personally don't see NSIS as trying to solve the rate </FONT>
<BR><FONT SIZE=2>&gt; adaptation needs of</FONT>
<BR><FONT SIZE=2>&gt; the wireless access network. I can see that it is very much </FONT>
<BR><FONT SIZE=2>&gt; needed, but it</FONT>
<BR><FONT SIZE=2>&gt; is rather more specialised than a generic signalling protocol for QoS</FONT>
<BR><FONT SIZE=2>&gt; requests. This looks like a charter debate.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; The wireless access network definitely needs some QoS </FONT>
<BR><FONT SIZE=2>&gt; signalling support,</FONT>
<BR><FONT SIZE=2>&gt; but as you have shown, it is specific to the technology and </FONT>
<BR><FONT SIZE=2>&gt; the mobility</FONT>
<BR><FONT SIZE=2>&gt; service.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Dick</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; From: Steve Gilbert [<A HREF="mailto:gilbert@rsch.comm.mot.com">mailto:gilbert@rsch.comm.mot.com</A>]</FONT>
<BR><FONT SIZE=2>&gt; Sent: 18 January 2002 16:21</FONT>
<BR><FONT SIZE=2>&gt; To: nsis@ietf.org</FONT>
<BR><FONT SIZE=2>&gt; Subject: [NSIS] Support needed for Throughput Adaptive QoS in wireless</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; I tend to agree with the need which Herman identifies (below) </FONT>
<BR><FONT SIZE=2>&gt; for throughput</FONT>
<BR><FONT SIZE=2>&gt; adaptive capabilities in a wireless QoS system.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; The cellular wireless QoS problem is very different than that </FONT>
<BR><FONT SIZE=2>&gt; of wired QoS</FONT>
<BR><FONT SIZE=2>&gt; because of the need to handle the case of a user with a QoS </FONT>
<BR><FONT SIZE=2>&gt; &quot;guarantee&quot;</FONT>
<BR><FONT SIZE=2>&gt; handing</FONT>
<BR><FONT SIZE=2>&gt; off into a different cell.&nbsp; In the worst case, the cell which </FONT>
<BR><FONT SIZE=2>&gt; it is entering</FONT>
<BR><FONT SIZE=2>&gt; may</FONT>
<BR><FONT SIZE=2>&gt; have its resources fully allocated to existing users. </FONT>
<BR><FONT SIZE=2>&gt; Dropping the session</FONT>
<BR><FONT SIZE=2>&gt; of</FONT>
<BR><FONT SIZE=2>&gt; the user being handed off is not a good idea. This points out </FONT>
<BR><FONT SIZE=2>&gt; the need for</FONT>
<BR><FONT SIZE=2>&gt; some</FONT>
<BR><FONT SIZE=2>&gt; rational way to accommodate such calls. The approach taken in </FONT>
<BR><FONT SIZE=2>&gt; some wireless</FONT>
<BR><FONT SIZE=2>&gt; voice systems is to reserve resources for use only by </FONT>
<BR><FONT SIZE=2>&gt; sessions which are</FONT>
<BR><FONT SIZE=2>&gt; handing</FONT>
<BR><FONT SIZE=2>&gt; off into the cell. This may suffice if the resource needs of </FONT>
<BR><FONT SIZE=2>&gt; the hand off</FONT>
<BR><FONT SIZE=2>&gt; session are predictable. However, in a system in which arbitrary</FONT>
<BR><FONT SIZE=2>&gt; applications</FONT>
<BR><FONT SIZE=2>&gt; can utilize a wide range of throughput values, reserving </FONT>
<BR><FONT SIZE=2>&gt; enough capacity to</FONT>
<BR><FONT SIZE=2>&gt; handle the range of throughputs which could potentially be needed by a</FONT>
<BR><FONT SIZE=2>&gt; single</FONT>
<BR><FONT SIZE=2>&gt; flow may not be practical.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; What is needed is the use of throughput adaptive applications and the</FONT>
<BR><FONT SIZE=2>&gt; ability</FONT>
<BR><FONT SIZE=2>&gt; for a traffic flow to express its QoS preferences with regard to the</FONT>
<BR><FONT SIZE=2>&gt; throughput</FONT>
<BR><FONT SIZE=2>&gt; values which it may be allocated. Upon handing off into the </FONT>
<BR><FONT SIZE=2>&gt; new cell, the</FONT>
<BR><FONT SIZE=2>&gt; QoS</FONT>
<BR><FONT SIZE=2>&gt; preferences of the handoff traffic flow and of the existing </FONT>
<BR><FONT SIZE=2>&gt; traffic flows in</FONT>
<BR><FONT SIZE=2>&gt; that cell would be considered and resources reallocated to </FONT>
<BR><FONT SIZE=2>&gt; best meet their</FONT>
<BR><FONT SIZE=2>&gt; preferences. Some of the existing traffic flows may have </FONT>
<BR><FONT SIZE=2>&gt; their throughput</FONT>
<BR><FONT SIZE=2>&gt; allocations reduced in order to free up resources to be </FONT>
<BR><FONT SIZE=2>&gt; allocated to the</FONT>
<BR><FONT SIZE=2>&gt; handoff</FONT>
<BR><FONT SIZE=2>&gt; traffic flow.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; The QoS signaling needs of this approach include the ability </FONT>
<BR><FONT SIZE=2>&gt; of the system</FONT>
<BR><FONT SIZE=2>&gt; to</FONT>
<BR><FONT SIZE=2>&gt; notify traffic flows of their new allocations, and the </FONT>
<BR><FONT SIZE=2>&gt; ability for a new</FONT>
<BR><FONT SIZE=2>&gt; traffic</FONT>
<BR><FONT SIZE=2>&gt; flow requesting &quot;admission&quot; to express its QoS preferences, </FONT>
<BR><FONT SIZE=2>&gt; possibly in</FONT>
<BR><FONT SIZE=2>&gt; terms of</FONT>
<BR><FONT SIZE=2>&gt; a list of throughput values and the benefit it receives from each. A</FONT>
<BR><FONT SIZE=2>&gt; non-adaptive real-time application would indicate a single </FONT>
<BR><FONT SIZE=2>&gt; throughput value</FONT>
<BR><FONT SIZE=2>&gt; which it desires rather than a list of throughput values.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; One could argue that this provides no throughput &quot;guarantee&quot; </FONT>
<BR><FONT SIZE=2>&gt; and changes</FONT>
<BR><FONT SIZE=2>&gt; what it</FONT>
<BR><FONT SIZE=2>&gt; means to have a QoS request &quot;admitted&quot;. This is true. But in </FONT>
<BR><FONT SIZE=2>&gt; wireless, it is</FONT>
<BR><FONT SIZE=2>&gt; difficult and sometimes impractical to provide the same QoS </FONT>
<BR><FONT SIZE=2>&gt; guarantees that</FONT>
<BR><FONT SIZE=2>&gt; could be provided in a wireline system which doesn't have to deal with</FONT>
<BR><FONT SIZE=2>&gt; handoff. In a wireless system, there is the possibility that </FONT>
<BR><FONT SIZE=2>&gt; the user will</FONT>
<BR><FONT SIZE=2>&gt; drive</FONT>
<BR><FONT SIZE=2>&gt; into a tunnel or take the elevator to a sub-basement of a </FONT>
<BR><FONT SIZE=2>&gt; building where the</FONT>
<BR><FONT SIZE=2>&gt; wireless signal is lost. Radio coverage and QoS can not be </FONT>
<BR><FONT SIZE=2>&gt; guaranteed under</FONT>
<BR><FONT SIZE=2>&gt; all</FONT>
<BR><FONT SIZE=2>&gt; possible situations.&nbsp; Wireless channel resources are often </FONT>
<BR><FONT SIZE=2>&gt; more scarce or</FONT>
<BR><FONT SIZE=2>&gt; expensive than those of a wired channel. This generally results in the</FONT>
<BR><FONT SIZE=2>&gt; motivation to utilize them more efficiently. What is more </FONT>
<BR><FONT SIZE=2>&gt; realistic than</FONT>
<BR><FONT SIZE=2>&gt; trying</FONT>
<BR><FONT SIZE=2>&gt; to provide wireless QoS identical to that of wire-line is to </FONT>
<BR><FONT SIZE=2>&gt; come up with a</FONT>
<BR><FONT SIZE=2>&gt; useful approach for &quot;QoS management&quot; and &quot;resource </FONT>
<BR><FONT SIZE=2>&gt; allocation&quot; which can be</FONT>
<BR><FONT SIZE=2>&gt; applied in a wireless system.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; If efficient utilization of the resources by QoS flows is not a major</FONT>
<BR><FONT SIZE=2>&gt; concern,</FONT>
<BR><FONT SIZE=2>&gt; the QoS of admitted users could be increased (or at least </FONT>
<BR><FONT SIZE=2>&gt; made less prone to</FONT>
<BR><FONT SIZE=2>&gt; reductions) through over-provisioning or preventing admission </FONT>
<BR><FONT SIZE=2>&gt; of new calls</FONT>
<BR><FONT SIZE=2>&gt; even</FONT>
<BR><FONT SIZE=2>&gt; when the level of congestion is still low. The resources not </FONT>
<BR><FONT SIZE=2>&gt; guaranteed to</FONT>
<BR><FONT SIZE=2>&gt; QoS</FONT>
<BR><FONT SIZE=2>&gt; traffic flows could be used by best effort traffic. Systems </FONT>
<BR><FONT SIZE=2>&gt; with significant</FONT>
<BR><FONT SIZE=2>&gt; best effort traffic would be able to increase the overall </FONT>
<BR><FONT SIZE=2>&gt; utilization of the</FONT>
<BR><FONT SIZE=2>&gt; channel without negatively effecting QoS traffic flows.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Steve</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; Date: Thu, 17 Jan 2002 19:49:13 +0000</FONT>
<BR><FONT SIZE=2>&gt; &gt; To: &quot;Georgios Karagiannis (ELN)&quot; </FONT>
<BR><FONT SIZE=2>&gt; &lt;Georgios.Karagiannis@eln.ericsson.se&gt;,</FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp; &quot;'Loughney John (NRC/Helsinki)'&quot; &lt;john.loughney@nokia.com&gt;,</FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp; &quot;'ext Kappler Cornelia'&quot; &lt;Cornelia.Kappler@icn.siemens.de&gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; From: Hermann De Meer &lt;h.demeer@ee.ucl.ac.uk&gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; Cc: &lt;nsis@ietf.org&gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; Subject: RE: [NSIS] Two kinds of requirements</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; Hi Georgios and all</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; At 14:09 17/01/2002 +0100, Georgios Karagiannis (ELN) wrote:</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;Hi John and Cornelia</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;I think that one of the requirements that should be included</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;in the NSIS WG requirements document is that the NSIS protocol</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;should be modular. Modular in the context of having</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;a toolkit from which one can choose the applicable tools</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;in order to manage QoS in a particular networking environment.</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; I believe you are raising a very important issue with the </FONT>
<BR><FONT SIZE=2>&gt; emphasis on </FONT>
<BR><FONT SIZE=2>&gt; &gt; modularity</FONT>
<BR><FONT SIZE=2>&gt; &gt; of QoS architectures/signalling.</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; But one can generalize that: it's all about flexibility,</FONT>
<BR><FONT SIZE=2>&gt; &gt; namely flexibility of signalling/control/provisioning vs. </FONT>
<BR><FONT SIZE=2>&gt; flexibility of </FONT>
<BR><FONT SIZE=2>&gt; &gt; applications/users.</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; Flexibility does not necessarily mean complexity, often on </FONT>
<BR><FONT SIZE=2>&gt; the contrary:</FONT>
<BR><FONT SIZE=2>&gt; &gt; one side being flexible makes the life for the other side </FONT>
<BR><FONT SIZE=2>&gt; easier (think of</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; airline ticket pricing:</FONT>
<BR><FONT SIZE=2>&gt; &gt; the price for the *same seat* can vary in an order of </FONT>
<BR><FONT SIZE=2>&gt; magnitude simply</FONT>
<BR><FONT SIZE=2>&gt; &gt; depending on how flexible you are!)</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; QoS signalling is about indicating of how &quot;inflexible&quot; you </FONT>
<BR><FONT SIZE=2>&gt; are from that </FONT>
<BR><FONT SIZE=2>&gt; &gt; perspective.</FONT>
<BR><FONT SIZE=2>&gt; &gt; But looking at IntServ (RSVP) or DiffServ,&nbsp; an </FONT>
<BR><FONT SIZE=2>&gt; interpretation of these</FONT>
<BR><FONT SIZE=2>&gt; signals</FONT>
<BR><FONT SIZE=2>&gt; &gt; have traditionally been seen rather statically:</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; - a &quot;one-size-fits-all&quot;&nbsp; &quot;end-to-end&quot; implementation of the </FONT>
<BR><FONT SIZE=2>&gt; mechanisms</FONT>
<BR><FONT SIZE=2>&gt; &gt; - a &quot;take-it-or-leave-it&quot; approach: statically defined QoS classes.</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; this makes QoS provisioning cumbersome, complex, expensive </FONT>
<BR><FONT SIZE=2>&gt; (unnecessarily)</FONT>
<BR><FONT SIZE=2>&gt; &gt; (and it may be a good deal the reason for the </FONT>
<BR><FONT SIZE=2>&gt; &quot;failure/insufficiency&quot; of </FONT>
<BR><FONT SIZE=2>&gt; &gt; current QoS solutions/</FONT>
<BR><FONT SIZE=2>&gt; &gt; signalling techniques).</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; Remember, the success of IP networking has to a larger </FONT>
<BR><FONT SIZE=2>&gt; extend been due to </FONT>
<BR><FONT SIZE=2>&gt; &gt; the fact of</FONT>
<BR><FONT SIZE=2>&gt; &gt; relying on flexibility and cooperation, for example, for congestion</FONT>
<BR><FONT SIZE=2>&gt; handling.</FONT>
<BR><FONT SIZE=2>&gt; &gt; (or &quot;exception&quot; handling, if you want, by TCP-similar schemes)</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; in &lt;draft-demeer-nsis-analyis-00.txt&gt; we therefore make a </FONT>
<BR><FONT SIZE=2>&gt; point to extend </FONT>
<BR><FONT SIZE=2>&gt; &gt; QoS signalling for:</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; 1) explicitly dealing with such &quot;QoS exceptions&quot; (there is also an</FONT>
<BR><FONT SIZE=2>&gt; economic </FONT>
<BR><FONT SIZE=2>&gt; &gt; argument for this)</FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; that is, not only signaling QoS preferences from </FONT>
<BR><FONT SIZE=2>&gt; applications to the </FONT>
<BR><FONT SIZE=2>&gt; &gt; network, but also</FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; QoS exceptions back from networks to applications or to between</FONT>
<BR><FONT SIZE=2>&gt; networks,</FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; and an expected cooperative adaptation.</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; 2) allowing for flexible interpretations in different </FONT>
<BR><FONT SIZE=2>&gt; domains (core, </FONT>
<BR><FONT SIZE=2>&gt; &gt; access, mobile, wireless,</FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; administrative conditions, ....)</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; The &quot;trick&quot; may be to modify signalling (including RSVP) </FONT>
<BR><FONT SIZE=2>&gt; such that most </FONT>
<BR><FONT SIZE=2>&gt; &gt; flexibility/cooperation</FONT>
<BR><FONT SIZE=2>&gt; &gt; can be re-gained by assuring a minimum support of inflexibility </FONT>
<BR><FONT SIZE=2>&gt; &gt; (intentionally not using the</FONT>
<BR><FONT SIZE=2>&gt; &gt; the term QoS guarantee here).</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; --Hermann</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; ...</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; _______________________________________________</FONT>
<BR><FONT SIZE=2>&gt; nsis mailing list</FONT>
<BR><FONT SIZE=2>&gt; nsis@ietf.org</FONT>
<BR><FONT SIZE=2>&gt; <A HREF="https://www1.ietf.org/mailman/listinfo/nsis" TARGET="_blank">https://www1.ietf.org/mailman/listinfo/nsis</A></FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; _______________________________________________</FONT>
<BR><FONT SIZE=2>&gt; nsis mailing list</FONT>
<BR><FONT SIZE=2>&gt; nsis@ietf.org</FONT>
<BR><FONT SIZE=2>&gt; <A HREF="https://www1.ietf.org/mailman/listinfo/nsis" TARGET="_blank">https://www1.ietf.org/mailman/listinfo/nsis</A></FONT>
<BR><FONT SIZE=2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1A045.EF7BF370--

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



From daemon@optimus.ietf.org  Fri Jan 18 13:11: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 NAA21521
	for <nsis-archive@odin.ietf.org>; Fri, 18 Jan 2002 13:11:05 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id NAA27227
	for nsis-archive@odin.ietf.org; Fri, 18 Jan 2002 13:11: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 MAA26252;
	Fri, 18 Jan 2002 12:46: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 MAA26223
	for <nsis@optimus.ietf.org>; Fri, 18 Jan 2002 12:46:34 -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 MAA20518
	for <nsis@ietf.org>; Fri, 18 Jan 2002 12:46:31 -0500 (EST)
Received: from znsgs01r.europe.nortel.com (znsgs01r.europe.nortel.com [47.137.129.92])
	by zcars0m9.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g0IHk1f01784
	for <nsis@ietf.org>; Fri, 18 Jan 2002 12:46:01 -0500 (EST)
Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.73.112.187])
	by znsgs01r.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g0IHjh027103
	for <nsis@ietf.org>; Fri, 18 Jan 2002 17:45:43 GMT
Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19)
	id <D1FNG94J>; Fri, 18 Jan 2002 17:45:58 -0000
Message-ID: <4103264BC8D3D51180B7002048400C450A9BFF@zhard0jd.europe.nortel.com>
From: "Elwyn Davies"<elwynd@nortelnetworks.com>
To: "Nsis (E-mail)" <nsis@ietf.org>
Date: Fri, 18 Jan 2002 17:45:56 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C1A047.FB9F7C60"
Subject: [NSIS] Tying the requests to the flows exploiting them
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_01C1A047.FB9F7C60
Content-Type: text/plain;
	charset="iso-8859-1"

Hi.

Nsis is targeting the setup of QoS paths across multiple domains potentially
belonging to several organisations that don't trust each other.  This has
been reflected in the proposals for the internal operation of the protocol
where extensive security requirements are proposed (Sec 5.8).  What appears
to be missing are equivalently stringent means for ensuring that domains
that authorise a QoS path can tell that the packets using that path are
actually the ones that should be using it.

In the simpler world of Intserv and Diffserv, requested QoS is invoked by
simple pattern matching on some combination of the packet header fields, but
even here thare has been a good deal of heart searching about how to ensure
that only the right packets can exploit better treatment from a network
(sub-text: only get what they paid for).  To do this properly seems to need
two things:

- The QoS protocol must be able to carry back to the end host making the
request from each QoS domain, a seed for unforgeable tokens which can be
attached to packets belonging to flow(s) which are to exploit the QoS path
setup by the request.

- The end host must be able to generate and attach suitable unforgeable
tokens to each packet in a flow that should receive the requested treatment,
which may then be tested by each QoS domain through which the packet passes.

Regards,
Elwyn  

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

Elwyn B Davies

        Routing and Addressing Strategy Prime
        Portfolio Integration			Solutions Ready		

        Nortel Networks plc			Email:
elwynd@nortelnetworks.com
        Harlow Laboratories     			ESN
6-742-5498
        London Road, Harlow,    		Direct Line
+44-1279-405498
        Essex, CM17 9NA, UK     		Fax
+44-1279-402047
        Registered Office: 			Maidenhead Office Park,
Westacott Way,
        Company No. 3937799			Maidenhead, Berkshire, SSL6
3QH
----------------------------------------------------------------------------
This message may contain information proprietary to Nortel Networks plc so
any
unauthorised disclosure, copying or distribution of its contents is strictly
prohibited.
----------------------------------------------------------------------------
"The Folly is mostly mine"
and the opinions are mine and not those of my employer.
============================================================================
======






------_=_NextPart_001_01C1A047.FB9F7C60
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>Tying the requests to the flows exploiting them</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2 FACE=3D"Arial">Hi.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Nsis is targeting the setup of QoS =
paths across multiple domains potentially belonging to several =
organisations that don't trust each other.&nbsp; This has been =
reflected in the proposals for the internal operation of the protocol =
where extensive security requirements are proposed (Sec 5.8).&nbsp; =
What appears to be missing are equivalently stringent means for =
ensuring that domains that authorise a QoS path can tell that the =
packets using that path are actually the ones that should be using =
it.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">In the simpler world of Intserv and =
Diffserv, requested QoS is invoked by simple pattern matching on some =
combination of the packet header fields, but even here thare has been a =
good deal of heart searching about how to ensure that only the right =
packets can exploit better treatment from a network (sub-text: only get =
what they paid for).&nbsp; To do this properly seems to need two =
things:</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">- The QoS protocol must be able to =
carry back to the end host making the request from each QoS domain, a =
seed for unforgeable tokens which can be attached to packets belonging =
to flow(s) which are to exploit the QoS path setup by the =
request.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">- The end host must be able to =
generate and attach suitable unforgeable tokens to each packet in a =
flow that should receive the requested treatment, which may then be =
tested by each QoS domain through which the packet passes.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Regards,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Elwyn&nbsp; </FONT>
</P>

<P><FONT SIZE=3D1 =
FACE=3D"Arial">---------------------------------------------------------=
-------------------------</FONT>
</P>

<P><FONT SIZE=3D1 FACE=3D"Arial">Elwyn B Davies</FONT>
</P>

<P><FONT SIZE=3D1 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Routing and =
Addressing Strategy Prime</FONT>
<BR><FONT SIZE=3D1 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Portfolio =
Integration&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Solutions Ready =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
</P>

<P><FONT COLOR=3D"#000000" SIZE=3D1 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Nortel =
Networks plc&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT> <FONT SIZE=3D1 =
FACE=3D"Arial">Email: elwynd@nortelnetworks.com</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D1 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Harlow =
Laboratories&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
ESN&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 6-742-5498</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D1 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; London Road, =
Harlow,&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Direct =
Line&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
+44-1279-405498</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D1 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Essex, CM17 =
9NA, UK&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Fax&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +44-1279-402047</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D1 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Registered =
Office: &nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Maidenhead Office Park, =
Westacott Way,</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D1 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Company =
No.</FONT> <FONT SIZE=3D1 =
FACE=3D"Arial">3937799&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT><FONT =
COLOR=3D"#000000" SIZE=3D1 FACE=3D"Arial">Maidenhead, Berkshire, SSL6 =
3QH</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D1 =
FACE=3D"Arial">---------------------------------------------------------=
-------------------</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D1 FACE=3D"Arial">This message may =
contain information proprietary to Nortel Networks plc so any</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D1 FACE=3D"Arial">unauthorised =
disclosure, copying or distribution of its contents is strictly =
prohibited.</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D1 =
FACE=3D"Arial">---------------------------------------------------------=
-------------------</FONT>
<BR><FONT SIZE=3D1 FACE=3D"Arial">&quot;The Folly is mostly =
mine&quot;</FONT>
<BR><FONT SIZE=3D1 FACE=3D"Arial">and the opinions are mine and not =
those of my employer.</FONT>
<BR><FONT SIZE=3D1 =
FACE=3D"Arial">=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</FONT>
</P>
<BR>
<BR>
<BR>
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01C1A047.FB9F7C60--

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



From daemon@optimus.ietf.org  Fri Jan 18 13:15: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 MAA19693
	for <nsis-archive@odin.ietf.org>; Fri, 18 Jan 2002 12:26:40 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id MAA25107
	for nsis-archive@odin.ietf.org; Fri, 18 Jan 2002 12:26: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 MAA24231;
	Fri, 18 Jan 2002 12:04: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 MAA24201
	for <nsis@optimus.ietf.org>; Fri, 18 Jan 2002 12:04:36 -0500 (EST)
Received: from cbibipnt03.HC.BT.COM (saturn.bt.com [193.113.57.20])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18909
	for <nsis@ietf.org>; Fri, 18 Jan 2002 12:04:32 -0500 (EST)
From: dick.rr.knight@bt.com
Received: by cbibipnt03.hc.bt.com with Internet Mail Service (5.5.2652.35)
	id <DA1WFGWK>; Fri, 18 Jan 2002 16:44:47 -0000
Message-ID: <451D45016C2CD2119DA50000F8FE7F07080E5A45@mlngcbnt01.hc.bt.com>
To: wchen@tri.sbc.com, dick.rr.knight@bt.com, schneider@tri.sbc.com,
        Georgios.Karagiannis@eln.ericsson.se
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements  (priority on the boundary b
	e tween a customer and the network)
Date: Fri, 18 Jan 2002 16:44:37 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
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


There is something missing for me in your logic. What is 3?

I can better relate to the terminology of everyhop; everyedge; everyhost. Is
3 the everyhost bit?

-----Original Message-----
From: Chen, Weijing [mailto:wchen@tri.sbc.com]
Sent: 18 January 2002 16:12
To: 'dick.rr.knight@bt.com'; Schneider, Marco;
Georgios.Karagiannis@eln.ericsson.se
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements (priority on the boundary
be tween a customer and the network)


Sorry, previous picture is garbled by mailer. 


[host]<--1--[hop]-->[edge]<---2---[hop]-->[edge]<--1--[hop]-->[host]

[host]<-------------------3------------------------------------------------>
[host]


The 3 is our goal and is comprised of 1 and 2. As we know, there are
solutions for 2 (MPLS, DiffServ, PNNI, over-provisioning, etc). What we need
to solve is the 1.  Now what about translation (or mapping) between 1 and 2?
Do we need to standardize it?  If yes, where? In NSIS group or elsewhere?

Regardless, the objective of 1 is KISS and universal. The complexity of 1
and 2 mapping must be born by the [edge].



--
Weijing Chen
SBC Technology Resources
9505 Arboretum Blvd.
Austin, TX 78759
512 372 5710
wchen@tri.sbc.com



 -----Original Message-----
From: 	dick.rr.knight@bt.com [mailto:dick.rr.knight@bt.com] 
Sent:	Friday, January 18, 2002 5:12 AM
To:	Schneider, Marco; Georgios.Karagiannis@eln.ericsson.se;
dick.rr.knight@bt.com
Cc:	nsis@ietf.org
Subject:	RE: [NSIS] Two kinds of requirements (priority on the
boundary be tween a customer and the network)


I do not agree.

What is the point of completing the work enabling the customer to signal to
the network, if the network cannot signal between domains? The network can
never satisfy the request.

Dick

-----Original Message-----
From: Schneider, Marco [mailto:schneider@tri.sbc.com]
Sent: 18 January 2002 01:44
To: 'Georgios Karagiannis (ELN)'; 'dick.rr.knight@bt.com'
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


Hi Georgios,

While I agree NSIS could be used to support Interior to Interior (of one
carrier) or Edge to Core, I think that we need to prioritize on a signaling
protocol across the boundary between a customer and the network. Note that
the customer could be an individual, an ISP or another Carrier.

Marco Schneider

-----Original Message-----
From: Georgios Karagiannis (ELN)
[mailto:Georgios.Karagiannis@eln.ericsson.se]
Sent: Thursday, January 17, 2002 3:39 AM
To: 'dick.rr.knight@bt.com'
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


Hi Dick 

In principle I agree with your comment (see below).

[DK] >> To be more precise, I am suggesting a new protocol that is 
[DK] >> independent of the underlying transport technology and the QoS 
[DK] >> implemented and is also independent of the session control protocol.


However, a very important point here is that we need to 
specify a protocol that can be used independent of the underlying transport 
technology, but that can satisfy the QoS requirements imposed by these 
underlying transport technologies. Otherwise the protocol will not be
suitable
and useful.

A way of achieving this is by first creating a modular QoS signaling toolkit

that will contain mandatory and optional QoS requirements;
Second, specify how the protocol functionality should be separated in 
building blocks (protocol components) and define a minimum set 
of mandatory reservation options/features that should be 
processed by any network nodes, e.g., end-hosts,
proxies, edges and interior nodes.
An example of such a protocol decomposition is given below!
In this way each node will only process (check and use) the protocol 
components of interest.


|---------|
|---------|
|everyhost|<------------------------------------------------------->|everyho
st|
|---------|
|---------|
|         |                                                         |
|
|---------|   |---------|                             |---------|
|---------|
|everyedge|<->|everyedge|<--------------------------->|everyedge|<->|everyed
ge|
|---------|   |---------|                             |---------|
|---------|
|         |   |         |                             |         |   |
|
|---------|   |---------|   |--------|   |--------|   |---------|
|---------|
|everyhop |<->|everyhop |<->|everyhop|<->|everyhop|<->|everyhop
|<->|everyhop |
|---------|   |---------|   |--------|   |--------|   |---------|
|---------| 
    host          edge        interior    interior       edge          host


  NSIS protocol decomposition (building blocks): 
 *  "everyhost", "everyedge" and "everyhop" are protocol components;
 *  host: can be an end-host or a proxy and it can process and use the
"everyhost", 
    "everyedge", and "everyhop" protocol components;

 *  edge: can be a Diffserv edge, MPLS edge, etc., and it can process and
use 
    the "everyedge", and "everyhop" protocol components. The "everyhost" 
    protocol component is not processed (used or checked);

 *  interior: can be any router within a domain and it can process and use 
    only the "everyhop" protocol component.
    The "everyhost" and "everyedge" protocol components are not 
    processed (used or checked);


Best Regards,
Georgios

-----Original Message-----
From: dick.rr.knight@bt.com [mailto:dick.rr.knight@bt.com]
Sent: woensdag 16 januari 2002 13:00
To: brian.williams@ericsson.com.au; lieve.bos@alcatel.be
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


I was waiting for some reaction to Brian's comments, but as there aren't
any, here are my thoughts on the requirements:

I agree with the analysis that discussion has been based around
application-related signalling for QoS (at session level) and QoS signalling
protocols used to actually provision the QoS at the transport level.
Brian is right that there will never be an enhancement to a single session
protocol that will satisfy all applications.
However, for similar reasons, it is never going to be possible to prescribe
a single QoS mechanism to be used in all networks. Existing networks (or
domains) will not be changed overnight and new networks already face several
workable mechanisms to deploy QoS.

I think that what is needed is a new protocol that can signal the
requirements of any session and can be satisfied by any QoS mechanism,
existing or new.
To be more precise, I am suggesting a new protocol that is independent of
the underlying transport technology and the QoS implemented and is also
independent of the session control protocol. Such a new protocol would be
generic, optionally implemented by applications that would benefit from
end-to-end QoS, and would be complimentary to the QoS mechanisms deployed
(and of course other mechanisms, such as the routing).

I think that this implies a more abstract definition of the QoS mechanism
and may lend itself to the signalling of pre-defined QoS classes rather than
parameters.

Dick Knight

-----Original Message-----
From: Brian Williams [mailto:brian.williams@ericsson.com.au]
Sent: 22 December 2001 23:57
To: lieve.bos@alcatel.be
Cc: nsis@ietf.org
Subject: Re: [NSIS] Two kinds of requirements


Hi.
While the two types of signalling may be related, I think there is a
need to develop a QoS bearer mechanism which is independent of any
specific session signalling, and thus can be used for any application. I
believe many of the applications which have identified requirements to
the working group have their own specific session layer signalling (ie
it is not end-to-end SIP).  

Having the session and transport protocols developed separately of
course does not prohibit the two being used in conjunction for a
specific application.
/brian
 
On Fri, 2001-12-21 at 22:24, lieve.bos@alcatel.be wrote:
> Hello all,
> 
> >From the discussion in Salt Lake city and the drafts submitted, one can
> easily see that people are suggesting improvements to QoS signalling at
> two totally different levels (some at session level and some at
> transport level).
> 
> First of all, there are drafts suggesting some improvements in the
> session setup procedures (i.e. the ability to negotiate the preferred
> QoS level between end users during SDP negotiation in SIP, so before the
> actual resources are being setup). The QoS information negotiated at the
> session layer determines the QoS level both endusers have to use for 
> their local access connection. This first kind of 'session level QoS
> negotiation' happens end-to-end between the two end-users.
> 
> Secondly, there are drafts suggesting that we need
> improvements/alternatives for the QoS signalling protocols (e.g. RSVP)
> used to actually provision the QoS at the transport level between two
> endusers. This second kind of 'transport level QoS signalling' can
> consist of several phases: end-to-edge and edge-to-edge. 
> 
> It's important that everybody realises that, in order to give endusers
> true end-to-end Quality of Service, we need improvements for QoS both at
> session and transport level. Also its important to understand that they
> are not uncorrelated. Providers want to be able to control (e.g. via
> policy control mechanisms) that the QoS requested at the transport level
> is not exceeding the QoS negotiated/authorised previously at session
> level. So, what about developing in NSIS a modular framework
> incorporating both session and transport level QoS signalling with
> possible hooks between the two layers (e.g. for policy enforcement).
> 
> Lieve
> 
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis



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

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

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

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

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



From daemon@optimus.ietf.org  Fri Jan 18 14:23: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 OAA24076
	for <nsis-archive@odin.ietf.org>; Fri, 18 Jan 2002 14:22:51 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id OAA00289
	for nsis-archive@odin.ietf.org; Fri, 18 Jan 2002 14:22: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 OAA29967;
	Fri, 18 Jan 2002 14:09: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 OAA29936
	for <nsis@optimus.ietf.org>; Fri, 18 Jan 2002 14:09:00 -0500 (EST)
Received: from howler.tri.sbc.com (howler.tri.sbc.com [205.173.58.4])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23856
	for <nsis@ietf.org>; Fri, 18 Jan 2002 14:08:56 -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 g0IJB2T19714;
	Fri, 18 Jan 2002 13:11:02 -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 g0IJ8Pu09268;
	Fri, 18 Jan 2002 13:08:25 -0600 (CST)
Received: by TRIMAIL2.ad.tri.sbc.com with Internet Mail Service (5.5.2653.19)
	id <ZND32MPH>; Fri, 18 Jan 2002 13:08:52 -0600
Message-ID: <905A1C4ABF353F4C8CC16FA9F53DD0D6322426@TRIMAIL2.ad.tri.sbc.com>
From: "Chen, Weijing" <wchen@tri.sbc.com>
To: "'dick.rr.knight@bt.com'" <dick.rr.knight@bt.com>,
        "Schneider, Marco"
	 <schneider@tri.sbc.com>
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements  (priority on the boundary b
	 e tween a customer and the network)
Date: Fri, 18 Jan 2002 13:08:42 -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

Dick,

3 is more a function than a particular protocol or protocol component. Allow
me to illustrate the QoS service delivery chain with the diagram below:

[host]<--1--[hop]-->[edge]<---2---[hop]-->[edge]<--1--[hop]-->[host]

[host]<-------------------3----------------------------------------------->[
host]

a) The user locates the service provider or other subscriber(s) that he
wishes to contact.  The result of this step is that the subscriber will know
the network addresses of the other subscriber(s)) he wishes to contact, and
the QoS he wishes to use to contact them. (By SIP, SDP, DNS, web, or any
application level session protocol)
b) The user negotiates with the network to establish the desired
communications capabilities with the other subscriber(s). (By signaling
protocol 1)
c) The network internally allocates the resources to fulfill the
subscriber's request. (By signaling protocol 2 (e.g. PNNI, MPLS, RSVP, or
even over-provisioning) and mapping of QoS of 1 to QoS of 2)
d) The user authenticates with the other subscriber(s) and is authorized to
receive services from them. (By other security means)
e) The user then communicates with the other subscriber(s)) to receive
services. (By underline transport link reserved previously in step b and c.
)
f) At the conclusion of the session, billing information is recorded so the
subscriber can be billed for the network services.

Now 3 is the experience of the user who got QoS service from the network.
The actual protocols involved are 1 and 2. The 1 does not really go from
end-to-end, but from end-to-network, and network-to-end. The edge will do
the network-to-network. Again standardization of 1 to 2 QoS mapping is
debatable which I don't have an opinion yet.

--
Weijing Chen
SBC Technology Resources
9505 Arboretum Blvd.
Austin, TX 78759
512 372 5710
wchen@tri.sbc.com


 -----Original Message-----
From: 	dick.rr.knight@bt.com [mailto:dick.rr.knight@bt.com] 
Sent:	Friday, January 18, 2002 10:45 AM
To:	Chen, Weijing; dick.rr.knight@bt.com; Schneider, Marco;
Georgios.Karagiannis@eln.ericsson.se
Cc:	nsis@ietf.org
Subject:	RE: [NSIS] Two kinds of requirements  (priority on the
boundary b e tween a customer and the network)


There is something missing for me in your logic. What is 3?

I can better relate to the terminology of everyhop; everyedge; everyhost. Is
3 the everyhost bit?

-----Original Message-----
From: Chen, Weijing [mailto:wchen@tri.sbc.com]
Sent: 18 January 2002 16:12
To: 'dick.rr.knight@bt.com'; Schneider, Marco;
Georgios.Karagiannis@eln.ericsson.se
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements (priority on the boundary
be tween a customer and the network)


Sorry, previous picture is garbled by mailer. 


[host]<--1--[hop]-->[edge]<---2---[hop]-->[edge]<--1--[hop]-->[host]

[host]<-------------------3------------------------------------------------>
[host]


The 3 is our goal and is comprised of 1 and 2. As we know, there are
solutions for 2 (MPLS, DiffServ, PNNI, over-provisioning, etc). What we need
to solve is the 1.  Now what about translation (or mapping) between 1 and 2?
Do we need to standardize it?  If yes, where? In NSIS group or elsewhere?

Regardless, the objective of 1 is KISS and universal. The complexity of 1
and 2 mapping must be born by the [edge].



--
Weijing Chen
SBC Technology Resources
9505 Arboretum Blvd.
Austin, TX 78759
512 372 5710
wchen@tri.sbc.com



 -----Original Message-----
From: 	dick.rr.knight@bt.com [mailto:dick.rr.knight@bt.com] 
Sent:	Friday, January 18, 2002 5:12 AM
To:	Schneider, Marco; Georgios.Karagiannis@eln.ericsson.se;
dick.rr.knight@bt.com
Cc:	nsis@ietf.org
Subject:	RE: [NSIS] Two kinds of requirements (priority on the
boundary be tween a customer and the network)


I do not agree.

What is the point of completing the work enabling the customer to signal to
the network, if the network cannot signal between domains? The network can
never satisfy the request.

Dick

-----Original Message-----
From: Schneider, Marco [mailto:schneider@tri.sbc.com]
Sent: 18 January 2002 01:44
To: 'Georgios Karagiannis (ELN)'; 'dick.rr.knight@bt.com'
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


Hi Georgios,

While I agree NSIS could be used to support Interior to Interior (of one
carrier) or Edge to Core, I think that we need to prioritize on a signaling
protocol across the boundary between a customer and the network. Note that
the customer could be an individual, an ISP or another Carrier.

Marco Schneider

-----Original Message-----
From: Georgios Karagiannis (ELN)
[mailto:Georgios.Karagiannis@eln.ericsson.se]
Sent: Thursday, January 17, 2002 3:39 AM
To: 'dick.rr.knight@bt.com'
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


Hi Dick 

In principle I agree with your comment (see below).

[DK] >> To be more precise, I am suggesting a new protocol that is 
[DK] >> independent of the underlying transport technology and the QoS 
[DK] >> implemented and is also independent of the session control protocol.


However, a very important point here is that we need to 
specify a protocol that can be used independent of the underlying transport 
technology, but that can satisfy the QoS requirements imposed by these 
underlying transport technologies. Otherwise the protocol will not be
suitable
and useful.

A way of achieving this is by first creating a modular QoS signaling toolkit

that will contain mandatory and optional QoS requirements;
Second, specify how the protocol functionality should be separated in 
building blocks (protocol components) and define a minimum set 
of mandatory reservation options/features that should be 
processed by any network nodes, e.g., end-hosts,
proxies, edges and interior nodes.
An example of such a protocol decomposition is given below!
In this way each node will only process (check and use) the protocol 
components of interest.


|---------|
|---------|
|everyhost|<------------------------------------------------------->|everyho
st|
|---------|
|---------|
|         |                                                         |
|
|---------|   |---------|                             |---------|
|---------|
|everyedge|<->|everyedge|<--------------------------->|everyedge|<->|everyed
ge|
|---------|   |---------|                             |---------|
|---------|
|         |   |         |                             |         |   |
|
|---------|   |---------|   |--------|   |--------|   |---------|
|---------|
|everyhop |<->|everyhop |<->|everyhop|<->|everyhop|<->|everyhop
|<->|everyhop |
|---------|   |---------|   |--------|   |--------|   |---------|
|---------| 
    host          edge        interior    interior       edge          host


  NSIS protocol decomposition (building blocks): 
 *  "everyhost", "everyedge" and "everyhop" are protocol components;
 *  host: can be an end-host or a proxy and it can process and use the
"everyhost", 
    "everyedge", and "everyhop" protocol components;

 *  edge: can be a Diffserv edge, MPLS edge, etc., and it can process and
use 
    the "everyedge", and "everyhop" protocol components. The "everyhost" 
    protocol component is not processed (used or checked);

 *  interior: can be any router within a domain and it can process and use 
    only the "everyhop" protocol component.
    The "everyhost" and "everyedge" protocol components are not 
    processed (used or checked);


Best Regards,
Georgios

-----Original Message-----
From: dick.rr.knight@bt.com [mailto:dick.rr.knight@bt.com]
Sent: woensdag 16 januari 2002 13:00
To: brian.williams@ericsson.com.au; lieve.bos@alcatel.be
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


I was waiting for some reaction to Brian's comments, but as there aren't
any, here are my thoughts on the requirements:

I agree with the analysis that discussion has been based around
application-related signalling for QoS (at session level) and QoS signalling
protocols used to actually provision the QoS at the transport level.
Brian is right that there will never be an enhancement to a single session
protocol that will satisfy all applications.
However, for similar reasons, it is never going to be possible to prescribe
a single QoS mechanism to be used in all networks. Existing networks (or
domains) will not be changed overnight and new networks already face several
workable mechanisms to deploy QoS.

I think that what is needed is a new protocol that can signal the
requirements of any session and can be satisfied by any QoS mechanism,
existing or new.
To be more precise, I am suggesting a new protocol that is independent of
the underlying transport technology and the QoS implemented and is also
independent of the session control protocol. Such a new protocol would be
generic, optionally implemented by applications that would benefit from
end-to-end QoS, and would be complimentary to the QoS mechanisms deployed
(and of course other mechanisms, such as the routing).

I think that this implies a more abstract definition of the QoS mechanism
and may lend itself to the signalling of pre-defined QoS classes rather than
parameters.

Dick Knight

-----Original Message-----
From: Brian Williams [mailto:brian.williams@ericsson.com.au]
Sent: 22 December 2001 23:57
To: lieve.bos@alcatel.be
Cc: nsis@ietf.org
Subject: Re: [NSIS] Two kinds of requirements


Hi.
While the two types of signalling may be related, I think there is a
need to develop a QoS bearer mechanism which is independent of any
specific session signalling, and thus can be used for any application. I
believe many of the applications which have identified requirements to
the working group have their own specific session layer signalling (ie
it is not end-to-end SIP).  

Having the session and transport protocols developed separately of
course does not prohibit the two being used in conjunction for a
specific application.
/brian
 
On Fri, 2001-12-21 at 22:24, lieve.bos@alcatel.be wrote:
> Hello all,
> 
> >From the discussion in Salt Lake city and the drafts submitted, one can
> easily see that people are suggesting improvements to QoS signalling at
> two totally different levels (some at session level and some at
> transport level).
> 
> First of all, there are drafts suggesting some improvements in the
> session setup procedures (i.e. the ability to negotiate the preferred
> QoS level between end users during SDP negotiation in SIP, so before the
> actual resources are being setup). The QoS information negotiated at the
> session layer determines the QoS level both endusers have to use for 
> their local access connection. This first kind of 'session level QoS
> negotiation' happens end-to-end between the two end-users.
> 
> Secondly, there are drafts suggesting that we need
> improvements/alternatives for the QoS signalling protocols (e.g. RSVP)
> used to actually provision the QoS at the transport level between two
> endusers. This second kind of 'transport level QoS signalling' can
> consist of several phases: end-to-edge and edge-to-edge. 
> 
> It's important that everybody realises that, in order to give endusers
> true end-to-end Quality of Service, we need improvements for QoS both at
> session and transport level. Also its important to understand that they
> are not uncorrelated. Providers want to be able to control (e.g. via
> policy control mechanisms) that the QoS requested at the transport level
> is not exceeding the QoS negotiated/authorised previously at session
> level. So, what about developing in NSIS a modular framework
> incorporating both session and transport level QoS signalling with
> possible hooks between the two layers (e.g. for policy enforcement).
> 
> Lieve
> 
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis



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

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

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

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

_______________________________________________
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 Jan 18 14:31: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 OAA24297
	for <nsis-archive@odin.ietf.org>; Fri, 18 Jan 2002 14:31:18 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id OAA00922
	for nsis-archive@odin.ietf.org; Fri, 18 Jan 2002 14:31: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 OAA00111;
	Fri, 18 Jan 2002 14:13: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 OAA00039
	for <nsis@optimus.ietf.org>; Fri, 18 Jan 2002 14:13:24 -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 OAA23928
	for <nsis@ietf.org>; Fri, 18 Jan 2002 14:13:18 -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 g0IJFNT19760
	for <nsis@ietf.org>; Fri, 18 Jan 2002 13:15:23 -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 g0IJCkL09423
	for <nsis@ietf.org>; Fri, 18 Jan 2002 13:12:46 -0600 (CST)
Received: by TRIMAIL2.ad.tri.sbc.com with Internet Mail Service (5.5.2653.19)
	id <ZND32MQF>; Fri, 18 Jan 2002 13:13:13 -0600
Message-ID: <905A1C4ABF353F4C8CC16FA9F53DD0D62A6FF0@TRIMAIL2.ad.tri.sbc.com>
From: "Allen, Keith" <kallen@tri.sbc.com>
To: "Nsis (E-mail)" <nsis@ietf.org>
Subject: RE: [NSIS] Tying the requests to the flows exploiting them
Date: Fri, 18 Jan 2002 13:13:02 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C1A054.26793820"
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_01C1A054.26793820
Content-Type: text/plain;
	charset="iso-8859-1"

Hello.
 
I would like to see the NSIS protocol enable the user to specify during call
(or "session" or whatever) establishment the means by which the packets that
identified as part are part of the call very flexibly.  So, for example, for
one call the user might send packets with an MPLS label value agreed upon by
the user and the network.  On another call the user might send packets with
given source and destination IP addresses, and given source and destination
TCP port numbers.  In the first example, the MPLS label value is exchanged
in the signaling messages.  In the second, the IP addresses and port numbers
are exchanged. 
 
I wouldn't think forgeability would be an issue.  If the user slaps an MPLS
label value specified as part of a call on a packet that is not really part
of the call, well, it is now.  The network will always check to see if the
user is trying to exceed their QoS parameters and shape or drop or reduce
the priority of those packets that are beyond the limits.
 
So, I guess my philosophy could be stated that the parties on either side of
the interface trust the other to correctly identify which packets are part
of a call, but still check to make sure the traffic isn't exceeding the
agreed-upon limits.
 
Keith Allen
SBC Technology Resources
9505 Arboretum Blvd.
Austin, TX 78759
(512) 372-5741
kallen@tri.sbc.com <mailto:kallen@tri.sbc.com> 
 
-----Original Message-----
From: Elwyn Davies [mailto:elwynd@nortelnetworks.com]
Sent: Friday, January 18, 2002 11:46 AM
To: Nsis (E-mail)
Subject: [NSIS] Tying the requests to the flows exploiting them
 
Hi. 
Nsis is targeting the setup of QoS paths across multiple domains potentially
belonging to several organisations that don't trust each other.  This has
been reflected in the proposals for the internal operation of the protocol
where extensive security requirements are proposed (Sec 5.8).  What appears
to be missing are equivalently stringent means for ensuring that domains
that authorise a QoS path can tell that the packets using that path are
actually the ones that should be using it.
In the simpler world of Intserv and Diffserv, requested QoS is invoked by
simple pattern matching on some combination of the packet header fields, but
even here thare has been a good deal of heart searching about how to ensure
that only the right packets can exploit better treatment from a network
(sub-text: only get what they paid for).  To do this properly seems to need
two things:
- The QoS protocol must be able to carry back to the end host making the
request from each QoS domain, a seed for unforgeable tokens which can be
attached to packets belonging to flow(s) which are to exploit the QoS path
setup by the request.
- The end host must be able to generate and attach suitable unforgeable
tokens to each packet in a flow that should receive the requested treatment,
which may then be tested by each QoS domain through which the packet passes.
Regards, 
Elwyn  
----------------------------------------------------------------------------
------ 
Elwyn B Davies 
        Routing and Addressing Strategy Prime 
        Portfolio Integration                   Solutions Ready         
        Nortel Networks plc                     Email:
elwynd@nortelnetworks.com 
        Harlow Laboratories                             ESN
6-742-5498 
        London Road, Harlow,                    Direct Line
+44-1279-405498 
        Essex, CM17 9NA, UK                     Fax
+44-1279-402047 
        Registered Office:                      Maidenhead Office Park,
Westacott Way, 
        Company No. 3937799                     Maidenhead, Berkshire, SSL6
3QH 
----------------------------------------------------------------------------

This message may contain information proprietary to Nortel Networks plc so
any 
unauthorised disclosure, copying or distribution of its contents is strictly
prohibited. 
----------------------------------------------------------------------------

"The Folly is mostly mine" 
and the opinions are mine and not those of my employer. 
============================================================================
====== 





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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">


<meta name=3DProgId content=3DWord.Document>
<meta name=3DGenerator content=3D"Microsoft Word 9">
<meta name=3DOriginator content=3D"Microsoft Word 9">
<link rel=3DFile-List href=3D"cid:filelist.xml@01C1A021.DBC99270">
<title>Tying the requests to the flows exploiting them</title>
<!--[if gte mso 9]><xml>
 <o:OfficeDocumentSettings>
  <o:DoNotRelyOnCSS/>
 </o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:Zoom>0</w:Zoom>
  <w:DocumentKind>DocumentEmail</w:DocumentKind>
  <w:EnvelopeVis/>
  <w:Compatibility>
   <w:ForgetLastTabAlignment/>
   <w:DoNotUseHTMLParagraphAutoSpacing/>
  </w:Compatibility>
 </w:WordDocument>
</xml><![endif]-->
<style>
<!--
 /* Font Definitions */
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;
	mso-font-charset:0;
	mso-generic-font-family:swiss;
	mso-font-pitch:variable;
	mso-font-signature:553679495 -2147483648 8 0 66047 0;}
 /* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{mso-style-parent:"";
	margin:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;
	text-underline:single;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;
	text-underline:single;}
p.MsoAutoSig, li.MsoAutoSig, div.MsoAutoSig
	{margin:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
p
	{margin-right:0in;
	mso-margin-top-alt:auto;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
span.EmailStyle16
	{mso-style-type:personal-reply;
	mso-ansi-font-size:10.0pt;
	mso-ascii-font-family:Arial;
	mso-hansi-font-family:Arial;
	mso-bidi-font-family:Arial;
	color:navy;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;
	mso-header-margin:.5in;
	mso-footer-margin:.5in;
	mso-paper-source:0;}
div.Section1
	{page:Section1;}
-->
</style>
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple =
style=3D'tab-interval:.5in'>

<div class=3DSection1>

<p class=3DMsoNormal><span class=3DEmailStyle16><font size=3D2 =
color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'>H=
ello.<o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle16><font size=3D2 =
color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'><=
![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></span></p>=


<p class=3DMsoNormal><span class=3DEmailStyle16><font size=3D2 =
color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'>I=
 would
like to see the NSIS protocol enable the user to specify during call =
(or &#8220;session&#8221;
or whatever) establishment the means by which the packets that =
identified as
part are part of the call very flexibly.<span style=3D"mso-spacerun: =
yes">&nbsp;
</span>So, for example, for one call the user might send packets with =
an MPLS
label value agreed upon by the user and the network.<span =
style=3D"mso-spacerun:
yes">&nbsp; </span>On another call the user might send packets with =
given
source and destination IP addresses, and given source and destination =
TCP port
numbers.<span style=3D"mso-spacerun: yes">&nbsp; </span>In the first =
example, the
MPLS label value is exchanged in the signaling messages.<span
style=3D"mso-spacerun: yes">&nbsp; </span>In the second, the IP =
addresses and
port numbers are exchanged. <o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle16><font size=3D2 =
color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'><=
![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></span></p>=


<p class=3DMsoNormal><span class=3DEmailStyle16><font size=3D2 =
color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'>I=
 wouldn&#8217;t
think forgeability would be an issue.<span style=3D"mso-spacerun: =
yes">&nbsp;
</span>If the user slaps an MPLS label value specified as part of a =
call on a
packet that is not really part of the call, well, it is now.<span
style=3D"mso-spacerun: yes">&nbsp; </span>The network will always check =
to see if
the user is trying to exceed their QoS parameters and shape or drop or =
reduce
the priority of those packets that are beyond the =
limits.<o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle16><font size=3D2 =
color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'><=
![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></span></p>=


<p class=3DMsoNormal><span class=3DEmailStyle16><font size=3D2 =
color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'>S=
o, I
guess my philosophy could be stated that the parties on either side of =
the
interface trust the other to correctly identify which packets are part =
of a
call, but still check to make sure the traffic isn&#8217;t exceeding =
the agreed-upon
limits.<o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle16><font size=3D2 =
color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'><=
![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></span></p>=


<p class=3DMsoNormal><!--[if supportFields]><span =
class=3DEmailStyle16><font=20
size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;mso-bidi-font-size:
12.0pt;font-family:Arial'><span =
style=3D'mso-element:field-begin'></span><span=20
style=3D"mso-spacerun: yes">&nbsp;</span>AUTOTEXTLIST \s &quot;E-mail=20
Signature&quot; <span =
style=3D'mso-element:field-separator'></span></span></font></span><![end=
if]--><font
color=3Dblack><span style=3D'color:black'><o:p></o:p></span></font></p>

<p class=3DMsoNormal><i><font size=3D3 color=3Dnavy face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:navy;font-style:italic'>Keith =
Allen</span></font><font
color=3Dblack><span =
style=3D'color:black'><o:p></o:p></span></font></i></p>

<p class=3DMsoNormal><i><font size=3D3 color=3Dnavy face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:navy;font-style:italic'>SBC Technology =
Resources</span></font><font
color=3Dblack><span =
style=3D'color:black'><o:p></o:p></span></font></i></p>

<p class=3DMsoNormal><i><font size=3D3 color=3Dnavy face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:navy;font-style:italic'>9505 Arboretum =
Blvd.</span></font><font
color=3Dblack><span =
style=3D'color:black'><o:p></o:p></span></font></i></p>

<p class=3DMsoNormal><i><font size=3D3 color=3Dnavy face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:navy;font-style:italic'>Austin, TX =
78759</span></font><font
color=3Dblack><span =
style=3D'color:black'><o:p></o:p></span></font></i></p>

<p class=3DMsoNormal><i><font size=3D3 color=3Dnavy face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:navy;font-style:italic'>(512) =
372-5741</span></font><font
color=3Dblack><span =
style=3D'color:black'><o:p></o:p></span></font></i></p>

<p class=3DMsoNormal><font size=3D3 color=3Dnavy face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:navy'><a =
href=3D"mailto:kallen@tri.sbc.com">kallen@tri.sbc.com</a><o:p></o:p></sp=
an></font></p>

<p class=3DMsoNormal><!--[if supportFields]><span =
class=3DEmailStyle16><font=20
size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;mso-bidi-font-size:
12.0pt;font-family:Arial'><span =
style=3D'mso-element:field-end'></span></span></font></span><![endif]-->=
<span
class=3DEmailStyle16><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'><![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></span></p>=


<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D2 =
color=3Dblack
face=3DTahoma><span =
style=3D'font-size:10.0pt;font-family:Tahoma;color:black'>-----Original
Message-----<br>
<b><span style=3D'font-weight:bold'>From:</span></b> Elwyn Davies
[mailto:elwynd@nortelnetworks.com]<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Friday, January =
18, 2002
11:46 AM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> Nsis (E-mail)<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> [NSIS] Tying =
the requests
to the flows exploiting them</span></font></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D3 =
face=3D"Times New Roman"><span
style=3D'font-size:12.0pt'><![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></p>

<p style=3D'margin-left:.5in'><font size=3D2 color=3Dblack =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:black'>Hi.</span></fon=
t><font
color=3Dblack><span style=3D'color:black'> </span></font><font =
color=3Dblack><span
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p style=3D'margin-left:.5in'><font size=3D2 color=3Dblack =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:black'>Nsis is =
targeting the
setup of QoS paths across multiple domains potentially belonging to =
several
organisations that don't trust each other.&nbsp; This has been =
reflected in the
proposals for the internal operation of the protocol where extensive =
security
requirements are proposed (Sec 5.8).&nbsp; What appears to be missing =
are
equivalently stringent means for ensuring that domains that authorise a =
QoS path
can tell that the packets using that path are actually the ones that =
should be
using it.</span></font><font color=3Dblack><span =
style=3D'color:black;mso-color-alt:
windowtext'><o:p></o:p></span></font></p>

<p style=3D'margin-left:.5in'><font size=3D2 color=3Dblack =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:black'>In the simpler =
world of
Intserv and Diffserv, requested QoS is invoked by simple pattern =
matching on
some combination of the packet header fields, but even here thare has =
been a
good deal of heart searching about how to ensure that only the right =
packets
can exploit better treatment from a network (sub-text: only get what =
they paid
for).&nbsp; To do this properly seems to need two =
things:</span></font><font
color=3Dblack><span =
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p style=3D'margin-left:.5in'><font size=3D2 color=3Dblack =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:black'>- The QoS =
protocol must
be able to carry back to the end host making the request from each QoS =
domain,
a seed for unforgeable tokens which can be attached to packets =
belonging to
flow(s) which are to exploit the QoS path setup by the =
request.</span></font><font
color=3Dblack><span =
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p style=3D'margin-left:.5in'><font size=3D2 color=3Dblack =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:black'>- The end host =
must be
able to generate and attach suitable unforgeable tokens to each packet =
in a
flow that should receive the requested treatment, which may then be =
tested by
each QoS domain through which the packet passes.</span></font><font
color=3Dblack><span =
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p style=3D'margin-left:.5in'><font size=3D2 color=3Dblack =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:black'>Regards,</span>=
</font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span style=3D'f=
ont-size:10.0pt;
font-family:Arial;color:black'>Elwyn&nbsp; </span></font><font =
color=3Dblack><span
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p style=3D'margin-left:.5in'><font size=3D1 color=3Dblack =
face=3DArial><span
style=3D'font-size:7.5pt;font-family:Arial;color:black'>----------------=
------------------------------------------------------------------</span=
></font><font
color=3Dblack><span style=3D'color:black'> </span></font><font =
color=3Dblack><span
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p style=3D'margin-left:.5in'><font size=3D1 color=3Dblack =
face=3DArial><span
style=3D'font-size:7.5pt;font-family:Arial;color:black'>Elwyn B =
Davies</span></font><font
color=3Dblack><span style=3D'color:black'> </span></font><font =
color=3Dblack><span
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p style=3D'margin-left:.5in'><font size=3D1 color=3Dblack =
face=3DArial><span
style=3D'font-size:7.5pt;font-family:Arial;color:black'>&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;
Routing and Addressing Strategy Prime</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D1 color=3Dblack face=3DArial><span =
style=3D'font-size:7.5pt;
font-family:Arial;color:black'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;
Portfolio Integration&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Solutions Ready
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></font><font =
color=3Dblack><span
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p style=3D'margin-left:.5in'><font size=3D1 color=3Dblack =
face=3DArial><span
style=3D'font-size:7.5pt;font-family:Arial;color:black'>&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;
Nortel Networks plc&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span></font><font =
color=3Dblack><span
style=3D'color:black'> </span></font><font size=3D1 color=3Dblack =
face=3DArial><span
style=3D'font-size:7.5pt;font-family:Arial;color:black'>Email:
elwynd@nortelnetworks.com</span></font><font color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D1 color=3Dblack face=3DArial><span =
style=3D'font-size:7.5pt;
font-family:Arial;color:black'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; Harlow
Laboratories&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
ESN&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
6-742-5498</span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D1 color=3Dblack face=3DArial><span =
style=3D'font-size:7.5pt;
font-family:Arial;color:black'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;
London Road, Harlow,&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Direct =
Line&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
+44-1279-405498</span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D1 color=3Dblack face=3DArial><span =
style=3D'font-size:7.5pt;
font-family:Arial;color:black'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;
Essex, CM17 9NA, UK&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Fax&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
+44-1279-402047</span></font><font color=3Dblack><span =
style=3D'color:black'> <br>
</span></font><font size=3D1 color=3Dblack face=3DArial><span =
style=3D'font-size:7.5pt;
font-family:Arial;color:black'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;
Registered Office: &nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Maidenhead Office Park, =
Westacott
Way,</span></font><font color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D1 color=3Dblack face=3DArial><span =
style=3D'font-size:7.5pt;
font-family:Arial;color:black'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;
Company No.</span></font><font color=3Dblack><span =
style=3D'color:black'> </span></font><font
size=3D1 color=3Dblack face=3DArial><span =
style=3D'font-size:7.5pt;font-family:Arial;
color:black'>3937799&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Maidenhead, Berkshire, SSL6 =
3QH</span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D1 color=3Dblack face=3DArial><span =
style=3D'font-size:7.5pt;
font-family:Arial;color:black'>-----------------------------------------=
-----------------------------------</span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D1 color=3Dblack face=3DArial><span =
style=3D'font-size:7.5pt;
font-family:Arial;color:black'>This message may contain information =
proprietary
to Nortel Networks plc so any</span></font><font color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D1 color=3Dblack face=3DArial><span =
style=3D'font-size:7.5pt;
font-family:Arial;color:black'>unauthorised disclosure, copying or =
distribution
of its contents is strictly prohibited.</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D1 color=3Dblack face=3DArial><span =
style=3D'font-size:7.5pt;
font-family:Arial;color:black'>-----------------------------------------=
-----------------------------------</span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D1 color=3Dblack face=3DArial><span =
style=3D'font-size:7.5pt;
font-family:Arial;color:black'>&quot;The Folly is mostly =
mine&quot;</span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D1 color=3Dblack face=3DArial><span =
style=3D'font-size:7.5pt;
font-family:Arial;color:black'>and the opinions are mine and not those =
of my
employer.</span></font><font color=3Dblack><span style=3D'color:black'> =
<br>
</span></font><font size=3D1 color=3Dblack face=3DArial><span =
style=3D'font-size:7.5pt;
font-family:Arial;color:black'>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</span></fon=
t><font
color=3Dblack><span style=3D'color:black'> </span></font><font =
color=3Dblack><span
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:0in;margin-right:0in;margin-bottom:
12.0pt;margin-left:.5in'><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:black'><br>
<br style=3D'mso-special-character:line-break'>
<![if !supportLineBreakNewLine]><br =
style=3D'mso-special-character:line-break'>
<![endif]></span></font><font color=3Dblack><span =
style=3D'color:black;mso-color-alt:
windowtext'><o:p></o:p></span></font></p>

</div>

</body>

</html>

------_=_NextPart_001_01C1A054.26793820--

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



From daemon@ns.ietf.org  Fri Jan 18 14: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 OAA24567
	for <nsis-archive@odin.ietf.org>; Fri, 18 Jan 2002 14:41:19 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id OAA01206
	for nsis-archive@odin.ietf.org; Fri, 18 Jan 2002 14:39: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 OAA00439;
	Fri, 18 Jan 2002 14:28: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 OAA00412
	for <nsis@optimus.ietf.org>; Fri, 18 Jan 2002 14:28:02 -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 OAA24217
	for <nsis@ietf.org>; Fri, 18 Jan 2002 14:27:57 -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 g0IJU3T19845;
	Fri, 18 Jan 2002 13:30:03 -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 g0IJRPr09992;
	Fri, 18 Jan 2002 13:27:25 -0600 (CST)
Received: by TRIMAIL2.ad.tri.sbc.com with Internet Mail Service (5.5.2653.19)
	id <ZND32MTQ>; Fri, 18 Jan 2002 13:27:52 -0600
Message-ID: <905A1C4ABF353F4C8CC16FA9F53DD0D638B99F@TRIMAIL2.ad.tri.sbc.com>
From: "Schneider, Marco" <schneider@tri.sbc.com>
To: "Chen, Weijing" <wchen@tri.sbc.com>,
        "'dick.rr.knight@bt.com'"
	 <dick.rr.knight@bt.com>,
        "'Georgios.Karagiannis@eln.ericsson.se'"
	 <Georgios.Karagiannis@eln.ericsson.se>
Cc: "'nsis@ietf.org'" <nsis@ietf.org>
Subject: RE: [NSIS] Two kinds of requirements (priority on the boundary be
	 tween a customer and the network)
Date: Fri, 18 Jan 2002 13:27:47 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: nsis-admin@ietf.org
Errors-To: nsis-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Next Steps in Signaling <nsis.ietf.org>
X-BeenThere: nsis@ietf.org

Dick,

Perhaps you have interpreted my wording differently than intended. By
"Interior to Interior" I meant within the same domain. As Weijing comments
below there are already a number of solutions within 2 and these do not
require signaling in direct response to an NSIS setup request when they deal
with aggregated paths. 

Marco 
-----Original Message-----
From: Chen, Weijing 
Sent: Friday, January 18, 2002 10:12 AM
To: 'dick.rr.knight@bt.com'; Schneider, Marco;
Georgios.Karagiannis@eln.ericsson.se
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements (priority on the boundary
be tween a customer and the network)


Sorry, previous picture is garbled by mailer. 


[host]<--1--[hop]-->[edge]<---2---[hop]-->[edge]<--1--[hop]-->[host]

[host]<-------------------3------------------------------------------------>
[host]


The 3 is our goal and is comprised of 1 and 2. As we know, there are
solutions for 2 (MPLS, DiffServ, PNNI, over-provisioning, etc). What we need
to solve is the 1.  Now what about translation (or mapping) between 1 and 2?
Do we need to standardize it?  If yes, where? In NSIS group or elsewhere?

Regardless, the objective of 1 is KISS and universal. The complexity of 1
and 2 mapping must be born by the [edge].



--
Weijing Chen
SBC Technology Resources
9505 Arboretum Blvd.
Austin, TX 78759
512 372 5710
wchen@tri.sbc.com



 -----Original Message-----
From: 	dick.rr.knight@bt.com [mailto:dick.rr.knight@bt.com] 
Sent:	Friday, January 18, 2002 5:12 AM
To:	Schneider, Marco; Georgios.Karagiannis@eln.ericsson.se;
dick.rr.knight@bt.com
Cc:	nsis@ietf.org
Subject:	RE: [NSIS] Two kinds of requirements (priority on the
boundary be tween a customer and the network)


I do not agree.

What is the point of completing the work enabling the customer to signal to
the network, if the network cannot signal between domains? The network can
never satisfy the request.

Dick

-----Original Message-----
From: Schneider, Marco [mailto:schneider@tri.sbc.com]
Sent: 18 January 2002 01:44
To: 'Georgios Karagiannis (ELN)'; 'dick.rr.knight@bt.com'
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


Hi Georgios,

While I agree NSIS could be used to support Interior to Interior (of one
carrier) or Edge to Core, I think that we need to prioritize on a signaling
protocol across the boundary between a customer and the network. Note that
the customer could be an individual, an ISP or another Carrier.

Marco Schneider

-----Original Message-----
From: Georgios Karagiannis (ELN)
[mailto:Georgios.Karagiannis@eln.ericsson.se]
Sent: Thursday, January 17, 2002 3:39 AM
To: 'dick.rr.knight@bt.com'
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


Hi Dick 

In principle I agree with your comment (see below).

[DK] >> To be more precise, I am suggesting a new protocol that is 
[DK] >> independent of the underlying transport technology and the QoS 
[DK] >> implemented and is also independent of the session control protocol.


However, a very important point here is that we need to 
specify a protocol that can be used independent of the underlying transport 
technology, but that can satisfy the QoS requirements imposed by these 
underlying transport technologies. Otherwise the protocol will not be
suitable
and useful.

A way of achieving this is by first creating a modular QoS signaling toolkit

that will contain mandatory and optional QoS requirements;
Second, specify how the protocol functionality should be separated in 
building blocks (protocol components) and define a minimum set 
of mandatory reservation options/features that should be 
processed by any network nodes, e.g., end-hosts,
proxies, edges and interior nodes.
An example of such a protocol decomposition is given below!
In this way each node will only process (check and use) the protocol 
components of interest.


|---------|
|---------|
|everyhost|<------------------------------------------------------->|everyho
st|
|---------|
|---------|
|         |                                                         |
|
|---------|   |---------|                             |---------|
|---------|
|everyedge|<->|everyedge|<--------------------------->|everyedge|<->|everyed
ge|
|---------|   |---------|                             |---------|
|---------|
|         |   |         |                             |         |   |
|
|---------|   |---------|   |--------|   |--------|   |---------|
|---------|
|everyhop |<->|everyhop |<->|everyhop|<->|everyhop|<->|everyhop
|<->|everyhop |
|---------|   |---------|   |--------|   |--------|   |---------|
|---------| 
    host          edge        interior    interior       edge          host


  NSIS protocol decomposition (building blocks): 
 *  "everyhost", "everyedge" and "everyhop" are protocol components;
 *  host: can be an end-host or a proxy and it can process and use the
"everyhost", 
    "everyedge", and "everyhop" protocol components;

 *  edge: can be a Diffserv edge, MPLS edge, etc., and it can process and
use 
    the "everyedge", and "everyhop" protocol components. The "everyhost" 
    protocol component is not processed (used or checked);

 *  interior: can be any router within a domain and it can process and use 
    only the "everyhop" protocol component.
    The "everyhost" and "everyedge" protocol components are not 
    processed (used or checked);


Best Regards,
Georgios

-----Original Message-----
From: dick.rr.knight@bt.com [mailto:dick.rr.knight@bt.com]
Sent: woensdag 16 januari 2002 13:00
To: brian.williams@ericsson.com.au; lieve.bos@alcatel.be
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


I was waiting for some reaction to Brian's comments, but as there aren't
any, here are my thoughts on the requirements:

I agree with the analysis that discussion has been based around
application-related signalling for QoS (at session level) and QoS signalling
protocols used to actually provision the QoS at the transport level.
Brian is right that there will never be an enhancement to a single session
protocol that will satisfy all applications.
However, for similar reasons, it is never going to be possible to prescribe
a single QoS mechanism to be used in all networks. Existing networks (or
domains) will not be changed overnight and new networks already face several
workable mechanisms to deploy QoS.

I think that what is needed is a new protocol that can signal the
requirements of any session and can be satisfied by any QoS mechanism,
existing or new.
To be more precise, I am suggesting a new protocol that is independent of
the underlying transport technology and the QoS implemented and is also
independent of the session control protocol. Such a new protocol would be
generic, optionally implemented by applications that would benefit from
end-to-end QoS, and would be complimentary to the QoS mechanisms deployed
(and of course other mechanisms, such as the routing).

I think that this implies a more abstract definition of the QoS mechanism
and may lend itself to the signalling of pre-defined QoS classes rather than
parameters.

Dick Knight

-----Original Message-----
From: Brian Williams [mailto:brian.williams@ericsson.com.au]
Sent: 22 December 2001 23:57
To: lieve.bos@alcatel.be
Cc: nsis@ietf.org
Subject: Re: [NSIS] Two kinds of requirements


Hi.
While the two types of signalling may be related, I think there is a
need to develop a QoS bearer mechanism which is independent of any
specific session signalling, and thus can be used for any application. I
believe many of the applications which have identified requirements to
the working group have their own specific session layer signalling (ie
it is not end-to-end SIP).  

Having the session and transport protocols developed separately of
course does not prohibit the two being used in conjunction for a
specific application.
/brian
 
On Fri, 2001-12-21 at 22:24, lieve.bos@alcatel.be wrote:
> Hello all,
> 
> >From the discussion in Salt Lake city and the drafts submitted, one can
> easily see that people are suggesting improvements to QoS signalling at
> two totally different levels (some at session level and some at
> transport level).
> 
> First of all, there are drafts suggesting some improvements in the
> session setup procedures (i.e. the ability to negotiate the preferred
> QoS level between end users during SDP negotiation in SIP, so before the
> actual resources are being setup). The QoS information negotiated at the
> session layer determines the QoS level both endusers have to use for 
> their local access connection. This first kind of 'session level QoS
> negotiation' happens end-to-end between the two end-users.
> 
> Secondly, there are drafts suggesting that we need
> improvements/alternatives for the QoS signalling protocols (e.g. RSVP)
> used to actually provision the QoS at the transport level between two
> endusers. This second kind of 'transport level QoS signalling' can
> consist of several phases: end-to-edge and edge-to-edge. 
> 
> It's important that everybody realises that, in order to give endusers
> true end-to-end Quality of Service, we need improvements for QoS both at
> session and transport level. Also its important to understand that they
> are not uncorrelated. Providers want to be able to control (e.g. via
> policy control mechanisms) that the QoS requested at the transport level
> is not exceeding the QoS negotiated/authorised previously at session
> level. So, what about developing in NSIS a modular framework
> incorporating both session and transport level QoS signalling with
> possible hooks between the two layers (e.g. for policy enforcement).
> 
> Lieve
> 
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis



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

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

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

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

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



From daemon@ns.ietf.org  Fri Jan 18 15:07: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 PAA25352
	for <nsis-archive@odin.ietf.org>; Fri, 18 Jan 2002 15:07:04 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id PAA02342
	for nsis-archive@odin.ietf.org; Fri, 18 Jan 2002 15:07: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 OAA01623;
	Fri, 18 Jan 2002 14:54: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 OAA01594
	for <nsis@ns.ietf.org>; Fri, 18 Jan 2002 14:54:37 -0500 (EST)
Received: from fig.isi.edu (fig.isi.edu [128.9.160.78])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25010
	for <nsis@ietf.org>; Fri, 18 Jan 2002 14:54:32 -0500 (EST)
Received: from localhost (berson@localhost)
	by fig.isi.edu (8.11.6/8.11.6) with ESMTP id g0IJsMG05918;
	Fri, 18 Jan 2002 11:54:22 -0800
X-Authentication-Warning: fig.isi.edu: berson owned process doing -bs
Date: Fri, 18 Jan 2002 11:54:22 -0800 (PST)
From: Steven Berson <berson@isi.edu>
To: "Loughney John (NRC/Helsinki)" <john.loughney@nokia.com>
cc: jmaeng@ipdialog.com, <nsis@ietf.org>
Subject: RE: [NSIS] Charter of nsis
In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEF5D938C@esebe004.NOE.Nokia.com>
Message-ID: <Pine.LNX.4.44.0201181112400.5416-100000@fig.isi.edu>
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

RSVP is just the signalling.  Please take the time to read RFC 2205
(and associated documents) if there is any confusion.  Perhaps, a 
reading list (in priority order) about RSVP and Integrated Services 
would be useful.

I would start with:

RFC	Title
---	-----
1633	Integrated Services in the Internet Architecture: an Overview
2205	Resource ReSerVation Protocol (RSVP) -- Version 1 Functional 
	Specification
2210	The Use of RSVP with IETF Integrated Services
2961	RSVP Refresh Overhead Reduction Extensions
3209	RSVP-TE: Extensions to RSVP for LSP Tunnels

RFC 1633 gives the broad architecture for RSVP and Integrated 
Services.  RFC 2205 is the RSVP specification.  RFC 2210 describes how 
RSVP actually signals for specific services.  RFC 2961 gives a variety 
of optimizations for RSVP to deal with fast setup of reservations and 
reducing the number of refresh messages.  RFC 3209 describes how RSVP 
is used for MPLS.

In addition the following RFCs are useful and define two types of 
Quality of Service as well as a general template for a service.  I've 
already mentioned RFC 2998 before.

RFC	Title
---	-----
2211	Specification of the Controlled-Load Network Element Service
2212	Specification of Guaranteed Quality of Service
2216	Network Element Service Specification Template
2998	A Framework for Integrated Services Operation over Diffserv
	Networks


Finally, there a lot of other RFCs that are also directly related to 
RSVP (and signalling in general) and integrated services that I list 
for (I hope) completeness.

RFC	Title
---	-----
2206	RSVP Management Information Base using SMIv2
2207	RSVP Extensions for IPSEC Data Flows
2208	Resource ReSerVation Protocol (RSVP) -- Version 1 
	Applicability Statement Some Guidelines on Deployment
2209	Resource ReSerVation Protocol (RSVP) -- Version 1 Message
	Processing Rules
2213	Integrated Services Management Information Base using SMIv2
2214	Integrated Services Management Information Base Guaranteed
	Service Extensions using SMIv2
2215	General Characterization Parameters for Integrated Service
	Network Elements
2379	RSVP over ATM Implementation Guidelines
2380	RSVP over ATM Implementation Requirements
2381	Interoperation of Controlled-Load Service and Guaranteed 
	Service with ATM
2382	A Framework for Integrated Services and RSVP over ATM
2688	Integrated Services Mappings for Low Speed Networks
2689	Providing Integrated Services over Low-bitrate Links
2745	RSVP Diagnostic Messages
2746	RSVP Operation Over IP Tunnels
2747	RSVP Cryptographic Authentication
2748	The COPS (Common Open Policy Service) Protocol
2749	COPS usage for RSVP
2750	RSVP Extensions for Policy Control
2751	Signaled Preemption Priority Policy Element
2752	Identity Representation for RSVP
2753	A Framework for Policy-based Admission Control
2814	SBM (Subnet Bandwidth Manager): A Protocol for RSVP-based
	Admission Control over IEEE 802-style networks
2815	Integrated Service Mappings on IEEE 802 Networks
2816	A Framework for Integrated Services Over Shared and Switched 
	IEEE 802 LAN Technologies
2872	Application and Sub Application Identity Policy Element for 
	Use with RSVP
2996	Format of the RSVP DCLASS Object
2997	Specification of the Null Service Type
3006	Integrated Services in the Presence of Compressible Flows
3097	RSVP Cryptographic Authentication -- Updated Message Type 
	Value
3175	Aggregation of RSVP for IPv4 and IPv6 Reservations
3182	Identity Representation for RSVP
3210	Applicability Statement for Extensions to RSVP for LSP-Tunnels

Regards,
Steve



On Fri, 18 Jan 2002, Loughney John (NRC/Helsinki) wrote:

> Hi,
> 
> > I am new to this group. I read most of discussions and am 
> > confused with the charter of this group.  In my mind, RSVP is 
> > more than signaling since it specifies how routers should behave 
> > and so on.  Is nsis' goal is to define something like RSVP and 
> > specify the behavior of networks to meet the
> > signaling?  I would appreciate any clarification.
> 
> No, we are looking at using RSVP only for signaling so that
> some features of RSVP may not be needed.  Also, we can
> think of 'creative' ways in which to use RSVP for signaling
> that may require additional specification.
> 
> 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  Fri Jan 18 15:10: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 PAA25430
	for <nsis-archive@odin.ietf.org>; Fri, 18 Jan 2002 15:10:28 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id PAA02396
	for nsis-archive@odin.ietf.org; Fri, 18 Jan 2002 15:10: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 PAA02242;
	Fri, 18 Jan 2002 15:03: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 PAA02175
	for <nsis@ns.ietf.org>; Fri, 18 Jan 2002 15:03:12 -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 PAA25258
	for <nsis@ietf.org>; Fri, 18 Jan 2002 15:03:08 -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 g0IK5ET20061
	for <nsis@ietf.org>; Fri, 18 Jan 2002 14:05:14 -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 g0IK2bC11490
	for <nsis@ietf.org>; Fri, 18 Jan 2002 14:02:37 -0600 (CST)
Received: by TRIMAIL2.ad.tri.sbc.com with Internet Mail Service (5.5.2653.19)
	id <ZND32M7Y>; Fri, 18 Jan 2002 14:03:04 -0600
Message-ID: <905A1C4ABF353F4C8CC16FA9F53DD0D62A6FF1@TRIMAIL2.ad.tri.sbc.com>
From: "Allen, Keith" <kallen@tri.sbc.com>
To: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements  (priority on the boundary b
	 e tween a customer and the network)
Date: Fri, 18 Jan 2002 14:03:03 -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 all,

I'm still trying to get caught up on the terminology and semantics of the
discussion you are having, and I'm having some difficulty understanding the
edge-edge, hop-hop, and host-host discussion.

In telephony signaling, at least, the concept of "termination" is used.  An
entity "terminates" signaling if it receives signaling information,
understands it, and takes some action in response to it.  Now, part of the
action taken in response to a signaling message might be to formulate
another signaling message (using either the same signaling protocol or a
different protocol) and send it along to another entity, but it has still
"terminated" the signaling.  An entity that does not terminate signaling
would just blindly convey a signaling packet without looking at its
contents.

Given this concept, has NSIS converged upon the entities that will terminate
the signaling protocol it is trying to define?  If we coarsely define the
universe as consisting of network service providers and network service
users, I can think of the following possible combinations of entities for
"terminating" a signaling exchange:

1. user - service provider
2. service provider - service provider
3. user - user
4. within a service provider's domain
5. within a user's domain

I hope NSIS is focused on (1).  (2) would also be useful, but the needs of
this interaction differ some from (1) and trying to define a single protocol
that does both might be difficult.  Users rarely interface directly with
other users without a service provider in between, so (3) would seem to be a
low priority.  Users may want to exchange data with each other about QoS,
though, using the network as a non-terminating transport mechanism for this
exchange.  I think, however, there will be lots of protocols that spring up
for this.  Things like SIP, H.248(?) and even the ubiquitous XML could end
up being used for this.  I think NSIS should focus elsewhere and not try to
duplicate these efforts.  There are already some protocols defined that
might fit the bill for (4) and (5), so again NSIS should not duplicate these
efforts or work them at a lower priority.

Of course, focusing on (1) and possibly (2) does not mean the others can be
ignored.  NSIS should be cognizant of the developments in those areas so its
work meshes well.

Keith Allen
SBC Technology Resources
9505 Arboretum Blvd.
Austin, TX 78759
(512) 372-5741
kallen@tri.sbc.com

 -----Original Message-----
From: 	Chen, Weijing  
Sent:	Friday, January 18, 2002 1:09 PM
To:	'dick.rr.knight@bt.com'; Schneider, Marco
Cc:	nsis@ietf.org
Subject:	RE: [NSIS] Two kinds of requirements  (priority on the
boundary b e tween a customer and the network)

Dick,

3 is more a function than a particular protocol or protocol component. Allow
me to illustrate the QoS service delivery chain with the diagram below:

[host]<--1--[hop]-->[edge]<---2---[hop]-->[edge]<--1--[hop]-->[host]

[host]<-------------------3----------------------------------------------->[
host]

a) The user locates the service provider or other subscriber(s) that he
wishes to contact.  The result of this step is that the subscriber will know
the network addresses of the other subscriber(s)) he wishes to contact, and
the QoS he wishes to use to contact them. (By SIP, SDP, DNS, web, or any
application level session protocol)
b) The user negotiates with the network to establish the desired
communications capabilities with the other subscriber(s). (By signaling
protocol 1)
c) The network internally allocates the resources to fulfill the
subscriber's request. (By signaling protocol 2 (e.g. PNNI, MPLS, RSVP, or
even over-provisioning) and mapping of QoS of 1 to QoS of 2)
d) The user authenticates with the other subscriber(s) and is authorized to
receive services from them. (By other security means)
e) The user then communicates with the other subscriber(s)) to receive
services. (By underline transport link reserved previously in step b and c.
)
f) At the conclusion of the session, billing information is recorded so the
subscriber can be billed for the network services.

Now 3 is the experience of the user who got QoS service from the network.
The actual protocols involved are 1 and 2. The 1 does not really go from
end-to-end, but from end-to-network, and network-to-end. The edge will do
the network-to-network. Again standardization of 1 to 2 QoS mapping is
debatable which I don't have an opinion yet.

--
Weijing Chen
SBC Technology Resources
9505 Arboretum Blvd.
Austin, TX 78759
512 372 5710
wchen@tri.sbc.com


 -----Original Message-----
From: 	dick.rr.knight@bt.com [mailto:dick.rr.knight@bt.com] 
Sent:	Friday, January 18, 2002 10:45 AM
To:	Chen, Weijing; dick.rr.knight@bt.com; Schneider, Marco;
Georgios.Karagiannis@eln.ericsson.se
Cc:	nsis@ietf.org
Subject:	RE: [NSIS] Two kinds of requirements  (priority on the
boundary b e tween a customer and the network)


There is something missing for me in your logic. What is 3?

I can better relate to the terminology of everyhop; everyedge; everyhost. Is
3 the everyhost bit?

-----Original Message-----
From: Chen, Weijing [mailto:wchen@tri.sbc.com]
Sent: 18 January 2002 16:12
To: 'dick.rr.knight@bt.com'; Schneider, Marco;
Georgios.Karagiannis@eln.ericsson.se
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements (priority on the boundary
be tween a customer and the network)


Sorry, previous picture is garbled by mailer. 


[host]<--1--[hop]-->[edge]<---2---[hop]-->[edge]<--1--[hop]-->[host]

[host]<-------------------3------------------------------------------------>
[host]


The 3 is our goal and is comprised of 1 and 2. As we know, there are
solutions for 2 (MPLS, DiffServ, PNNI, over-provisioning, etc). What we need
to solve is the 1.  Now what about translation (or mapping) between 1 and 2?
Do we need to standardize it?  If yes, where? In NSIS group or elsewhere?

Regardless, the objective of 1 is KISS and universal. The complexity of 1
and 2 mapping must be born by the [edge].



--
Weijing Chen
SBC Technology Resources
9505 Arboretum Blvd.
Austin, TX 78759
512 372 5710
wchen@tri.sbc.com



 -----Original Message-----
From: 	dick.rr.knight@bt.com [mailto:dick.rr.knight@bt.com] 
Sent:	Friday, January 18, 2002 5:12 AM
To:	Schneider, Marco; Georgios.Karagiannis@eln.ericsson.se;
dick.rr.knight@bt.com
Cc:	nsis@ietf.org
Subject:	RE: [NSIS] Two kinds of requirements (priority on the
boundary be tween a customer and the network)


I do not agree.

What is the point of completing the work enabling the customer to signal to
the network, if the network cannot signal between domains? The network can
never satisfy the request.

Dick

-----Original Message-----
From: Schneider, Marco [mailto:schneider@tri.sbc.com]
Sent: 18 January 2002 01:44
To: 'Georgios Karagiannis (ELN)'; 'dick.rr.knight@bt.com'
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


Hi Georgios,

While I agree NSIS could be used to support Interior to Interior (of one
carrier) or Edge to Core, I think that we need to prioritize on a signaling
protocol across the boundary between a customer and the network. Note that
the customer could be an individual, an ISP or another Carrier.

Marco Schneider

-----Original Message-----
From: Georgios Karagiannis (ELN)
[mailto:Georgios.Karagiannis@eln.ericsson.se]
Sent: Thursday, January 17, 2002 3:39 AM
To: 'dick.rr.knight@bt.com'
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


Hi Dick 

In principle I agree with your comment (see below).

[DK] >> To be more precise, I am suggesting a new protocol that is 
[DK] >> independent of the underlying transport technology and the QoS 
[DK] >> implemented and is also independent of the session control protocol.


However, a very important point here is that we need to 
specify a protocol that can be used independent of the underlying transport 
technology, but that can satisfy the QoS requirements imposed by these 
underlying transport technologies. Otherwise the protocol will not be
suitable
and useful.

A way of achieving this is by first creating a modular QoS signaling toolkit

that will contain mandatory and optional QoS requirements;
Second, specify how the protocol functionality should be separated in 
building blocks (protocol components) and define a minimum set 
of mandatory reservation options/features that should be 
processed by any network nodes, e.g., end-hosts,
proxies, edges and interior nodes.
An example of such a protocol decomposition is given below!
In this way each node will only process (check and use) the protocol 
components of interest.


|---------|
|---------|
|everyhost|<------------------------------------------------------->|everyho
st|
|---------|
|---------|
|         |                                                         |
|
|---------|   |---------|                             |---------|
|---------|
|everyedge|<->|everyedge|<--------------------------->|everyedge|<->|everyed
ge|
|---------|   |---------|                             |---------|
|---------|
|         |   |         |                             |         |   |
|
|---------|   |---------|   |--------|   |--------|   |---------|
|---------|
|everyhop |<->|everyhop |<->|everyhop|<->|everyhop|<->|everyhop
|<->|everyhop |
|---------|   |---------|   |--------|   |--------|   |---------|
|---------| 
    host          edge        interior    interior       edge          host


  NSIS protocol decomposition (building blocks): 
 *  "everyhost", "everyedge" and "everyhop" are protocol components;
 *  host: can be an end-host or a proxy and it can process and use the
"everyhost", 
    "everyedge", and "everyhop" protocol components;

 *  edge: can be a Diffserv edge, MPLS edge, etc., and it can process and
use 
    the "everyedge", and "everyhop" protocol components. The "everyhost" 
    protocol component is not processed (used or checked);

 *  interior: can be any router within a domain and it can process and use 
    only the "everyhop" protocol component.
    The "everyhost" and "everyedge" protocol components are not 
    processed (used or checked);


Best Regards,
Georgios

-----Original Message-----
From: dick.rr.knight@bt.com [mailto:dick.rr.knight@bt.com]
Sent: woensdag 16 januari 2002 13:00
To: brian.williams@ericsson.com.au; lieve.bos@alcatel.be
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


I was waiting for some reaction to Brian's comments, but as there aren't
any, here are my thoughts on the requirements:

I agree with the analysis that discussion has been based around
application-related signalling for QoS (at session level) and QoS signalling
protocols used to actually provision the QoS at the transport level.
Brian is right that there will never be an enhancement to a single session
protocol that will satisfy all applications.
However, for similar reasons, it is never going to be possible to prescribe
a single QoS mechanism to be used in all networks. Existing networks (or
domains) will not be changed overnight and new networks already face several
workable mechanisms to deploy QoS.

I think that what is needed is a new protocol that can signal the
requirements of any session and can be satisfied by any QoS mechanism,
existing or new.
To be more precise, I am suggesting a new protocol that is independent of
the underlying transport technology and the QoS implemented and is also
independent of the session control protocol. Such a new protocol would be
generic, optionally implemented by applications that would benefit from
end-to-end QoS, and would be complimentary to the QoS mechanisms deployed
(and of course other mechanisms, such as the routing).

I think that this implies a more abstract definition of the QoS mechanism
and may lend itself to the signalling of pre-defined QoS classes rather than
parameters.

Dick Knight

-----Original Message-----
From: Brian Williams [mailto:brian.williams@ericsson.com.au]
Sent: 22 December 2001 23:57
To: lieve.bos@alcatel.be
Cc: nsis@ietf.org
Subject: Re: [NSIS] Two kinds of requirements


Hi.
While the two types of signalling may be related, I think there is a
need to develop a QoS bearer mechanism which is independent of any
specific session signalling, and thus can be used for any application. I
believe many of the applications which have identified requirements to
the working group have their own specific session layer signalling (ie
it is not end-to-end SIP).  

Having the session and transport protocols developed separately of
course does not prohibit the two being used in conjunction for a
specific application.
/brian
 
On Fri, 2001-12-21 at 22:24, lieve.bos@alcatel.be wrote:
> Hello all,
> 
> >From the discussion in Salt Lake city and the drafts submitted, one can
> easily see that people are suggesting improvements to QoS signalling at
> two totally different levels (some at session level and some at
> transport level).
> 
> First of all, there are drafts suggesting some improvements in the
> session setup procedures (i.e. the ability to negotiate the preferred
> QoS level between end users during SDP negotiation in SIP, so before the
> actual resources are being setup). The QoS information negotiated at the
> session layer determines the QoS level both endusers have to use for 
> their local access connection. This first kind of 'session level QoS
> negotiation' happens end-to-end between the two end-users.
> 
> Secondly, there are drafts suggesting that we need
> improvements/alternatives for the QoS signalling protocols (e.g. RSVP)
> used to actually provision the QoS at the transport level between two
> endusers. This second kind of 'transport level QoS signalling' can
> consist of several phases: end-to-edge and edge-to-edge. 
> 
> It's important that everybody realises that, in order to give endusers
> true end-to-end Quality of Service, we need improvements for QoS both at
> session and transport level. Also its important to understand that they
> are not uncorrelated. Providers want to be able to control (e.g. via
> policy control mechanisms) that the QoS requested at the transport level
> is not exceeding the QoS negotiated/authorised previously at session
> level. So, what about developing in NSIS a modular framework
> incorporating both session and transport level QoS signalling with
> possible hooks between the two layers (e.g. for policy enforcement).
> 
> Lieve
> 
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis



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

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

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

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

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

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

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



From daemon@ns.ietf.org  Fri Jan 18 15:23: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 PAA25761
	for <nsis-archive@odin.ietf.org>; Fri, 18 Jan 2002 15:23:05 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id PAA02823
	for nsis-archive@odin.ietf.org; Fri, 18 Jan 2002 15:23: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 PAA02435;
	Fri, 18 Jan 2002 15:10: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 PAA02388
	for <nsis@ns.ietf.org>; Fri, 18 Jan 2002 15:10:13 -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 PAA25423
	for <nsis@ietf.org>; Fri, 18 Jan 2002 15:10:08 -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 g0IKBlT20123;
	Fri, 18 Jan 2002 14:11:47 -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 g0IK98C11817;
	Fri, 18 Jan 2002 14:09:08 -0600 (CST)
Received: by TRIMAIL2.ad.tri.sbc.com with Internet Mail Service (5.5.2653.19)
	id <ZND32M94>; Fri, 18 Jan 2002 14:09:35 -0600
Message-ID: <905A1C4ABF353F4C8CC16FA9F53DD0D638B9A1@TRIMAIL2.ad.tri.sbc.com>
From: "Schneider, Marco" <schneider@tri.sbc.com>
To: "'Roy, Radhika R, ALASO'" <rrroy@att.com>,
        Gary Kenward
	 <gkenward@nortelnetworks.com>,
        "Loughney John (NRC/Helsinki)"
	 <john.loughney@nokia.com>,
        brunner@ccrle.nec.de, Yaron Kahana
	 <ykahana@comgates.co.il>,
        "Geib, Ruediger" <Ruediger.Geib@t-systems.com>, dick.rr.knight@bt.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements
Date: Fri, 18 Jan 2002 14:09:30 -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 Roy,

Below is the original text from your reponse to Gary Kenward. Hopefully the
context is clear.

"[Roy, Radhika R, ALARC]  I would say that it is the QOS needs of the
application (e.g., SIP-based VoIP) that the user likes to express (as
opposed to "service"). Similarly, instead of network services, we would say
network layer QOS services (e.g., RSVP, DiffServ, MPLS). We would develop
the end-to-end (application layer) QOS signaling protocol (say, NSIS QOS).
Now, there needs to have some kinds of standards how NSIS QOS will be mapped
over RSVP, DiffServ, MPLS, etc."

So by End-to-End you mean between directly between two "users". This is
session level signaling and I don't believe the signaling part is within the
scope of this working group. An application level QOS specification may be. 

After a session level agreement on QOS, the host/client/customer will need
to signal an actual reservation request to the network for the necessary QOS
agreed to at the session level. This is the protocol that we need to work
on. 

This approach is discussed in the SIP draft "SIP Extensions for Media
Authorization" (draft-ietf-sip-call-auth-03.txt) and the RAP draft
"Framework for session set-up with media authorization"
(draft-ietf-rap-session-auth-02.txt).

Marco Schneider

-----Original Message-----
From: Roy, Radhika R, ALASO [mailto:rrroy@att.com]
Sent: Friday, January 18, 2002 9:18 AM
To: Schneider, Marco; Gary Kenward; Loughney John (NRC/Helsinki);
brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
dick.rr.knight@bt.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


Defined below [RRR]

-----Original Message-----
From: Schneider, Marco [mailto:schneider@tri.sbc.com]
Sent: Thursday, January 17, 2002 8:47 PM
To: Roy, Radhika R, ALASO; Gary Kenward; Loughney John (NRC/Helsinki);
brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
dick.rr.knight@bt.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


Hi Roy,

Can you please define what you mean by "End-to-End Application Layer QOS
Signaling". Thanks.

[RRR] Suppose an user is initiation a SIP call to another user with audio,
video, and data. The use needs to express the needs of QOS for audio, video,
and data to another user. 

[RRR] The signaling mechanism that allows to express the QOS parameters of
audio, video, and data is termed as the "End-to-End Application Layer QOS
Signaling."

Marco Schneider

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



From daemon@optimus.ietf.org  Sat Jan 19 14:35: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 OAA21957
	for <nsis-archive@odin.ietf.org>; Sat, 19 Jan 2002 14:35:37 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id OAA15767
	for nsis-archive@odin.ietf.org; Sat, 19 Jan 2002 14:35: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 OAB15303;
	Sat, 19 Jan 2002 14:26: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 OAA15235
	for <nsis@optimus.ietf.org>; Sat, 19 Jan 2002 14:26:35 -0500 (EST)
Received: from mail-server.comgates.co.il ([212.150.198.2])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21759
	for <nsis@ietf.org>; Sat, 19 Jan 2002 14:26:26 -0500 (EST)
Received: by mail-server.comgates.co.il with Internet Mail Service (5.5.2653.19)
	id <DC2CZZA4>; Sat, 19 Jan 2002 21:26:48 +0200
Message-ID: <6FEF757325DBD411B7DA000629A8A61E9AC650@mail-server.comgates.co.il>
From: Yaron Kahana <ykahana@comgates.co.il>
To: Gary Kenward <gkenward@nortelnetworks.com>,
        "'dick.rr.knight@bt.com'"
	 <dick.rr.knight@bt.com>,
        gilbert@rsch.comm.mot.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] Support needed for Throughput Adaptive QoS in wireless
Date: Sat, 19 Jan 2002 21:26:44 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C1A11F.3A8C0EC0"
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_01C1A11F.3A8C0EC0
Content-Type: text/plain;
	charset="iso-8859-1"

Hi all,
 
I think that the describe situation is:
1) NOT unique to the mobile case.
2) Should be handled by a "higher hierarchy".
 
I think that the described example is the derivative of unpredictable over
loading of resources, and is rather common (for example through Erlang
distribution?). The mobile case, with its relative high dynamic users, can
still perform the correct network planning work to handle such cases. The
NGN, whereas the users will have their services linked to their "entity" and
not to their landline, will have to deal with it as well.
 
I also think that the solution of over loading should be managed by a local
"higher hierarchy" and not by the End-to-End reservation. This local service
controller should be aware of the sessions, users, resources and
commitments. Hence could decide a "re-negotiation" or a drop. Think about
the case that there is an emergency call in the cell (911) and it is being
dropped or degraded?
 
I'm not sure this is within NSIS scope, but this service controller
(softswitch?) should be aware of the resources reservation and should manage
the allocation of resources and admission control (see TIPHON
DTS02009v044.doc).
 
Best Regards,
 
Yaron Kahana
COGITO Project Manager
COMGATES
www.comgates.com <http://www.comgates.com> 
 
 

-----Original Message-----
From: Gary Kenward [mailto:gkenward@nortelnetworks.com]
Sent: Friday, January 18, 2002 7:31 PM
To: 'dick.rr.knight@bt.com'; gilbert@rsch.comm.mot.com; nsis@ietf.org
Subject: RE: [NSIS] Support needed for Throughput Adaptive QoS in wireless



Steve: 

  I don't believe that Dick is proposing that NSIS accomodate 
rate adaption, I believe that the issue is QoS re-negotiation 
to allow better handoff performance. 
  
  The situation is simply that if the admission control used 
during a handoff is "all or nothing" then the likelihood the 
flows of the mobile user will be dropped when a handoff occurs is 
much higher. "Re-negotiation" of QoS allows the network to reduce 
the resource demands to the point that the new access router 
can handle the flows, at least to some degree. 

  Re-negotiation can mean many different solution scenarios. 
At the extremes, the solution could be an NSIS negotiation 
protocol between mobile and access network; a "minimum" QoS 
that the network that is allowed as a fallback to allow the 
handoff to occur. Note that in either case, the result may 
mean dropping of specific flows that cannot be support (e.g. 
the video portion of a multimedia session). 

The second scenario does not necessarly require interaction 
with the mobile or other networks and thus may 
not impact NSIS.  However, it might be a good thing for the 
network to tell the mobile that the QoS had been degraded, 
thus allowing the mobile application to "adapt". NSIS does not 
need to participate in the adaption, it would simply provide 
the information on the new QoS. 

I think the requirement here is for the NSIS wg to consider 
all the options. 

Gary 


> -----Original Message----- 
> From: dick.rr.knight@bt.com [ mailto:dick.rr.knight@bt.com
<mailto:dick.rr.knight@bt.com> ] 
> Sent: January 18, 2002 11:51 
> To: gilbert@rsch.comm.mot.com; nsis@ietf.org 
> Subject: RE: [NSIS] Support needed for Throughput Adaptive QoS in 
> wireless 
> 
> 
> 
> There are some important points in this email. Probably 
> obvious for people 
> with wireless backgrounds, but a bit more of a surprise for wired 
> backgrounds. 
> 
> I personally don't see NSIS as trying to solve the rate 
> adaptation needs of 
> the wireless access network. I can see that it is very much 
> needed, but it 
> is rather more specialised than a generic signalling protocol for QoS 
> requests. This looks like a charter debate. 
> 
> The wireless access network definitely needs some QoS 
> signalling support, 
> but as you have shown, it is specific to the technology and 
> the mobility 
> service. 
> 
> Dick 
> 
> -----Original Message----- 
> From: Steve Gilbert [ mailto:gilbert@rsch.comm.mot.com
<mailto:gilbert@rsch.comm.mot.com> ] 
> Sent: 18 January 2002 16:21 
> To: nsis@ietf.org 
> Subject: [NSIS] Support needed for Throughput Adaptive QoS in wireless 
> 
> 
> 
> 
> I tend to agree with the need which Herman identifies (below) 
> for throughput 
> adaptive capabilities in a wireless QoS system. 
> 
> The cellular wireless QoS problem is very different than that 
> of wired QoS 
> because of the need to handle the case of a user with a QoS 
> "guarantee" 
> handing 
> off into a different cell.  In the worst case, the cell which 
> it is entering 
> may 
> have its resources fully allocated to existing users. 
> Dropping the session 
> of 
> the user being handed off is not a good idea. This points out 
> the need for 
> some 
> rational way to accommodate such calls. The approach taken in 
> some wireless 
> voice systems is to reserve resources for use only by 
> sessions which are 
> handing 
> off into the cell. This may suffice if the resource needs of 
> the hand off 
> session are predictable. However, in a system in which arbitrary 
> applications 
> can utilize a wide range of throughput values, reserving 
> enough capacity to 
> handle the range of throughputs which could potentially be needed by a 
> single 
> flow may not be practical. 
> 
> What is needed is the use of throughput adaptive applications and the 
> ability 
> for a traffic flow to express its QoS preferences with regard to the 
> throughput 
> values which it may be allocated. Upon handing off into the 
> new cell, the 
> QoS 
> preferences of the handoff traffic flow and of the existing 
> traffic flows in 
> that cell would be considered and resources reallocated to 
> best meet their 
> preferences. Some of the existing traffic flows may have 
> their throughput 
> allocations reduced in order to free up resources to be 
> allocated to the 
> handoff 
> traffic flow. 
> 
> The QoS signaling needs of this approach include the ability 
> of the system 
> to 
> notify traffic flows of their new allocations, and the 
> ability for a new 
> traffic 
> flow requesting "admission" to express its QoS preferences, 
> possibly in 
> terms of 
> a list of throughput values and the benefit it receives from each. A 
> non-adaptive real-time application would indicate a single 
> throughput value 
> which it desires rather than a list of throughput values. 
> 
> One could argue that this provides no throughput "guarantee" 
> and changes 
> what it 
> means to have a QoS request "admitted". This is true. But in 
> wireless, it is 
> difficult and sometimes impractical to provide the same QoS 
> guarantees that 
> could be provided in a wireline system which doesn't have to deal with 
> handoff. In a wireless system, there is the possibility that 
> the user will 
> drive 
> into a tunnel or take the elevator to a sub-basement of a 
> building where the 
> wireless signal is lost. Radio coverage and QoS can not be 
> guaranteed under 
> all 
> possible situations.  Wireless channel resources are often 
> more scarce or 
> expensive than those of a wired channel. This generally results in the 
> motivation to utilize them more efficiently. What is more 
> realistic than 
> trying 
> to provide wireless QoS identical to that of wire-line is to 
> come up with a 
> useful approach for "QoS management" and "resource 
> allocation" which can be 
> applied in a wireless system. 
> 
> If efficient utilization of the resources by QoS flows is not a major 
> concern, 
> the QoS of admitted users could be increased (or at least 
> made less prone to 
> reductions) through over-provisioning or preventing admission 
> of new calls 
> even 
> when the level of congestion is still low. The resources not 
> guaranteed to 
> QoS 
> traffic flows could be used by best effort traffic. Systems 
> with significant 
> best effort traffic would be able to increase the overall 
> utilization of the 
> channel without negatively effecting QoS traffic flows. 
> 
> Steve 
> 
> 
> 
> > Date: Thu, 17 Jan 2002 19:49:13 +0000 
> > To: "Georgios Karagiannis (ELN)" 
> <Georgios.Karagiannis@eln.ericsson.se>, 
> >    "'Loughney John (NRC/Helsinki)'" <john.loughney@nokia.com>, 
> >    "'ext Kappler Cornelia'" <Cornelia.Kappler@icn.siemens.de> 
> > From: Hermann De Meer <h.demeer@ee.ucl.ac.uk> 
> > Cc: <nsis@ietf.org> 
> > Subject: RE: [NSIS] Two kinds of requirements 
> > 
> > Hi Georgios and all 
> > 
> > At 14:09 17/01/2002 +0100, Georgios Karagiannis (ELN) wrote: 
> > >Hi John and Cornelia 
> > > 
> > >I think that one of the requirements that should be included 
> > >in the NSIS WG requirements document is that the NSIS protocol 
> > >should be modular. Modular in the context of having 
> > >a toolkit from which one can choose the applicable tools 
> > >in order to manage QoS in a particular networking environment. 
> > 
> > I believe you are raising a very important issue with the 
> emphasis on 
> > modularity 
> > of QoS architectures/signalling. 
> > 
> > But one can generalize that: it's all about flexibility, 
> > namely flexibility of signalling/control/provisioning vs. 
> flexibility of 
> > applications/users. 
> > 
> > Flexibility does not necessarily mean complexity, often on 
> the contrary: 
> > one side being flexible makes the life for the other side 
> easier (think of 
> 
> > airline ticket pricing: 
> > the price for the *same seat* can vary in an order of 
> magnitude simply 
> > depending on how flexible you are!) 
> > 
> > QoS signalling is about indicating of how "inflexible" you 
> are from that 
> > perspective. 
> > But looking at IntServ (RSVP) or DiffServ,  an 
> interpretation of these 
> signals 
> > have traditionally been seen rather statically: 
> > 
> > - a "one-size-fits-all"  "end-to-end" implementation of the 
> mechanisms 
> > - a "take-it-or-leave-it" approach: statically defined QoS classes. 
> > 
> > this makes QoS provisioning cumbersome, complex, expensive 
> (unnecessarily) 
> > (and it may be a good deal the reason for the 
> "failure/insufficiency" of 
> > current QoS solutions/ 
> > signalling techniques). 
> > 
> > Remember, the success of IP networking has to a larger 
> extend been due to 
> > the fact of 
> > relying on flexibility and cooperation, for example, for congestion 
> handling. 
> > (or "exception" handling, if you want, by TCP-similar schemes) 
> > 
> > in <draft-demeer-nsis-analyis-00.txt> we therefore make a 
> point to extend 
> > QoS signalling for: 
> > 
> > 1) explicitly dealing with such "QoS exceptions" (there is also an 
> economic 
> > argument for this) 
> >      that is, not only signaling QoS preferences from 
> applications to the 
> > network, but also 
> >      QoS exceptions back from networks to applications or to between 
> networks, 
> >      and an expected cooperative adaptation. 
> > 
> > 2) allowing for flexible interpretations in different 
> domains (core, 
> > access, mobile, wireless, 
> >       administrative conditions, ....) 
> > 
> > 
> > The "trick" may be to modify signalling (including RSVP) 
> such that most 
> > flexibility/cooperation 
> > can be re-gained by assuring a minimum support of inflexibility 
> > (intentionally not using the 
> > the term QoS guarantee here). 
> > 
> > 
> > --Hermann 
> > 
> ... 
> 
> _______________________________________________ 
> nsis mailing list 
> nsis@ietf.org 
> https://www1.ietf.org/mailman/listinfo/nsis
<https://www1.ietf.org/mailman/listinfo/nsis>  
> 
> _______________________________________________ 
> nsis mailing list 
> nsis@ietf.org 
> https://www1.ietf.org/mailman/listinfo/nsis
<https://www1.ietf.org/mailman/listinfo/nsis>  
> 


------_=_NextPart_001_01C1A11F.3A8C0EC0
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">
<TITLE>RE: [NSIS] Support needed for Throughput Adaptive QoS in wireless</TITLE>

<META content="MSHTML 6.00.2600.0" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=439490919-19012002>Hi 
all,</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=439490919-19012002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=439490919-19012002>I 
think that the describe situation is:</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=439490919-19012002>1) NOT 
unique to the mobile case.</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=439490919-19012002>2) 
Should be&nbsp;handled by a "higher hierarchy".</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=439490919-19012002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=439490919-19012002>I 
think that the described example is the derivative of unpredictable over loading 
of resources, and&nbsp;is&nbsp;rather common (for example through Erlang 
distribution?). The mobile case, with its relative high dynamic users, can still 
perform the correct network planning work to handle such cases. The NGN, whereas 
the users will have their services linked to their "entity" and not to their 
landline, will have to deal with it as well.</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=439490919-19012002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=439490919-19012002>I also 
think that the solution of over loading should be managed by a local "higher 
hierarchy" and not by the End-to-End reservation. This local service controller 
should be aware of the sessions, users, resources and commitments. Hence could 
decide a "re-negotiation" or a drop. Think about the case that there is an 
emergency call in the cell (911) and it is being dropped or 
degraded?</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=439490919-19012002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=439490919-19012002>I'm 
not sure this is within NSIS scope, but this service controller (softswitch?) 
should be aware of the resources&nbsp;reservation and should manage the 
allocation of resources and admission control (see TIPHON 
DTS02009v044.doc).</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=439490919-19012002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=439490919-19012002>Best 
Regards,</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=439490919-19012002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=439490919-19012002>Yaron 
Kahana</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=439490919-19012002>COGITO 
Project Manager</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=439490919-19012002>COMGATES</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=439490919-19012002><A 
href="http://www.comgates.com">www.comgates.com</A></SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=439490919-19012002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=439490919-19012002></SPAN></FONT>&nbsp;</DIV>
<BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Gary Kenward 
  [mailto:gkenward@nortelnetworks.com]<BR><B>Sent:</B> Friday, January 18, 2002 
  7:31 PM<BR><B>To:</B> 'dick.rr.knight@bt.com'; gilbert@rsch.comm.mot.com; 
  nsis@ietf.org<BR><B>Subject:</B> RE: [NSIS] Support needed for Throughput 
  Adaptive QoS in wireless<BR><BR></FONT></DIV>
  <P><FONT size=2>Steve:</FONT> </P>
  <P><FONT size=2>&nbsp; I don't believe that Dick is proposing that NSIS 
  accomodate </FONT><BR><FONT size=2>rate adaption, I believe that the issue is 
  QoS re-negotiation </FONT><BR><FONT size=2>to allow better handoff 
  performance.</FONT> <BR><FONT size=2>&nbsp;</FONT> <BR><FONT size=2>&nbsp; The 
  situation is simply that if the admission control used</FONT> <BR><FONT 
  size=2>during a handoff is "all or nothing" then the likelihood the</FONT> 
  <BR><FONT size=2>flows of the mobile user will be dropped when a handoff 
  occurs is </FONT><BR><FONT size=2>much higher. "Re-negotiation" of QoS allows 
  the network to reduce</FONT> <BR><FONT size=2>the resource demands to the 
  point that the new access router </FONT><BR><FONT size=2>can handle the flows, 
  at least to some degree.</FONT> </P>
  <P><FONT size=2>&nbsp; Re-negotiation can mean many different solution 
  scenarios.</FONT> <BR><FONT size=2>At the extremes, the solution could be an 
  NSIS negotiation </FONT><BR><FONT size=2>protocol between mobile and access 
  network; a "minimum" QoS </FONT><BR><FONT size=2>that the network that is 
  allowed as a fallback to allow the </FONT><BR><FONT size=2>handoff to occur. 
  Note that in either case, the result may</FONT> <BR><FONT size=2>mean dropping 
  of specific flows that cannot be support (e.g.</FONT> <BR><FONT size=2>the 
  video portion of a multimedia session).</FONT> </P>
  <P><FONT size=2>The second scenario does not necessarly require interaction 
  </FONT><BR><FONT size=2>with the mobile or other networks and thus may</FONT> 
  <BR><FONT size=2>not impact NSIS.&nbsp; However, it might be a good thing for 
  the</FONT> <BR><FONT size=2>network to tell the mobile that the QoS had been 
  degraded,</FONT> <BR><FONT size=2>thus allowing the mobile application to 
  "adapt". NSIS does not</FONT> <BR><FONT size=2>need to participate in the 
  adaption, it would simply provide</FONT> <BR><FONT size=2>the information on 
  the new QoS.</FONT> </P>
  <P><FONT size=2>I think the requirement here is for the NSIS wg to 
  consider</FONT> <BR><FONT size=2>all the options.</FONT> </P>
  <P><FONT size=2>Gary</FONT> </P><BR>
  <P><FONT size=2>&gt; -----Original Message-----</FONT> <BR><FONT size=2>&gt; 
  From: dick.rr.knight@bt.com [<A 
  href="mailto:dick.rr.knight@bt.com">mailto:dick.rr.knight@bt.com</A>]</FONT> 
  <BR><FONT size=2>&gt; Sent: January 18, 2002 11:51</FONT> <BR><FONT 
  size=2>&gt; To: gilbert@rsch.comm.mot.com; nsis@ietf.org</FONT> <BR><FONT 
  size=2>&gt; Subject: RE: [NSIS] Support needed for Throughput Adaptive QoS 
  in</FONT> <BR><FONT size=2>&gt; wireless</FONT> <BR><FONT size=2>&gt; 
  </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT 
  size=2>&gt; There are some important points in this email. Probably 
  </FONT><BR><FONT size=2>&gt; obvious for people</FONT> <BR><FONT size=2>&gt; 
  with wireless backgrounds, but a bit more of a surprise for wired</FONT> 
  <BR><FONT size=2>&gt; backgrounds.</FONT> <BR><FONT size=2>&gt; 
  </FONT><BR><FONT size=2>&gt; I personally don't see NSIS as trying to solve 
  the rate </FONT><BR><FONT size=2>&gt; adaptation needs of</FONT> <BR><FONT 
  size=2>&gt; the wireless access network. I can see that it is very much 
  </FONT><BR><FONT size=2>&gt; needed, but it</FONT> <BR><FONT size=2>&gt; is 
  rather more specialised than a generic signalling protocol for QoS</FONT> 
  <BR><FONT size=2>&gt; requests. This looks like a charter debate.</FONT> 
  <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; The wireless access network 
  definitely needs some QoS </FONT><BR><FONT size=2>&gt; signalling 
  support,</FONT> <BR><FONT size=2>&gt; but as you have shown, it is specific to 
  the technology and </FONT><BR><FONT size=2>&gt; the mobility</FONT> <BR><FONT 
  size=2>&gt; service.</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; 
  Dick</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; -----Original 
  Message-----</FONT> <BR><FONT size=2>&gt; From: Steve Gilbert [<A 
  href="mailto:gilbert@rsch.comm.mot.com">mailto:gilbert@rsch.comm.mot.com</A>]</FONT> 
  <BR><FONT size=2>&gt; Sent: 18 January 2002 16:21</FONT> <BR><FONT size=2>&gt; 
  To: nsis@ietf.org</FONT> <BR><FONT size=2>&gt; Subject: [NSIS] Support needed 
  for Throughput Adaptive QoS in wireless</FONT> <BR><FONT size=2>&gt; 
  </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT 
  size=2>&gt; </FONT><BR><FONT size=2>&gt; I tend to agree with the need which 
  Herman identifies (below) </FONT><BR><FONT size=2>&gt; for throughput</FONT> 
  <BR><FONT size=2>&gt; adaptive capabilities in a wireless QoS system.</FONT> 
  <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; The cellular wireless QoS 
  problem is very different than that </FONT><BR><FONT size=2>&gt; of wired 
  QoS</FONT> <BR><FONT size=2>&gt; because of the need to handle the case of a 
  user with a QoS </FONT><BR><FONT size=2>&gt; "guarantee"</FONT> <BR><FONT 
  size=2>&gt; handing</FONT> <BR><FONT size=2>&gt; off into a different 
  cell.&nbsp; In the worst case, the cell which </FONT><BR><FONT size=2>&gt; it 
  is entering</FONT> <BR><FONT size=2>&gt; may</FONT> <BR><FONT size=2>&gt; have 
  its resources fully allocated to existing users. </FONT><BR><FONT size=2>&gt; 
  Dropping the session</FONT> <BR><FONT size=2>&gt; of</FONT> <BR><FONT 
  size=2>&gt; the user being handed off is not a good idea. This points out 
  </FONT><BR><FONT size=2>&gt; the need for</FONT> <BR><FONT size=2>&gt; 
  some</FONT> <BR><FONT size=2>&gt; rational way to accommodate such calls. The 
  approach taken in </FONT><BR><FONT size=2>&gt; some wireless</FONT> <BR><FONT 
  size=2>&gt; voice systems is to reserve resources for use only by 
  </FONT><BR><FONT size=2>&gt; sessions which are</FONT> <BR><FONT size=2>&gt; 
  handing</FONT> <BR><FONT size=2>&gt; off into the cell. This may suffice if 
  the resource needs of </FONT><BR><FONT size=2>&gt; the hand off</FONT> 
  <BR><FONT size=2>&gt; session are predictable. However, in a system in which 
  arbitrary</FONT> <BR><FONT size=2>&gt; applications</FONT> <BR><FONT 
  size=2>&gt; can utilize a wide range of throughput values, reserving 
  </FONT><BR><FONT size=2>&gt; enough capacity to</FONT> <BR><FONT size=2>&gt; 
  handle the range of throughputs which could potentially be needed by a</FONT> 
  <BR><FONT size=2>&gt; single</FONT> <BR><FONT size=2>&gt; flow may not be 
  practical.</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; What is 
  needed is the use of throughput adaptive applications and the</FONT> <BR><FONT 
  size=2>&gt; ability</FONT> <BR><FONT size=2>&gt; for a traffic flow to express 
  its QoS preferences with regard to the</FONT> <BR><FONT size=2>&gt; 
  throughput</FONT> <BR><FONT size=2>&gt; values which it may be allocated. Upon 
  handing off into the </FONT><BR><FONT size=2>&gt; new cell, the</FONT> 
  <BR><FONT size=2>&gt; QoS</FONT> <BR><FONT size=2>&gt; preferences of the 
  handoff traffic flow and of the existing </FONT><BR><FONT size=2>&gt; traffic 
  flows in</FONT> <BR><FONT size=2>&gt; that cell would be considered and 
  resources reallocated to </FONT><BR><FONT size=2>&gt; best meet their</FONT> 
  <BR><FONT size=2>&gt; preferences. Some of the existing traffic flows may have 
  </FONT><BR><FONT size=2>&gt; their throughput</FONT> <BR><FONT size=2>&gt; 
  allocations reduced in order to free up resources to be </FONT><BR><FONT 
  size=2>&gt; allocated to the</FONT> <BR><FONT size=2>&gt; handoff</FONT> 
  <BR><FONT size=2>&gt; traffic flow.</FONT> <BR><FONT size=2>&gt; 
  </FONT><BR><FONT size=2>&gt; The QoS signaling needs of this approach include 
  the ability </FONT><BR><FONT size=2>&gt; of the system</FONT> <BR><FONT 
  size=2>&gt; to</FONT> <BR><FONT size=2>&gt; notify traffic flows of their new 
  allocations, and the </FONT><BR><FONT size=2>&gt; ability for a new</FONT> 
  <BR><FONT size=2>&gt; traffic</FONT> <BR><FONT size=2>&gt; flow requesting 
  "admission" to express its QoS preferences, </FONT><BR><FONT size=2>&gt; 
  possibly in</FONT> <BR><FONT size=2>&gt; terms of</FONT> <BR><FONT size=2>&gt; 
  a list of throughput values and the benefit it receives from each. A</FONT> 
  <BR><FONT size=2>&gt; non-adaptive real-time application would indicate a 
  single </FONT><BR><FONT size=2>&gt; throughput value</FONT> <BR><FONT 
  size=2>&gt; which it desires rather than a list of throughput values.</FONT> 
  <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; One could argue that this 
  provides no throughput "guarantee" </FONT><BR><FONT size=2>&gt; and 
  changes</FONT> <BR><FONT size=2>&gt; what it</FONT> <BR><FONT size=2>&gt; 
  means to have a QoS request "admitted". This is true. But in </FONT><BR><FONT 
  size=2>&gt; wireless, it is</FONT> <BR><FONT size=2>&gt; difficult and 
  sometimes impractical to provide the same QoS </FONT><BR><FONT size=2>&gt; 
  guarantees that</FONT> <BR><FONT size=2>&gt; could be provided in a wireline 
  system which doesn't have to deal with</FONT> <BR><FONT size=2>&gt; handoff. 
  In a wireless system, there is the possibility that </FONT><BR><FONT 
  size=2>&gt; the user will</FONT> <BR><FONT size=2>&gt; drive</FONT> <BR><FONT 
  size=2>&gt; into a tunnel or take the elevator to a sub-basement of a 
  </FONT><BR><FONT size=2>&gt; building where the</FONT> <BR><FONT size=2>&gt; 
  wireless signal is lost. Radio coverage and QoS can not be </FONT><BR><FONT 
  size=2>&gt; guaranteed under</FONT> <BR><FONT size=2>&gt; all</FONT> <BR><FONT 
  size=2>&gt; possible situations.&nbsp; Wireless channel resources are often 
  </FONT><BR><FONT size=2>&gt; more scarce or</FONT> <BR><FONT size=2>&gt; 
  expensive than those of a wired channel. This generally results in the</FONT> 
  <BR><FONT size=2>&gt; motivation to utilize them more efficiently. What is 
  more </FONT><BR><FONT size=2>&gt; realistic than</FONT> <BR><FONT size=2>&gt; 
  trying</FONT> <BR><FONT size=2>&gt; to provide wireless QoS identical to that 
  of wire-line is to </FONT><BR><FONT size=2>&gt; come up with a</FONT> 
  <BR><FONT size=2>&gt; useful approach for "QoS management" and "resource 
  </FONT><BR><FONT size=2>&gt; allocation" which can be</FONT> <BR><FONT 
  size=2>&gt; applied in a wireless system.</FONT> <BR><FONT size=2>&gt; 
  </FONT><BR><FONT size=2>&gt; If efficient utilization of the resources by QoS 
  flows is not a major</FONT> <BR><FONT size=2>&gt; concern,</FONT> <BR><FONT 
  size=2>&gt; the QoS of admitted users could be increased (or at least 
  </FONT><BR><FONT size=2>&gt; made less prone to</FONT> <BR><FONT size=2>&gt; 
  reductions) through over-provisioning or preventing admission </FONT><BR><FONT 
  size=2>&gt; of new calls</FONT> <BR><FONT size=2>&gt; even</FONT> <BR><FONT 
  size=2>&gt; when the level of congestion is still low. The resources not 
  </FONT><BR><FONT size=2>&gt; guaranteed to</FONT> <BR><FONT size=2>&gt; 
  QoS</FONT> <BR><FONT size=2>&gt; traffic flows could be used by best effort 
  traffic. Systems </FONT><BR><FONT size=2>&gt; with significant</FONT> 
  <BR><FONT size=2>&gt; best effort traffic would be able to increase the 
  overall </FONT><BR><FONT size=2>&gt; utilization of the</FONT> <BR><FONT 
  size=2>&gt; channel without negatively effecting QoS traffic flows.</FONT> 
  <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; Steve</FONT> <BR><FONT 
  size=2>&gt; </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; 
  </FONT><BR><FONT size=2>&gt; &gt; Date: Thu, 17 Jan 2002 19:49:13 +0000</FONT> 
  <BR><FONT size=2>&gt; &gt; To: "Georgios Karagiannis (ELN)" </FONT><BR><FONT 
  size=2>&gt; &lt;Georgios.Karagiannis@eln.ericsson.se&gt;,</FONT> <BR><FONT 
  size=2>&gt; &gt;&nbsp;&nbsp;&nbsp; "'Loughney John (NRC/Helsinki)'" 
  &lt;john.loughney@nokia.com&gt;,</FONT> <BR><FONT size=2>&gt; 
  &gt;&nbsp;&nbsp;&nbsp; "'ext Kappler Cornelia'" 
  &lt;Cornelia.Kappler@icn.siemens.de&gt;</FONT> <BR><FONT size=2>&gt; &gt; 
  From: Hermann De Meer &lt;h.demeer@ee.ucl.ac.uk&gt;</FONT> <BR><FONT 
  size=2>&gt; &gt; Cc: &lt;nsis@ietf.org&gt;</FONT> <BR><FONT size=2>&gt; &gt; 
  Subject: RE: [NSIS] Two kinds of requirements</FONT> <BR><FONT size=2>&gt; 
  &gt; </FONT><BR><FONT size=2>&gt; &gt; Hi Georgios and all</FONT> <BR><FONT 
  size=2>&gt; &gt; </FONT><BR><FONT size=2>&gt; &gt; At 14:09 17/01/2002 +0100, 
  Georgios Karagiannis (ELN) wrote:</FONT> <BR><FONT size=2>&gt; &gt; &gt;Hi 
  John and Cornelia</FONT> <BR><FONT size=2>&gt; &gt; &gt;</FONT> <BR><FONT 
  size=2>&gt; &gt; &gt;I think that one of the requirements that should be 
  included</FONT> <BR><FONT size=2>&gt; &gt; &gt;in the NSIS WG requirements 
  document is that the NSIS protocol</FONT> <BR><FONT size=2>&gt; &gt; 
  &gt;should be modular. Modular in the context of having</FONT> <BR><FONT 
  size=2>&gt; &gt; &gt;a toolkit from which one can choose the applicable 
  tools</FONT> <BR><FONT size=2>&gt; &gt; &gt;in order to manage QoS in a 
  particular networking environment.</FONT> <BR><FONT size=2>&gt; &gt; 
  </FONT><BR><FONT size=2>&gt; &gt; I believe you are raising a very important 
  issue with the </FONT><BR><FONT size=2>&gt; emphasis on </FONT><BR><FONT 
  size=2>&gt; &gt; modularity</FONT> <BR><FONT size=2>&gt; &gt; of QoS 
  architectures/signalling.</FONT> <BR><FONT size=2>&gt; &gt; </FONT><BR><FONT 
  size=2>&gt; &gt; But one can generalize that: it's all about 
  flexibility,</FONT> <BR><FONT size=2>&gt; &gt; namely flexibility of 
  signalling/control/provisioning vs. </FONT><BR><FONT size=2>&gt; flexibility 
  of </FONT><BR><FONT size=2>&gt; &gt; applications/users.</FONT> <BR><FONT 
  size=2>&gt; &gt; </FONT><BR><FONT size=2>&gt; &gt; Flexibility does not 
  necessarily mean complexity, often on </FONT><BR><FONT size=2>&gt; the 
  contrary:</FONT> <BR><FONT size=2>&gt; &gt; one side being flexible makes the 
  life for the other side </FONT><BR><FONT size=2>&gt; easier (think of</FONT> 
  <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; &gt; airline ticket 
  pricing:</FONT> <BR><FONT size=2>&gt; &gt; the price for the *same seat* can 
  vary in an order of </FONT><BR><FONT size=2>&gt; magnitude simply</FONT> 
  <BR><FONT size=2>&gt; &gt; depending on how flexible you are!)</FONT> 
  <BR><FONT size=2>&gt; &gt; </FONT><BR><FONT size=2>&gt; &gt; QoS signalling is 
  about indicating of how "inflexible" you </FONT><BR><FONT size=2>&gt; are from 
  that </FONT><BR><FONT size=2>&gt; &gt; perspective.</FONT> <BR><FONT 
  size=2>&gt; &gt; But looking at IntServ (RSVP) or DiffServ,&nbsp; an 
  </FONT><BR><FONT size=2>&gt; interpretation of these</FONT> <BR><FONT 
  size=2>&gt; signals</FONT> <BR><FONT size=2>&gt; &gt; have traditionally been 
  seen rather statically:</FONT> <BR><FONT size=2>&gt; &gt; </FONT><BR><FONT 
  size=2>&gt; &gt; - a "one-size-fits-all"&nbsp; "end-to-end" implementation of 
  the </FONT><BR><FONT size=2>&gt; mechanisms</FONT> <BR><FONT size=2>&gt; &gt; 
  - a "take-it-or-leave-it" approach: statically defined QoS classes.</FONT> 
  <BR><FONT size=2>&gt; &gt; </FONT><BR><FONT size=2>&gt; &gt; this makes QoS 
  provisioning cumbersome, complex, expensive </FONT><BR><FONT size=2>&gt; 
  (unnecessarily)</FONT> <BR><FONT size=2>&gt; &gt; (and it may be a good deal 
  the reason for the </FONT><BR><FONT size=2>&gt; "failure/insufficiency" of 
  </FONT><BR><FONT size=2>&gt; &gt; current QoS solutions/</FONT> <BR><FONT 
  size=2>&gt; &gt; signalling techniques).</FONT> <BR><FONT size=2>&gt; &gt; 
  </FONT><BR><FONT size=2>&gt; &gt; Remember, the success of IP networking has 
  to a larger </FONT><BR><FONT size=2>&gt; extend been due to </FONT><BR><FONT 
  size=2>&gt; &gt; the fact of</FONT> <BR><FONT size=2>&gt; &gt; relying on 
  flexibility and cooperation, for example, for congestion</FONT> <BR><FONT 
  size=2>&gt; handling.</FONT> <BR><FONT size=2>&gt; &gt; (or "exception" 
  handling, if you want, by TCP-similar schemes)</FONT> <BR><FONT size=2>&gt; 
  &gt; </FONT><BR><FONT size=2>&gt; &gt; in 
  &lt;draft-demeer-nsis-analyis-00.txt&gt; we therefore make a </FONT><BR><FONT 
  size=2>&gt; point to extend </FONT><BR><FONT size=2>&gt; &gt; QoS signalling 
  for:</FONT> <BR><FONT size=2>&gt; &gt; </FONT><BR><FONT size=2>&gt; &gt; 1) 
  explicitly dealing with such "QoS exceptions" (there is also an</FONT> 
  <BR><FONT size=2>&gt; economic </FONT><BR><FONT size=2>&gt; &gt; argument for 
  this)</FONT> <BR><FONT size=2>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; that is, 
  not only signaling QoS preferences from </FONT><BR><FONT size=2>&gt; 
  applications to the </FONT><BR><FONT size=2>&gt; &gt; network, but also</FONT> 
  <BR><FONT size=2>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; QoS exceptions back 
  from networks to applications or to between</FONT> <BR><FONT size=2>&gt; 
  networks,</FONT> <BR><FONT size=2>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; and 
  an expected cooperative adaptation.</FONT> <BR><FONT size=2>&gt; &gt; 
  </FONT><BR><FONT size=2>&gt; &gt; 2) allowing for flexible interpretations in 
  different </FONT><BR><FONT size=2>&gt; domains (core, </FONT><BR><FONT 
  size=2>&gt; &gt; access, mobile, wireless,</FONT> <BR><FONT size=2>&gt; 
  &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; administrative conditions, 
  ....)</FONT> <BR><FONT size=2>&gt; &gt; </FONT><BR><FONT size=2>&gt; &gt; 
  </FONT><BR><FONT size=2>&gt; &gt; The "trick" may be to modify signalling 
  (including RSVP) </FONT><BR><FONT size=2>&gt; such that most </FONT><BR><FONT 
  size=2>&gt; &gt; flexibility/cooperation</FONT> <BR><FONT size=2>&gt; &gt; can 
  be re-gained by assuring a minimum support of inflexibility </FONT><BR><FONT 
  size=2>&gt; &gt; (intentionally not using the</FONT> <BR><FONT size=2>&gt; 
  &gt; the term QoS guarantee here).</FONT> <BR><FONT size=2>&gt; &gt; 
  </FONT><BR><FONT size=2>&gt; &gt; </FONT><BR><FONT size=2>&gt; &gt; 
  --Hermann</FONT> <BR><FONT size=2>&gt; &gt; </FONT><BR><FONT size=2>&gt; 
  ...</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; 
  _______________________________________________</FONT> <BR><FONT size=2>&gt; 
  nsis mailing list</FONT> <BR><FONT size=2>&gt; nsis@ietf.org</FONT> <BR><FONT 
  size=2>&gt; <A href="https://www1.ietf.org/mailman/listinfo/nsis" 
  target=_blank>https://www1.ietf.org/mailman/listinfo/nsis</A></FONT> <BR><FONT 
  size=2>&gt; </FONT><BR><FONT size=2>&gt; 
  _______________________________________________</FONT> <BR><FONT size=2>&gt; 
  nsis mailing list</FONT> <BR><FONT size=2>&gt; nsis@ietf.org</FONT> <BR><FONT 
  size=2>&gt; <A href="https://www1.ietf.org/mailman/listinfo/nsis" 
  target=_blank>https://www1.ietf.org/mailman/listinfo/nsis</A></FONT> <BR><FONT 
  size=2>&gt; </FONT></P></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C1A11F.3A8C0EC0--

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



From daemon@optimus.ietf.org  Mon Jan 21 04:40: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 EAA03342
	for <nsis-archive@odin.ietf.org>; Mon, 21 Jan 2002 04:40:39 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id EAA28453
	for nsis-archive@odin.ietf.org; Mon, 21 Jan 2002 04:40: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 EAA28036;
	Mon, 21 Jan 2002 04:30: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 EAA27928
	for <nsis@optimus.ietf.org>; Mon, 21 Jan 2002 04:30:37 -0500 (EST)
Received: from mail1.telekom.de ([62.225.183.235])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03245
	for <nsis@ietf.org>; Mon, 21 Jan 2002 04:30:33 -0500 (EST)
Received: from g8pbq.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Mon, 21 Jan 2002 10:27:55 +0100
Received: by G8PBQ.blf01.telekom.de with Internet Mail Service (5.5.2653.19)
	id <CRH1BT1P>; Mon, 21 Jan 2002 10:29:27 +0100
Message-Id: <DFD875E85664D3118FA6080006277DE70362C82D@U8PN2>
From: "Geib, Ruediger" <Ruediger.Geib@t-systems.com>
To: ykahana@comgates.co.il, gkenward@nortelnetworks.com, dick.rr.knight@bt.com,
        gilbert@rsch.comm.mot.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] Support needed for Throughput Adaptive QoS in wireless
Date: Mon, 21 Jan 2002 10:15:00 +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 EAA27972
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 also think that the solution of over loading 
>  should be managed by a local "higher hierarchy" 
>  and not by the End-to-End reservation. This 
>  local service controller should be aware of the 
>  sessions, users, resources and commitments. 
>  Hence could decide a "re-negotiation" or a drop.   

I'd favour adaptive applications also in the QoS case. Network to user re-negotiation means more complexity and it requires extra signalling. Leave it to the apps. A network may overbook, if it is aware that most apps are adaptive. This requires no extra procedures.

Two further arguments:
- Plain old telephony used a compression scheme
  to save transatlantic capacity during high 
  congestion (called DCME). No user was
  aware of that. The only extra signalling
  occured  between DCME units. 

- Say you support re-negotiation. Your cell 
  supports 10 QoS reservations and the ten
  of them are used. Number 11 wants to enter
  and triggers a re-negotiation. Do you 
  re-negotiate all of the ten existing
  reservations? Only one? If so, how do you
  decide on the candidate in a fair way?

Regards, Rüdiger  

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



From daemon@optimus.ietf.org  Mon Jan 21 04:50: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 EAA03459
	for <nsis-archive@odin.ietf.org>; Mon, 21 Jan 2002 04:50:56 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id EAA28683
	for nsis-archive@odin.ietf.org; Mon, 21 Jan 2002 04:50: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 EAA28515;
	Mon, 21 Jan 2002 04:41: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 EAA28484
	for <nsis@optimus.ietf.org>; Mon, 21 Jan 2002 04:41:21 -0500 (EST)
Received: from mail1.telekom.de ([62.225.183.235])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03363
	for <nsis@ietf.org>; Mon, 21 Jan 2002 04:41:17 -0500 (EST)
Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Mon, 21 Jan 2002 10:38:57 +0100
Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19)
	id <ZLG2QG8Z>; Mon, 21 Jan 2002 10:40:34 +0100
Message-Id: <DFD875E85664D3118FA6080006277DE70362C82F@U8PN2>
From: "Geib, Ruediger" <Ruediger.Geib@t-systems.com>
To: dick.rr.knight@bt.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements  (unsupported domains + chic
	 k en and eggs)
Date: Mon, 21 Jan 2002 10:40:26 +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 EAA28485
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 agree that it is the user that makes the decision about a 
> chunk of network that cannot support the requested QoS.
> 
> But why mark the packet and continue on all the way to the 
> destination and back? It is simpler for a user to indicate
> in the original request:
> 1. Don't downgrade
> 2. Downgrade to no lower than [x]
> 3. I'd prefer QoS [n] but I'll accept Best Efoort if I have to.

Case 3 probably results in Best Effort should you apply at inter carrier interfaces. I mean, it's a competitors reservation and the competitors customer sees what he's getting from his provider (because he doesn't know that I am the bad guy...).
Ok, I may have expressed it extremely negative, but did I really fail to describe business humanity? I would suggest to leave no room for negotiation and interpretation at inter carrier interfaces. 

This option may be allright at the first/final customer - provider edge. But it should be limited to this interface.
I personally look at negotiation only as an optional feature. To me, it's not a requirement.

Regards, Rüdiger

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



From daemon@optimus.ietf.org  Mon Jan 21 05:09:42 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03672
	for <nsis-archive@odin.ietf.org>; Mon, 21 Jan 2002 05:09:42 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id FAA29396
	for nsis-archive@odin.ietf.org; Mon, 21 Jan 2002 05: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 FAA29021;
	Mon, 21 Jan 2002 05:00: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 FAA28980
	for <nsis@optimus.ietf.org>; Mon, 21 Jan 2002 05:00:23 -0500 (EST)
Received: from cbibipnt08.hc.bt.com (saturn.bt.com [193.113.57.20])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03514
	for <nsis@ietf.org>; Mon, 21 Jan 2002 05:00:18 -0500 (EST)
From: dick.rr.knight@bt.com
Received: by cbibipnt08.hc.bt.com with Internet Mail Service (5.5.2654.89)
	id <DA1WV1W1>; Mon, 21 Jan 2002 10:00:01 -0000
Message-ID: <451D45016C2CD2119DA50000F8FE7F07080E5A4A@mlngcbnt01.hc.bt.com>
To: Ruediger.Geib@t-systems.com, dick.rr.knight@bt.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements   (unsupported domains + chi
	c k en and eggs)
Date: Mon, 21 Jan 2002 09:59:43 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2654.89)
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 FAA28981
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 don't want to get into the business humanity and all the scenarios that it
entails, but I am not convinced it is quite as bad as you suggest. Most of
these things are covered by business agreements and contracts - if there is
an agreement or contract and one provider doesn't meet it, then you get the
service from another.

There are more problems that I have since thought of. What happens if the
service provider gets a request for a high-grade connection - which can only
be satisfied by downgrading a stream that had been established already at
the requested level/class?

We could solve this, with a "no established flow downgrading" requirement or
option, but do we want to?

Dick

-----Original Message-----
From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com]
Sent: 21 January 2002 09:40
To: dick.rr.knight@bt.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements (unsupported domains +
chic k en and eggs)


> I agree that it is the user that makes the decision about a 
> chunk of network that cannot support the requested QoS.
> 
> But why mark the packet and continue on all the way to the 
> destination and back? It is simpler for a user to indicate
> in the original request:
> 1. Don't downgrade
> 2. Downgrade to no lower than [x]
> 3. I'd prefer QoS [n] but I'll accept Best Efoort if I have to.

Case 3 probably results in Best Effort should you apply at inter carrier
interfaces. I mean, it's a competitors reservation and the competitors
customer sees what he's getting from his provider (because he doesn't know
that I am the bad guy...).
Ok, I may have expressed it extremely negative, but did I really fail to
describe business humanity? I would suggest to leave no room for negotiation
and interpretation at inter carrier interfaces. 

This option may be allright at the first/final customer - provider edge. But
it should be limited to this interface.
I personally look at negotiation only as an optional feature. To me, it's
not a requirement.

Regards, Rüdiger

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



From daemon@optimus.ietf.org  Mon Jan 21 05:32: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 FAA04401
	for <nsis-archive@odin.ietf.org>; Mon, 21 Jan 2002 05:32:29 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id FAA00403
	for nsis-archive@odin.ietf.org; Mon, 21 Jan 2002 05:32: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 FAA29549;
	Mon, 21 Jan 2002 05:13: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 FAA29516
	for <nsis@optimus.ietf.org>; Mon, 21 Jan 2002 05:13:27 -0500 (EST)
Received: from cbibipnt05.hc.bt.com (saturn.bt.com [193.113.57.20])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04024
	for <nsis@ietf.org>; Mon, 21 Jan 2002 05:13:23 -0500 (EST)
From: dick.rr.knight@bt.com
Received: by cbibipnt05.hc.bt.com with Internet Mail Service (5.5.2652.35)
	id <DA1V42S2>; Mon, 21 Jan 2002 10:13:01 -0000
Message-ID: <451D45016C2CD2119DA50000F8FE7F07080E5A4B@mlngcbnt01.hc.bt.com>
To: schneider@tri.sbc.com, rrroy@att.com, gkenward@nortelnetworks.com,
        john.loughney@nokia.com, brunner@ccrle.nec.de, ykahana@comgates.co.il,
        Ruediger.Geib@t-systems.com, dick.rr.knight@bt.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements
Date: Mon, 21 Jan 2002 10:10:00 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
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


I don't think you can do the session level QoS agreement soley between
end-users, and ignore the capabilities of the intermediate networks. Suppose
you negotiate the perfect QoS for an application, and then request a
reservation to the network, what happens when the network can fulfill the
reservation? Do you begin the session level negotiation again, and keep
going stepwise until you get to the highest possible QoS the network can
give you?
Or do you accept the highest level of QoS the network can provide and then
see if you can accept that for the session?

It is in my mind, for the above reasons, that you need a protocol that can
request QoS and that request can be processed and acted upon at both user
and network nodes. It cannot be limited to user-network nor user-user.

I do agree that it need not be processed on a per hop basis as it can
transverse a domain with a single QoS mechanism. That mechanism, be it
diffserv or intserv, PNNI, RSVP, or even over-provisioning, takes care of
the policing and the "path" establishment within the domain.


Dick

-----Original Message-----
From: Schneider, Marco [mailto:schneider@tri.sbc.com]
Sent: 18 January 2002 20:10
To: 'Roy, Radhika R, ALASO'; Gary Kenward; Loughney John (NRC/Helsinki);
brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
dick.rr.knight@bt.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


Hi Roy,

Below is the original text from your reponse to Gary Kenward. Hopefully the
context is clear.

"[Roy, Radhika R, ALARC]  I would say that it is the QOS needs of the
application (e.g., SIP-based VoIP) that the user likes to express (as
opposed to "service"). Similarly, instead of network services, we would say
network layer QOS services (e.g., RSVP, DiffServ, MPLS). We would develop
the end-to-end (application layer) QOS signaling protocol (say, NSIS QOS).
Now, there needs to have some kinds of standards how NSIS QOS will be mapped
over RSVP, DiffServ, MPLS, etc."

So by End-to-End you mean between directly between two "users". This is
session level signaling and I don't believe the signaling part is within the
scope of this working group. An application level QOS specification may be. 

After a session level agreement on QOS, the host/client/customer will need
to signal an actual reservation request to the network for the necessary QOS
agreed to at the session level. This is the protocol that we need to work
on. 

This approach is discussed in the SIP draft "SIP Extensions for Media
Authorization" (draft-ietf-sip-call-auth-03.txt) and the RAP draft
"Framework for session set-up with media authorization"
(draft-ietf-rap-session-auth-02.txt).

Marco Schneider

-----Original Message-----
From: Roy, Radhika R, ALASO [mailto:rrroy@att.com]
Sent: Friday, January 18, 2002 9:18 AM
To: Schneider, Marco; Gary Kenward; Loughney John (NRC/Helsinki);
brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
dick.rr.knight@bt.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


Defined below [RRR]

-----Original Message-----
From: Schneider, Marco [mailto:schneider@tri.sbc.com]
Sent: Thursday, January 17, 2002 8:47 PM
To: Roy, Radhika R, ALASO; Gary Kenward; Loughney John (NRC/Helsinki);
brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
dick.rr.knight@bt.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


Hi Roy,

Can you please define what you mean by "End-to-End Application Layer QOS
Signaling". Thanks.

[RRR] Suppose an user is initiation a SIP call to another user with audio,
video, and data. The use needs to express the needs of QOS for audio, video,
and data to another user. 

[RRR] The signaling mechanism that allows to express the QOS parameters of
audio, video, and data is termed as the "End-to-End Application Layer QOS
Signaling."

Marco Schneider

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



From daemon@optimus.ietf.org  Mon Jan 21 05:41:06 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04498
	for <nsis-archive@odin.ietf.org>; Mon, 21 Jan 2002 05:41:01 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id FAA00677
	for nsis-archive@odin.ietf.org; Mon, 21 Jan 2002 05:41: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 FAA00322;
	Mon, 21 Jan 2002 05:31: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 FAA00289
	for <nsis@optimus.ietf.org>; Mon, 21 Jan 2002 05:31:04 -0500 (EST)
Received: from mail1.telekom.de ([62.225.183.235])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04357
	for <nsis@ietf.org>; Mon, 21 Jan 2002 05:30:59 -0500 (EST)
Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Mon, 21 Jan 2002 11:28:33 +0100
Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19)
	id <ZLG2Q28L>; Mon, 21 Jan 2002 11:29:09 +0100
Message-Id: <DFD875E85664D3118FA6080006277DE70362C831@U8PN2>
From: "Geib, Ruediger" <Ruediger.Geib@t-systems.com>
To: dick.rr.knight@bt.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements   (unsupported domains + chi
	 c k en and eggs)
Date: Mon, 21 Jan 2002 11:29:00 +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 FAA00290
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 Dick,

comments in line.

Regards, Rüdiger

> I don't want to get into the business humanity and all the 
> scenarios that it entails, but I am not convinced it is 
> quite as bad as you suggest. Most of these things are
> covered by business agreements and contracts 
> - if there is an agreement or contract and one provider
>   doesn't meet it, then you get the service from another.

I've been doing technical inter carrier agreements a while ago. I certainly don't want to say that carriers are not interested in providing end to end QoS services and I am aware of the contractual issues around them.

If you look at inventions like e.g. "hot potato"/"cold potato" routing, it may not be desirable to allow softening up a service committment already while specifying the service.

But also as a technican who has been doing this kind of inter carrier negotiation already: please let's limit the number of options with regard to QoS negotiation at inter carrier interfaces to an absolute minimum. And it not only simplifies life, it is also in the sense of the customer. 
 
> There are more problems that I have since thought of. What 
> happens if the  service provider gets a request for a 
> high-grade connection - which can only be satisfied by
> downgrading a stream that had been  established already at
> the requested level/class?
> 
> We could solve this, with a "no established flow downgrading" 
> requirement or option, but do we want to?

Sounds a bit like preemption. In theory preemption is a good idea. In practice, it adds signalling requirements (check the DiffServ aware Traffic Engineering discussion for input) and it results in added complexity in operation. 
In your example, a "resources not available" message may be the outcome (if signalling and operation of services are to be kept simple and preemption is not supported).



> -----Original Message-----
> From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com]
> Sent: 21 January 2002 09:40
> To: dick.rr.knight@bt.com
> Cc: nsis@ietf.org
> Subject: RE: [NSIS] Two kinds of requirements (unsupported domains +
> chic k en and eggs)
> 
> 
> > I agree that it is the user that makes the decision about a 
> > chunk of network that cannot support the requested QoS.
> > 
> > But why mark the packet and continue on all the way to the 
> > destination and back? It is simpler for a user to indicate
> > in the original request:
> > 1. Don't downgrade
> > 2. Downgrade to no lower than [x]
> > 3. I'd prefer QoS [n] but I'll accept Best Efoort if I have to.
> 
> Case 3 probably results in Best Effort should you apply at 
> inter carrier
> interfaces. I mean, it's a competitors reservation and the competitors
> customer sees what he's getting from his provider (because he 
> doesn't know
> that I am the bad guy...).
> Ok, I may have expressed it extremely negative, but did I 
> really fail to
> describe business humanity? I would suggest to leave no room 
> for negotiation
> and interpretation at inter carrier interfaces. 
> 
> This option may be allright at the first/final customer - 
> provider edge. But
> it should be limited to this interface.
> I personally look at negotiation only as an optional feature. 
> To me, it's
> not a requirement.
> 
> 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  Mon Jan 21 05: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 FAA04536
	for <nsis-archive@odin.ietf.org>; Mon, 21 Jan 2002 05:42:49 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id FAA00720
	for nsis-archive@odin.ietf.org; Mon, 21 Jan 2002 05:42: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 FAA29888;
	Mon, 21 Jan 2002 05:29: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 FAA29859
	for <nsis@optimus.ietf.org>; Mon, 21 Jan 2002 05:29:51 -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 FAA04342
	for <nsis@ietf.org>; Mon, 21 Jan 2002 05:29:46 -0500 (EST)
Received: from esealnt409.al.sw.ericsson.se (ESEALNT409.al.sw.ericsson.se [153.88.251.32])
	by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g0LATnw16824
	for <nsis@ietf.org>; Mon, 21 Jan 2002 11:29:49 +0100 (MET)
Received: FROM esealnt746.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Mon Jan 21 11:29:30 2002 +0100
Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <YHLJLW4D>; Mon, 21 Jan 2002 11:29:46 +0100
Message-ID: <E244E44D6AB85E40AEEF7EAABE3545FA823384@enleent104.nl.eu.ericsson.se>
From: "Georgios Karagiannis (ELN)" <Georgios.Karagiannis@eln.ericsson.se>
To: "'dick.rr.knight@bt.com'" <dick.rr.knight@bt.com>
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements
Date: Mon, 21 Jan 2002 11:29:38 +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 Dick

Please see my comment in line:
[DK]>> I do agree that it need not be processed on a per hop basis as it can
[DK]>> transverse a domain with a single QoS mechanism. That mechanism, be it
[DK]>> diffserv or intserv, PNNI, RSVP, or even over-provisioning, takes care of
[DK]>> the policing and the "path" establishment within the domain.

Please note that at the moment there are scenarios that will need to 
process the [everyhop] component. Some of these scenarios are the Radio Access
Network and Mobile IP,..
Therefore, the [everyhop] component should be supported by the NSIS protocol.
However a "host" or a "edge" should be able to activated or not.

Furthermore, in my opinion the NSIS protocol should be:
end host - end host: the NSIS protocol is terminated at end hosts;
end host - proxy: the NSIS protocol is terminated at end host and proxy;
end host - edge: the NSIS protocol is terminated at end end host and edge;
edge - edge: the NSIS protocol is terminated at egdes of one/multiple domains;


Best regards,
Georgios


-----Original Message-----
From: Schneider, Marco [mailto:schneider@tri.sbc.com]
Sent: 18 January 2002 20:10
To: 'Roy, Radhika R, ALASO'; Gary Kenward; Loughney John (NRC/Helsinki);
brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
dick.rr.knight@bt.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


Hi Roy,

Below is the original text from your reponse to Gary Kenward. Hopefully the
context is clear.

"[Roy, Radhika R, ALARC]  I would say that it is the QOS needs of the
application (e.g., SIP-based VoIP) that the user likes to express (as
opposed to "service"). Similarly, instead of network services, we would say
network layer QOS services (e.g., RSVP, DiffServ, MPLS). We would develop
the end-to-end (application layer) QOS signaling protocol (say, NSIS QOS).
Now, there needs to have some kinds of standards how NSIS QOS will be mapped
over RSVP, DiffServ, MPLS, etc."

So by End-to-End you mean between directly between two "users". This is
session level signaling and I don't believe the signaling part is within the
scope of this working group. An application level QOS specification may be. 

After a session level agreement on QOS, the host/client/customer will need
to signal an actual reservation request to the network for the necessary QOS
agreed to at the session level. This is the protocol that we need to work
on. 

This approach is discussed in the SIP draft "SIP Extensions for Media
Authorization" (draft-ietf-sip-call-auth-03.txt) and the RAP draft
"Framework for session set-up with media authorization"
(draft-ietf-rap-session-auth-02.txt).

Marco Schneider

-----Original Message-----
From: Roy, Radhika R, ALASO [mailto:rrroy@att.com]
Sent: Friday, January 18, 2002 9:18 AM
To: Schneider, Marco; Gary Kenward; Loughney John (NRC/Helsinki);
brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
dick.rr.knight@bt.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


Defined below [RRR]

-----Original Message-----
From: Schneider, Marco [mailto:schneider@tri.sbc.com]
Sent: Thursday, January 17, 2002 8:47 PM
To: Roy, Radhika R, ALASO; Gary Kenward; Loughney John (NRC/Helsinki);
brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
dick.rr.knight@bt.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


Hi Roy,

Can you please define what you mean by "End-to-End Application Layer QOS
Signaling". Thanks.

[RRR] Suppose an user is initiation a SIP call to another user with audio,
video, and data. The use needs to express the needs of QOS for audio, video,
and data to another user. 

[RRR] The signaling mechanism that allows to express the QOS parameters of
audio, video, and data is termed as the "End-to-End Application Layer QOS
Signaling."

Marco Schneider

_______________________________________________
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 Jan 21 05:58: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 FAA04849
	for <nsis-archive@odin.ietf.org>; Mon, 21 Jan 2002 05:58:08 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id FAA01008
	for nsis-archive@odin.ietf.org; Mon, 21 Jan 2002 05:58: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 FAA00868;
	Mon, 21 Jan 2002 05:47: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 FAA00797
	for <nsis@optimus.ietf.org>; Mon, 21 Jan 2002 05:47:11 -0500 (EST)
Received: from cbibipnt08.hc.bt.com (saturn.bt.com [193.113.57.20])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04607
	for <nsis@ietf.org>; Mon, 21 Jan 2002 05:47:05 -0500 (EST)
From: dick.rr.knight@bt.com
Received: by cbibipnt08.hc.bt.com with Internet Mail Service (5.5.2654.89)
	id <DA1WV2DC>; Mon, 21 Jan 2002 10:46:10 -0000
Message-ID: <451D45016C2CD2119DA50000F8FE7F07080E5A4C@mlngcbnt01.hc.bt.com>
To: wchen@tri.sbc.com, schneider@tri.sbc.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements   (priority on the boundary 
	b e tween a customer and the network)
Date: Mon, 21 Jan 2002 10:45:52 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2654.89)
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


I have a worry about this.

The "2" flow works as you have shown, but in reality a 
[edge]<---2---[hop]-->[edge]
is really
[edge][domain]<--2--[hop]-->[domain]  ...(cont next line)
<--2--[hop]-->[domain]<--2--[hop]-->[domain][edge]

where the flow

[domain]<--2--[hop]-->[domain]
implies a domain bounded by an interworking function and containing one or
more switching functions (i.e. at least a router or possibly a multiplexor
or switch etc.)

The inter-domain aspect is complex because of differing technology/QoS
solutions and the "who does the interworking" problems. If the interdomain
problem is solved by a standardised QoS request signalling protocol, then
this can be "mapped" down to the "2" flow you have shown.

This simplifies the interworking problem. Given a set of protocols, then the
requirement to interwork each protocol to all the others is a problem of
forever increasing complexity. If you interwork to a single generic protocol
then the interworking problem is 1x(NumProtocols). Every time you add a new
QoS mechanism, then the you only need one additional interworking solution.



-----Original Message-----
From: Chen, Weijing [mailto:wchen@tri.sbc.com]
Sent: 18 January 2002 19:09
To: 'dick.rr.knight@bt.com'; Schneider, Marco
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements (priority on the boundary
b e tween a customer and the network)


Dick,

3 is more a function than a particular protocol or protocol component. Allow
me to illustrate the QoS service delivery chain with the diagram below:

[host]<--1--[hop]-->[edge]<---2---[hop]-->[edge]<--1--[hop]-->[host]

[host]<-------------------3----------------------------------------------->[
host]

a) The user locates the service provider or other subscriber(s) that he
wishes to contact.  The result of this step is that the subscriber will know
the network addresses of the other subscriber(s)) he wishes to contact, and
the QoS he wishes to use to contact them. (By SIP, SDP, DNS, web, or any
application level session protocol)
b) The user negotiates with the network to establish the desired
communications capabilities with the other subscriber(s). (By signaling
protocol 1)
c) The network internally allocates the resources to fulfill the
subscriber's request. (By signaling protocol 2 (e.g. PNNI, MPLS, RSVP, or
even over-provisioning) and mapping of QoS of 1 to QoS of 2)
d) The user authenticates with the other subscriber(s) and is authorized to
receive services from them. (By other security means)
e) The user then communicates with the other subscriber(s)) to receive
services. (By underline transport link reserved previously in step b and c.
)
f) At the conclusion of the session, billing information is recorded so the
subscriber can be billed for the network services.

Now 3 is the experience of the user who got QoS service from the network.
The actual protocols involved are 1 and 2. The 1 does not really go from
end-to-end, but from end-to-network, and network-to-end. The edge will do
the network-to-network. Again standardization of 1 to 2 QoS mapping is
debatable which I don't have an opinion yet.

--
Weijing Chen
SBC Technology Resources
9505 Arboretum Blvd.
Austin, TX 78759
512 372 5710
wchen@tri.sbc.com


 -----Original Message-----
From: 	dick.rr.knight@bt.com [mailto:dick.rr.knight@bt.com] 
Sent:	Friday, January 18, 2002 10:45 AM
To:	Chen, Weijing; dick.rr.knight@bt.com; Schneider, Marco;
Georgios.Karagiannis@eln.ericsson.se
Cc:	nsis@ietf.org
Subject:	RE: [NSIS] Two kinds of requirements  (priority on the
boundary b e tween a customer and the network)


There is something missing for me in your logic. What is 3?

I can better relate to the terminology of everyhop; everyedge; everyhost. Is
3 the everyhost bit?

-----Original Message-----
From: Chen, Weijing [mailto:wchen@tri.sbc.com]
Sent: 18 January 2002 16:12
To: 'dick.rr.knight@bt.com'; Schneider, Marco;
Georgios.Karagiannis@eln.ericsson.se
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements (priority on the boundary
be tween a customer and the network)


Sorry, previous picture is garbled by mailer. 


[host]<--1--[hop]-->[edge]<---2---[hop]-->[edge]<--1--[hop]-->[host]

[host]<-------------------3------------------------------------------------>
[host]


The 3 is our goal and is comprised of 1 and 2. As we know, there are
solutions for 2 (MPLS, DiffServ, PNNI, over-provisioning, etc). What we need
to solve is the 1.  Now what about translation (or mapping) between 1 and 2?
Do we need to standardize it?  If yes, where? In NSIS group or elsewhere?

Regardless, the objective of 1 is KISS and universal. The complexity of 1
and 2 mapping must be born by the [edge].



--
Weijing Chen
SBC Technology Resources
9505 Arboretum Blvd.
Austin, TX 78759
512 372 5710
wchen@tri.sbc.com



 -----Original Message-----
From: 	dick.rr.knight@bt.com [mailto:dick.rr.knight@bt.com] 
Sent:	Friday, January 18, 2002 5:12 AM
To:	Schneider, Marco; Georgios.Karagiannis@eln.ericsson.se;
dick.rr.knight@bt.com
Cc:	nsis@ietf.org
Subject:	RE: [NSIS] Two kinds of requirements (priority on the
boundary be tween a customer and the network)


I do not agree.

What is the point of completing the work enabling the customer to signal to
the network, if the network cannot signal between domains? The network can
never satisfy the request.

Dick

-----Original Message-----
From: Schneider, Marco [mailto:schneider@tri.sbc.com]
Sent: 18 January 2002 01:44
To: 'Georgios Karagiannis (ELN)'; 'dick.rr.knight@bt.com'
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


Hi Georgios,

While I agree NSIS could be used to support Interior to Interior (of one
carrier) or Edge to Core, I think that we need to prioritize on a signaling
protocol across the boundary between a customer and the network. Note that
the customer could be an individual, an ISP or another Carrier.

Marco Schneider

-----Original Message-----
From: Georgios Karagiannis (ELN)
[mailto:Georgios.Karagiannis@eln.ericsson.se]
Sent: Thursday, January 17, 2002 3:39 AM
To: 'dick.rr.knight@bt.com'
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


Hi Dick 

In principle I agree with your comment (see below).

[DK] >> To be more precise, I am suggesting a new protocol that is 
[DK] >> independent of the underlying transport technology and the QoS 
[DK] >> implemented and is also independent of the session control protocol.


However, a very important point here is that we need to 
specify a protocol that can be used independent of the underlying transport 
technology, but that can satisfy the QoS requirements imposed by these 
underlying transport technologies. Otherwise the protocol will not be
suitable
and useful.

A way of achieving this is by first creating a modular QoS signaling toolkit

that will contain mandatory and optional QoS requirements;
Second, specify how the protocol functionality should be separated in 
building blocks (protocol components) and define a minimum set 
of mandatory reservation options/features that should be 
processed by any network nodes, e.g., end-hosts,
proxies, edges and interior nodes.
An example of such a protocol decomposition is given below!
In this way each node will only process (check and use) the protocol 
components of interest.


|---------|
|---------|
|everyhost|<------------------------------------------------------->|everyho
st|
|---------|
|---------|
|         |                                                         |
|
|---------|   |---------|                             |---------|
|---------|
|everyedge|<->|everyedge|<--------------------------->|everyedge|<->|everyed
ge|
|---------|   |---------|                             |---------|
|---------|
|         |   |         |                             |         |   |
|
|---------|   |---------|   |--------|   |--------|   |---------|
|---------|
|everyhop |<->|everyhop |<->|everyhop|<->|everyhop|<->|everyhop
|<->|everyhop |
|---------|   |---------|   |--------|   |--------|   |---------|
|---------| 
    host          edge        interior    interior       edge          host


  NSIS protocol decomposition (building blocks): 
 *  "everyhost", "everyedge" and "everyhop" are protocol components;
 *  host: can be an end-host or a proxy and it can process and use the
"everyhost", 
    "everyedge", and "everyhop" protocol components;

 *  edge: can be a Diffserv edge, MPLS edge, etc., and it can process and
use 
    the "everyedge", and "everyhop" protocol components. The "everyhost" 
    protocol component is not processed (used or checked);

 *  interior: can be any router within a domain and it can process and use 
    only the "everyhop" protocol component.
    The "everyhost" and "everyedge" protocol components are not 
    processed (used or checked);


Best Regards,
Georgios

-----Original Message-----
From: dick.rr.knight@bt.com [mailto:dick.rr.knight@bt.com]
Sent: woensdag 16 januari 2002 13:00
To: brian.williams@ericsson.com.au; lieve.bos@alcatel.be
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


I was waiting for some reaction to Brian's comments, but as there aren't
any, here are my thoughts on the requirements:

I agree with the analysis that discussion has been based around
application-related signalling for QoS (at session level) and QoS signalling
protocols used to actually provision the QoS at the transport level.
Brian is right that there will never be an enhancement to a single session
protocol that will satisfy all applications.
However, for similar reasons, it is never going to be possible to prescribe
a single QoS mechanism to be used in all networks. Existing networks (or
domains) will not be changed overnight and new networks already face several
workable mechanisms to deploy QoS.

I think that what is needed is a new protocol that can signal the
requirements of any session and can be satisfied by any QoS mechanism,
existing or new.
To be more precise, I am suggesting a new protocol that is independent of
the underlying transport technology and the QoS implemented and is also
independent of the session control protocol. Such a new protocol would be
generic, optionally implemented by applications that would benefit from
end-to-end QoS, and would be complimentary to the QoS mechanisms deployed
(and of course other mechanisms, such as the routing).

I think that this implies a more abstract definition of the QoS mechanism
and may lend itself to the signalling of pre-defined QoS classes rather than
parameters.

Dick Knight

-----Original Message-----
From: Brian Williams [mailto:brian.williams@ericsson.com.au]
Sent: 22 December 2001 23:57
To: lieve.bos@alcatel.be
Cc: nsis@ietf.org
Subject: Re: [NSIS] Two kinds of requirements


Hi.
While the two types of signalling may be related, I think there is a
need to develop a QoS bearer mechanism which is independent of any
specific session signalling, and thus can be used for any application. I
believe many of the applications which have identified requirements to
the working group have their own specific session layer signalling (ie
it is not end-to-end SIP).  

Having the session and transport protocols developed separately of
course does not prohibit the two being used in conjunction for a
specific application.
/brian
 
On Fri, 2001-12-21 at 22:24, lieve.bos@alcatel.be wrote:
> Hello all,
> 
> >From the discussion in Salt Lake city and the drafts submitted, one can
> easily see that people are suggesting improvements to QoS signalling at
> two totally different levels (some at session level and some at
> transport level).
> 
> First of all, there are drafts suggesting some improvements in the
> session setup procedures (i.e. the ability to negotiate the preferred
> QoS level between end users during SDP negotiation in SIP, so before the
> actual resources are being setup). The QoS information negotiated at the
> session layer determines the QoS level both endusers have to use for 
> their local access connection. This first kind of 'session level QoS
> negotiation' happens end-to-end between the two end-users.
> 
> Secondly, there are drafts suggesting that we need
> improvements/alternatives for the QoS signalling protocols (e.g. RSVP)
> used to actually provision the QoS at the transport level between two
> endusers. This second kind of 'transport level QoS signalling' can
> consist of several phases: end-to-edge and edge-to-edge. 
> 
> It's important that everybody realises that, in order to give endusers
> true end-to-end Quality of Service, we need improvements for QoS both at
> session and transport level. Also its important to understand that they
> are not uncorrelated. Providers want to be able to control (e.g. via
> policy control mechanisms) that the QoS requested at the transport level
> is not exceeding the QoS negotiated/authorised previously at session
> level. So, what about developing in NSIS a modular framework
> incorporating both session and transport level QoS signalling with
> possible hooks between the two layers (e.g. for policy enforcement).
> 
> Lieve
> 
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis



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

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

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

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

_______________________________________________
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 Jan 21 06:08:08 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05118
	for <nsis-archive@odin.ietf.org>; Mon, 21 Jan 2002 06:08:04 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id GAA01687
	for nsis-archive@odin.ietf.org; Mon, 21 Jan 2002 06:08: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 FAA01059;
	Mon, 21 Jan 2002 05:58: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 FAA01028
	for <nsis@optimus.ietf.org>; Mon, 21 Jan 2002 05:58:44 -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 FAA04869
	for <nsis@ietf.org>; Mon, 21 Jan 2002 05:58:39 -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 g0LAwgw15346
	for <nsis@ietf.org>; Mon, 21 Jan 2002 11:58:42 +0100 (MET)
Received: FROM esealnt747.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Mon Jan 21 11:58:33 2002 +0100
Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <YHKTK8J0>; Mon, 21 Jan 2002 11:58:33 +0100
Message-ID: <E244E44D6AB85E40AEEF7EAABE3545FA823385@enleent104.nl.eu.ericsson.se>
From: "Georgios Karagiannis (ELN)" <Georgios.Karagiannis@eln.ericsson.se>
To: "'gilbert@rsch.comm.mot.com'" <gilbert@rsch.comm.mot.com>, nsis@ietf.org
Subject: RE: [NSIS] Support needed for Throughput Adaptive QoS in wireless
Date: Mon, 21 Jan 2002 11:58:30 +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 Steve

I would like to add some information on 
the need for severe congestion adaptation.
This is one of the QoS requirements (please look also to the rest 
of the QoS requirements)
that we have presented in the NSIS draft entitled:
"QoS Signalling Requirements for Wireless Networks"
located at:
http://www.ietf.org/internet-drafts/draft-karagiannis-nsis-wireless-requirements-00.txt

This additional information is:
"Ability to deal with severe congestion":

   In case of a route change or link failure a severe congestion
   situation may occur in the network. Typically, routing algorithms are
   able to adapt and change their routing decisions to reflect changes
   in the topology and traffic volume. In such situations the re-routed
   traffic will have to follow a new path.  Interior nodes located on
   this new path may become overloaded, since they suddenly might need
   to support more traffic than they have capacity for.  These severe
   congestion situations will severely affect the overall performance of
   the traffic passing through such nodes. Therefore, the QoS signalling
   solution should be able to efficiently solve this situation.

Best regards,
Georgios



-----Original Message-----
From: Steve Gilbert [mailto:gilbert@rsch.comm.mot.com]
Sent: vrijdag 18 januari 2002 17:21
To: nsis@ietf.org
Subject: [NSIS] Support needed for Throughput Adaptive QoS in wireless




I tend to agree with the need which Herman identifies (below) for throughput
adaptive capabilities in a wireless QoS system.

The cellular wireless QoS problem is very different than that of wired QoS
because of the need to handle the case of a user with a QoS "guarantee" handing
off into a different cell.  In the worst case, the cell which it is entering may
have its resources fully allocated to existing users. Dropping the session of
the user being handed off is not a good idea. This points out the need for some
rational way to accommodate such calls. The approach taken in some wireless
voice systems is to reserve resources for use only by sessions which are handing
off into the cell. This may suffice if the resource needs of the hand off
session are predictable. However, in a system in which arbitrary applications
can utilize a wide range of throughput values, reserving enough capacity to
handle the range of throughputs which could potentially be needed by a single
flow may not be practical.

What is needed is the use of throughput adaptive applications and the ability
for a traffic flow to express its QoS preferences with regard to the throughput
values which it may be allocated. Upon handing off into the new cell, the QoS
preferences of the handoff traffic flow and of the existing traffic flows in
that cell would be considered and resources reallocated to best meet their
preferences. Some of the existing traffic flows may have their throughput
allocations reduced in order to free up resources to be allocated to the handoff
traffic flow.

The QoS signaling needs of this approach include the ability of the system to
notify traffic flows of their new allocations, and the ability for a new traffic
flow requesting "admission" to express its QoS preferences, possibly in terms of
a list of throughput values and the benefit it receives from each. A
non-adaptive real-time application would indicate a single throughput value
which it desires rather than a list of throughput values.

One could argue that this provides no throughput "guarantee" and changes what it
means to have a QoS request "admitted". This is true. But in wireless, it is
difficult and sometimes impractical to provide the same QoS guarantees that
could be provided in a wireline system which doesn't have to deal with
handoff. In a wireless system, there is the possibility that the user will drive
into a tunnel or take the elevator to a sub-basement of a building where the
wireless signal is lost. Radio coverage and QoS can not be guaranteed under all
possible situations.  Wireless channel resources are often more scarce or
expensive than those of a wired channel. This generally results in the
motivation to utilize them more efficiently. What is more realistic than trying
to provide wireless QoS identical to that of wire-line is to come up with a
useful approach for "QoS management" and "resource allocation" which can be
applied in a wireless system.

If efficient utilization of the resources by QoS flows is not a major concern,
the QoS of admitted users could be increased (or at least made less prone to
reductions) through over-provisioning or preventing admission of new calls even
when the level of congestion is still low. The resources not guaranteed to QoS
traffic flows could be used by best effort traffic. Systems with significant
best effort traffic would be able to increase the overall utilization of the
channel without negatively effecting QoS traffic flows.

Steve



> Date: Thu, 17 Jan 2002 19:49:13 +0000
> To: "Georgios Karagiannis (ELN)" <Georgios.Karagiannis@eln.ericsson.se>,
>    "'Loughney John (NRC/Helsinki)'" <john.loughney@nokia.com>,
>    "'ext Kappler Cornelia'" <Cornelia.Kappler@icn.siemens.de>
> From: Hermann De Meer <h.demeer@ee.ucl.ac.uk>
> Cc: <nsis@ietf.org>
> Subject: RE: [NSIS] Two kinds of requirements
> 
> Hi Georgios and all
> 
> At 14:09 17/01/2002 +0100, Georgios Karagiannis (ELN) wrote:
> >Hi John and Cornelia
> >
> >I think that one of the requirements that should be included
> >in the NSIS WG requirements document is that the NSIS protocol
> >should be modular. Modular in the context of having
> >a toolkit from which one can choose the applicable tools
> >in order to manage QoS in a particular networking environment.
> 
> I believe you are raising a very important issue with the emphasis on 
> modularity
> of QoS architectures/signalling.
> 
> But one can generalize that: it's all about flexibility,
> namely flexibility of signalling/control/provisioning vs. flexibility of 
> applications/users.
> 
> Flexibility does not necessarily mean complexity, often on the contrary:
> one side being flexible makes the life for the other side easier (think of 
> airline ticket pricing:
> the price for the *same seat* can vary in an order of magnitude simply
> depending on how flexible you are!)
> 
> QoS signalling is about indicating of how "inflexible" you are from that 
> perspective.
> But looking at IntServ (RSVP) or DiffServ,  an interpretation of these signals
> have traditionally been seen rather statically:
> 
> - a "one-size-fits-all"  "end-to-end" implementation of the mechanisms
> - a "take-it-or-leave-it" approach: statically defined QoS classes.
> 
> this makes QoS provisioning cumbersome, complex, expensive (unnecessarily)
> (and it may be a good deal the reason for the "failure/insufficiency" of 
> current QoS solutions/
> signalling techniques).
> 
> Remember, the success of IP networking has to a larger extend been due to 
> the fact of
> relying on flexibility and cooperation, for example, for congestion handling.
> (or "exception" handling, if you want, by TCP-similar schemes)
> 
> in <draft-demeer-nsis-analyis-00.txt> we therefore make a point to extend 
> QoS signalling for:
> 
> 1) explicitly dealing with such "QoS exceptions" (there is also an economic 
> argument for this)
>      that is, not only signaling QoS preferences from applications to the 
> network, but also
>      QoS exceptions back from networks to applications or to between networks,
>      and an expected cooperative adaptation.
> 
> 2) allowing for flexible interpretations in different domains (core, 
> access, mobile, wireless,
>       administrative conditions, ....)
> 
> 
> The "trick" may be to modify signalling (including RSVP) such that most 
> flexibility/cooperation
> can be re-gained by assuring a minimum support of inflexibility 
> (intentionally not using the
> the term QoS guarantee here).
> 
> 
> --Hermann
> 
...

_______________________________________________
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 Jan 21 06:08: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 GAA05134
	for <nsis-archive@odin.ietf.org>; Mon, 21 Jan 2002 06:08:19 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id GAA01702
	for nsis-archive@odin.ietf.org; Mon, 21 Jan 2002 06:08: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 FAA01137;
	Mon, 21 Jan 2002 05:58: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 FAA01093
	for <nsis@optimus.ietf.org>; Mon, 21 Jan 2002 05:58:52 -0500 (EST)
Received: from cbibipnt05.hc.bt.com (saturn.bt.com [193.113.57.20])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04882
	for <nsis@ietf.org>; Mon, 21 Jan 2002 05:58:48 -0500 (EST)
From: dick.rr.knight@bt.com
Received: by cbibipnt05.hc.bt.com with Internet Mail Service (5.5.2652.35)
	id <DA1V4MQJ>; Mon, 21 Jan 2002 10:57:56 -0000
Message-ID: <451D45016C2CD2119DA50000F8FE7F07080E5A4D@mlngcbnt01.hc.bt.com>
To: Georgios.Karagiannis@eln.ericsson.se
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements
Date: Mon, 21 Jan 2002 10:49:14 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
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


Interesting. I agree.

If (for example) the mobile access network has not yet chosen a QoS
signalling solution, then we offer the NSIS solutiona s applicable to that
problem space. Good one.

Also the end host - end host 
Is this important as it implies the same routing mechanism will be used as
the user plane packets?

Dick

-----Original Message-----
From: Georgios Karagiannis (ELN)
[mailto:Georgios.Karagiannis@eln.ericsson.se]
Sent: 21 January 2002 10:30
To: 'dick.rr.knight@bt.com'
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements



Hi Dick

Please see my comment in line:
[DK]>> I do agree that it need not be processed on a per hop basis as it can
[DK]>> transverse a domain with a single QoS mechanism. That mechanism, be
it
[DK]>> diffserv or intserv, PNNI, RSVP, or even over-provisioning, takes
care of
[DK]>> the policing and the "path" establishment within the domain.

Please note that at the moment there are scenarios that will need to 
process the [everyhop] component. Some of these scenarios are the Radio
Access
Network and Mobile IP,..
Therefore, the [everyhop] component should be supported by the NSIS
protocol.
However a "host" or a "edge" should be able to activated or not.

Furthermore, in my opinion the NSIS protocol should be:
end host - end host: the NSIS protocol is terminated at end hosts;
end host - proxy: the NSIS protocol is terminated at end host and proxy;
end host - edge: the NSIS protocol is terminated at end end host and edge;
edge - edge: the NSIS protocol is terminated at egdes of one/multiple
domains;


Best regards,
Georgios


-----Original Message-----
From: Schneider, Marco [mailto:schneider@tri.sbc.com]
Sent: 18 January 2002 20:10
To: 'Roy, Radhika R, ALASO'; Gary Kenward; Loughney John (NRC/Helsinki);
brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
dick.rr.knight@bt.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


Hi Roy,

Below is the original text from your reponse to Gary Kenward. Hopefully the
context is clear.

"[Roy, Radhika R, ALARC]  I would say that it is the QOS needs of the
application (e.g., SIP-based VoIP) that the user likes to express (as
opposed to "service"). Similarly, instead of network services, we would say
network layer QOS services (e.g., RSVP, DiffServ, MPLS). We would develop
the end-to-end (application layer) QOS signaling protocol (say, NSIS QOS).
Now, there needs to have some kinds of standards how NSIS QOS will be mapped
over RSVP, DiffServ, MPLS, etc."

So by End-to-End you mean between directly between two "users". This is
session level signaling and I don't believe the signaling part is within the
scope of this working group. An application level QOS specification may be. 

After a session level agreement on QOS, the host/client/customer will need
to signal an actual reservation request to the network for the necessary QOS
agreed to at the session level. This is the protocol that we need to work
on. 

This approach is discussed in the SIP draft "SIP Extensions for Media
Authorization" (draft-ietf-sip-call-auth-03.txt) and the RAP draft
"Framework for session set-up with media authorization"
(draft-ietf-rap-session-auth-02.txt).

Marco Schneider

-----Original Message-----
From: Roy, Radhika R, ALASO [mailto:rrroy@att.com]
Sent: Friday, January 18, 2002 9:18 AM
To: Schneider, Marco; Gary Kenward; Loughney John (NRC/Helsinki);
brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
dick.rr.knight@bt.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


Defined below [RRR]

-----Original Message-----
From: Schneider, Marco [mailto:schneider@tri.sbc.com]
Sent: Thursday, January 17, 2002 8:47 PM
To: Roy, Radhika R, ALASO; Gary Kenward; Loughney John (NRC/Helsinki);
brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
dick.rr.knight@bt.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


Hi Roy,

Can you please define what you mean by "End-to-End Application Layer QOS
Signaling". Thanks.

[RRR] Suppose an user is initiation a SIP call to another user with audio,
video, and data. The use needs to express the needs of QOS for audio, video,
and data to another user. 

[RRR] The signaling mechanism that allows to express the QOS parameters of
audio, video, and data is termed as the "End-to-End Application Layer QOS
Signaling."

Marco Schneider

_______________________________________________
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  Mon Jan 21 06:22: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 GAA05462
	for <nsis-archive@odin.ietf.org>; Mon, 21 Jan 2002 06:22:05 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id GAA02019
	for nsis-archive@odin.ietf.org; Mon, 21 Jan 2002 06:22: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 GAA01811;
	Mon, 21 Jan 2002 06:12: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 GAA01782
	for <nsis@optimus.ietf.org>; Mon, 21 Jan 2002 06:12:48 -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 GAA05275
	for <nsis@ietf.org>; Mon, 21 Jan 2002 06:12:42 -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 g0LBCkw29493
	for <nsis@ietf.org>; Mon, 21 Jan 2002 12:12:46 +0100 (MET)
Received: FROM esealnt747.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Mon Jan 21 12:12:44 2002 +0100
Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <YHKTK8PN>; Mon, 21 Jan 2002 12:12:44 +0100
Message-ID: <E244E44D6AB85E40AEEF7EAABE3545FA823386@enleent104.nl.eu.ericsson.se>
From: "Georgios Karagiannis (ELN)" <Georgios.Karagiannis@eln.ericsson.se>
To: "'dick.rr.knight@bt.com'" <dick.rr.knight@bt.com>
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements
Date: Mon, 21 Jan 2002 12:12:40 +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 Dick

 
[DK] Also the end host - end host 
[DK] Is this important as it implies the same routing mechanism 
[DK] will be used asthe user plane packets?

I think that there are scenarios (and companies) that
need to apply such a type of NSIS protocol.
Please note that my proposed framework can be applied on any 
type of NSIS protocols, i.e., end to end, end to edge, edge to edge.

Best regards,
Georgios

-----Original Message-----
From: dick.rr.knight@bt.com [mailto:dick.rr.knight@bt.com]
Sent: maandag 21 januari 2002 11:49
To: Georgios.Karagiannis@eln.ericsson.se
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements



Interesting. I agree.

If (for example) the mobile access network has not yet chosen a QoS
signalling solution, then we offer the NSIS solutiona s applicable to that
problem space. Good one.

Also the end host - end host 
Is this important as it implies the same routing mechanism will be used as
the user plane packets?

Dick

-----Original Message-----
From: Georgios Karagiannis (ELN)
[mailto:Georgios.Karagiannis@eln.ericsson.se]
Sent: 21 January 2002 10:30
To: 'dick.rr.knight@bt.com'
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements



Hi Dick

Please see my comment in line:
[DK]>> I do agree that it need not be processed on a per hop basis as it can
[DK]>> transverse a domain with a single QoS mechanism. That mechanism, be
it
[DK]>> diffserv or intserv, PNNI, RSVP, or even over-provisioning, takes
care of
[DK]>> the policing and the "path" establishment within the domain.

Please note that at the moment there are scenarios that will need to 
process the [everyhop] component. Some of these scenarios are the Radio
Access
Network and Mobile IP,..
Therefore, the [everyhop] component should be supported by the NSIS
protocol.
However a "host" or a "edge" should be able to activated or not.

Furthermore, in my opinion the NSIS protocol should be:
end host - end host: the NSIS protocol is terminated at end hosts;
end host - proxy: the NSIS protocol is terminated at end host and proxy;
end host - edge: the NSIS protocol is terminated at end end host and edge;
edge - edge: the NSIS protocol is terminated at egdes of one/multiple
domains;


Best regards,
Georgios


-----Original Message-----
From: Schneider, Marco [mailto:schneider@tri.sbc.com]
Sent: 18 January 2002 20:10
To: 'Roy, Radhika R, ALASO'; Gary Kenward; Loughney John (NRC/Helsinki);
brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
dick.rr.knight@bt.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


Hi Roy,

Below is the original text from your reponse to Gary Kenward. Hopefully the
context is clear.

"[Roy, Radhika R, ALARC]  I would say that it is the QOS needs of the
application (e.g., SIP-based VoIP) that the user likes to express (as
opposed to "service"). Similarly, instead of network services, we would say
network layer QOS services (e.g., RSVP, DiffServ, MPLS). We would develop
the end-to-end (application layer) QOS signaling protocol (say, NSIS QOS).
Now, there needs to have some kinds of standards how NSIS QOS will be mapped
over RSVP, DiffServ, MPLS, etc."

So by End-to-End you mean between directly between two "users". This is
session level signaling and I don't believe the signaling part is within the
scope of this working group. An application level QOS specification may be. 

After a session level agreement on QOS, the host/client/customer will need
to signal an actual reservation request to the network for the necessary QOS
agreed to at the session level. This is the protocol that we need to work
on. 

This approach is discussed in the SIP draft "SIP Extensions for Media
Authorization" (draft-ietf-sip-call-auth-03.txt) and the RAP draft
"Framework for session set-up with media authorization"
(draft-ietf-rap-session-auth-02.txt).

Marco Schneider

-----Original Message-----
From: Roy, Radhika R, ALASO [mailto:rrroy@att.com]
Sent: Friday, January 18, 2002 9:18 AM
To: Schneider, Marco; Gary Kenward; Loughney John (NRC/Helsinki);
brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
dick.rr.knight@bt.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


Defined below [RRR]

-----Original Message-----
From: Schneider, Marco [mailto:schneider@tri.sbc.com]
Sent: Thursday, January 17, 2002 8:47 PM
To: Roy, Radhika R, ALASO; Gary Kenward; Loughney John (NRC/Helsinki);
brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
dick.rr.knight@bt.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


Hi Roy,

Can you please define what you mean by "End-to-End Application Layer QOS
Signaling". Thanks.

[RRR] Suppose an user is initiation a SIP call to another user with audio,
video, and data. The use needs to express the needs of QOS for audio, video,
and data to another user. 

[RRR] The signaling mechanism that allows to express the QOS parameters of
audio, video, and data is termed as the "End-to-End Application Layer QOS
Signaling."

Marco Schneider

_______________________________________________
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  Mon Jan 21 08:19: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 IAA08493
	for <nsis-archive@odin.ietf.org>; Mon, 21 Jan 2002 08:19:09 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id IAA06181
	for nsis-archive@odin.ietf.org; Mon, 21 Jan 2002 08:19: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 IAA05847;
	Mon, 21 Jan 2002 08:09: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 IAA05788
	for <nsis@optimus.ietf.org>; Mon, 21 Jan 2002 08:09:26 -0500 (EST)
Received: from mail-server.comgates.co.il ([212.150.198.2])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08038
	for <nsis@ietf.org>; Mon, 21 Jan 2002 08:09:21 -0500 (EST)
Received: by mail-server.comgates.co.il with Internet Mail Service (5.5.2653.19)
	id <DC2CZZY9>; Mon, 21 Jan 2002 15:09:47 +0200
Message-ID: <6FEF757325DBD411B7DA000629A8A61E7BAD6A@mail-server.comgates.co.il>
From: Yaron Kahana <ykahana@comgates.co.il>
To: "Geib, Ruediger" <Ruediger.Geib@t-systems.com>,
        gkenward@nortelnetworks.com, dick.rr.knight@bt.com,
        gilbert@rsch.comm.mot.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] Support needed for Throughput Adaptive QoS in wireless
Date: Mon, 21 Jan 2002 15:09:46 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C1A27C.E5FEA5C0"
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_01C1A27C.E5FEA5C0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Duediger,

We agree on the problems, and I'm not sure we are in dispute on the
solution. In my opinion, the old PSTN world DCME signaling should be
correlated to network resource management entity of the NGN.
The same applies for the 2nd example - I'm not sure, but I think the =
simple
solution of "First Come first Served" should not apply in a service =
oriented
world. If I am a tycoon that paid a lot to the telephone company, or if =
I'm
a doctor conducting en emergency phonecall, I would like the service
provider to differentiate my sessions from the others (doctors :-)). =
This
must be done by an entity that understand who is the user behind the
application.

Regards,

Yaron Kahana
COGITO Project Manager
ComGates Ltd.
Email: ykahana@comgates.com
Visit Us: www.comgates.com

-----Original Message-----
From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com]
Sent: Monday, January 21, 2002 11:15 AM
To: ykahana@comgates.co.il; gkenward@nortelnetworks.com;
dick.rr.knight@bt.com; gilbert@rsch.comm.mot.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] Support needed for Throughput Adaptive QoS in
wireless


>  I also think that the solution of over loading=20
>  should be managed by a local "higher hierarchy"=20
>  and not by the End-to-End reservation. This=20
>  local service controller should be aware of the=20
>  sessions, users, resources and commitments.=20
>  Hence could decide a "re-negotiation" or a drop.  =20

I'd favour adaptive applications also in the QoS case. Network to user
re-negotiation means more complexity and it requires extra signalling. =
Leave
it to the apps. A network may overbook, if it is aware that most apps =
are
adaptive. This requires no extra procedures.

Two further arguments:
- Plain old telephony used a compression scheme
  to save transatlantic capacity during high=20
  congestion (called DCME). No user was
  aware of that. The only extra signalling
  occured  between DCME units.=20

- Say you support re-negotiation. Your cell=20
  supports 10 QoS reservations and the ten
  of them are used. Number 11 wants to enter
  and triggers a re-negotiation. Do you=20
  re-negotiate all of the ten existing
  reservations? Only one? If so, how do you
  decide on the candidate in a fair way?

Regards, R=FCdiger =20

------_=_NextPart_001_01C1A27C.E5FEA5C0
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.2653.12">
<TITLE>RE: [NSIS] Support needed for Throughput Adaptive QoS in =
wireless</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Hi Duediger,</FONT>
</P>

<P><FONT SIZE=3D2>We agree on the problems, and I'm not sure we are in =
dispute on the solution. In my opinion, the old PSTN world DCME =
signaling should be correlated to network resource management entity of =
the NGN.</FONT></P>

<P><FONT SIZE=3D2>The same applies for the 2nd example - I'm not sure, =
but I think the simple solution of &quot;First Come first Served&quot; =
should not apply in a service oriented world. If I am a tycoon that =
paid a lot to the telephone company, or if I'm a doctor conducting en =
emergency phonecall, I would like the service provider to differentiate =
my sessions from the others (doctors :-)). This must be done by an =
entity that understand who is the user behind the =
application.</FONT></P>

<P><FONT SIZE=3D2>Regards,</FONT>
</P>

<P><FONT SIZE=3D2>Yaron Kahana</FONT>
<BR><FONT SIZE=3D2>COGITO Project Manager</FONT>
<BR><FONT SIZE=3D2>ComGates Ltd.</FONT>
<BR><FONT SIZE=3D2>Email: ykahana@comgates.com</FONT>
<BR><FONT SIZE=3D2>Visit Us: www.comgates.com</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Geib, Ruediger [<A =
HREF=3D"mailto:Ruediger.Geib@t-systems.com">mailto:Ruediger.Geib@t-syste=
ms.com</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Monday, January 21, 2002 11:15 AM</FONT>
<BR><FONT SIZE=3D2>To: ykahana@comgates.co.il; =
gkenward@nortelnetworks.com;</FONT>
<BR><FONT SIZE=3D2>dick.rr.knight@bt.com; =
gilbert@rsch.comm.mot.com</FONT>
<BR><FONT SIZE=3D2>Cc: nsis@ietf.org</FONT>
<BR><FONT SIZE=3D2>Subject: RE: [NSIS] Support needed for Throughput =
Adaptive QoS in</FONT>
<BR><FONT SIZE=3D2>wireless</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>&gt;&nbsp; I also think that the solution of over =
loading </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; should be managed by a local &quot;higher =
hierarchy&quot; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; and not by the End-to-End reservation. =
This </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; local service controller should be aware =
of the </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; sessions, users, resources and =
commitments. </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; Hence could decide a =
&quot;re-negotiation&quot; or a drop.&nbsp;&nbsp; </FONT>
</P>

<P><FONT SIZE=3D2>I'd favour adaptive applications also in the QoS =
case. Network to user re-negotiation means more complexity and it =
requires extra signalling. Leave it to the apps. A network may =
overbook, if it is aware that most apps are adaptive. This requires no =
extra procedures.</FONT></P>

<P><FONT SIZE=3D2>Two further arguments:</FONT>
<BR><FONT SIZE=3D2>- Plain old telephony used a compression =
scheme</FONT>
<BR><FONT SIZE=3D2>&nbsp; to save transatlantic capacity during high =
</FONT>
<BR><FONT SIZE=3D2>&nbsp; congestion (called DCME). No user was</FONT>
<BR><FONT SIZE=3D2>&nbsp; aware of that. The only extra =
signalling</FONT>
<BR><FONT SIZE=3D2>&nbsp; occured&nbsp; between DCME units. </FONT>
</P>

<P><FONT SIZE=3D2>- Say you support re-negotiation. Your cell </FONT>
<BR><FONT SIZE=3D2>&nbsp; supports 10 QoS reservations and the =
ten</FONT>
<BR><FONT SIZE=3D2>&nbsp; of them are used. Number 11 wants to =
enter</FONT>
<BR><FONT SIZE=3D2>&nbsp; and triggers a re-negotiation. Do you </FONT>
<BR><FONT SIZE=3D2>&nbsp; re-negotiate all of the ten existing</FONT>
<BR><FONT SIZE=3D2>&nbsp; reservations? Only one? If so, how do =
you</FONT>
<BR><FONT SIZE=3D2>&nbsp; decide on the candidate in a fair way?</FONT>
</P>

<P><FONT SIZE=3D2>Regards, R=FCdiger&nbsp; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1A27C.E5FEA5C0--

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



From daemon@optimus.ietf.org  Mon Jan 21 08:22: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 IAA08559
	for <nsis-archive@odin.ietf.org>; Mon, 21 Jan 2002 08:22:32 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id IAA06329
	for nsis-archive@odin.ietf.org; Mon, 21 Jan 2002 08:22: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 IAA05856;
	Mon, 21 Jan 2002 08: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 IAA05795
	for <nsis@optimus.ietf.org>; Mon, 21 Jan 2002 08:09:27 -0500 (EST)
Received: from mail-server.comgates.co.il ([212.150.198.2])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08039
	for <nsis@ietf.org>; Mon, 21 Jan 2002 08:09:23 -0500 (EST)
Received: by mail-server.comgates.co.il with Internet Mail Service (5.5.2653.19)
	id <DC2CZZY0>; Mon, 21 Jan 2002 15:09:50 +0200
Message-ID: <6FEF757325DBD411B7DA000629A8A61E7BAD6B@mail-server.comgates.co.il>
From: Yaron Kahana <ykahana@comgates.co.il>
To: "Geib, Ruediger" <Ruediger.Geib@t-systems.com>, dick.rr.knight@bt.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements   (unsupported domains + chi
	 c k en and eggs)
Date: Mon, 21 Jan 2002 15:09:49 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C1A27C.E7D20630"
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_01C1A27C.E7D20630
Content-Type: text/plain;
	charset="iso-8859-1"

Hi Duediger,

>If you look at inventions like e.g. "hot potato"/"cold potato" 
>routing, it may not be desirable to allow softening up a service 
>committment already while specifying the service.

What should happen in "a hard commitment" was given by the network, but the
network "doesn't walk the talk", i.e. does not fulfills its commitment? Do
you require the application to actually verify the level of service? do you
think it should happen in a very low probability (what is "low" here?)?

Regards,

Yaron Kahana
COGITO Project Manager
ComGates Ltd.
Email: ykahana@comgates.com
Visit Us: www.comgates.com
COMGATES - Powering the NGN



------_=_NextPart_001_01C1A27C.E7D20630
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.2653.12">
<TITLE>RE: [NSIS] Two kinds of requirements   (unsupported domains + =
chi c k en and eggs)</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Hi Duediger,</FONT>
</P>

<P><FONT SIZE=3D2>&gt;If you look at inventions like e.g. &quot;hot =
potato&quot;/&quot;cold potato&quot; </FONT>
<BR><FONT SIZE=3D2>&gt;routing, it may not be desirable to allow =
softening up a service </FONT>
<BR><FONT SIZE=3D2>&gt;committment already while specifying the =
service.</FONT>
</P>

<P><FONT SIZE=3D2>What should happen in &quot;a hard commitment&quot; =
was given by the network, but the network &quot;doesn't walk the =
talk&quot;, i.e. does not fulfills its commitment? Do you require the =
application to actually verify the level of service? do you think it =
should happen in a very low probability (what is &quot;low&quot; =
here?)?</FONT></P>

<P><FONT SIZE=3D2>Regards,</FONT>
</P>

<P><FONT SIZE=3D2>Yaron Kahana</FONT>
<BR><FONT SIZE=3D2>COGITO Project Manager</FONT>
<BR><FONT SIZE=3D2>ComGates Ltd.</FONT>
<BR><FONT SIZE=3D2>Email: ykahana@comgates.com</FONT>
<BR><FONT SIZE=3D2>Visit Us: www.comgates.com</FONT>
<BR><FONT SIZE=3D2>COMGATES - Powering the NGN</FONT>
</P>
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01C1A27C.E7D20630--

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



From daemon@optimus.ietf.org  Mon Jan 21 08:34:31 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09194
	for <nsis-archive@odin.ietf.org>; Mon, 21 Jan 2002 08:34:30 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id IAA07112
	for nsis-archive@odin.ietf.org; Mon, 21 Jan 2002 08:34: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 IAA06457;
	Mon, 21 Jan 2002 08:25: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 IAA06422
	for <nsis@optimus.ietf.org>; Mon, 21 Jan 2002 08:25:12 -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 IAA08711
	for <nsis@ietf.org>; Mon, 21 Jan 2002 08:25:07 -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 g0LDOru14888
	for <nsis@ietf.org>; Mon, 21 Jan 2002 15:24:53 +0200 (EET)
Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T58960f518dac158f25078@esvir05nok.ntc.nokia.com>;
 Mon, 21 Jan 2002 15:25:08 +0200
Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779);
	 Mon, 21 Jan 2002 15:25:08 +0200
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [NSIS] Support needed for Throughput Adaptive QoS in wireless
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
Date: Mon, 21 Jan 2002 15:25:08 +0200
Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF5D93CB@esebe004.NOE.Nokia.com>
Thread-Topic: [NSIS] Support needed for Throughput Adaptive QoS in wireless
Thread-Index: AcGiXoD85h9M2BgiRn60j6Lf9Yp98wAID8Eg
To: <Ruediger.Geib@t-systems.com>
Cc: <nsis@ietf.org>
X-OriginalArrivalTime: 21 Jan 2002 13:25:08.0385 (UTC) FILETIME=[0BB21110:01C1A27F]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id IAA06423
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 also think that the solution of over loading 
> >  should be managed by a local "higher hierarchy" 
> >  and not by the End-to-End reservation. This 
> >  local service controller should be aware of the 
> >  sessions, users, resources and commitments. 
> >  Hence could decide a "re-negotiation" or a drop.   
> 
> I'd favour adaptive applications also in the QoS case. 
> Network to user re-negotiation means more complexity and it 
> requires extra signalling. Leave it to the apps. A network 
> may overbook, if it is aware that most apps are adaptive. 
> This requires no extra procedures.

NSIS cannot insist on adaptive applications, that is out of
scope.  Perhaps we could think that an NSIS protocol
could support re-negotiation (and allow a user to insist
on no re-negotiaion - but this starts to get into policy).

John

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



From daemon@optimus.ietf.org  Mon Jan 21 08:40:27 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09431
	for <nsis-archive@odin.ietf.org>; Mon, 21 Jan 2002 08:40:22 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id IAA07384
	for nsis-archive@odin.ietf.org; Mon, 21 Jan 2002 08:40: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 IAA06580;
	Mon, 21 Jan 2002 08:28:07 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA06508
	for <nsis@optimus.ietf.org>; Mon, 21 Jan 2002 08:28:03 -0500 (EST)
Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08804
	for <nsis@ietf.org>; Mon, 21 Jan 2002 08:27:58 -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 g0LDRju16553
	for <nsis@ietf.org>; Mon, 21 Jan 2002 15:27:45 +0200 (EET)
Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T589611f1daac158f25078@esvir05nok.ntc.nokia.com>;
 Mon, 21 Jan 2002 15:28:00 +0200
Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779);
	 Mon, 21 Jan 2002 15:28:00 +0200
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [NSIS] Charter of nsis
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
Date: Mon, 21 Jan 2002 15:27:59 +0200
Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF5D93CC@esebe004.NOE.Nokia.com>
Thread-Topic: [NSIS] Charter of nsis
Thread-Index: AcGgWe61HTr5tNx1QxafZFEFP5JnjQCJUklA
To: <berson@isi.edu>
Cc: <jmaeng@ipdialog.com>, <nsis@ietf.org>
X-OriginalArrivalTime: 21 Jan 2002 13:28:00.0533 (UTC) FILETIME=[724DC450:01C1A27F]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id IAA06509
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 Steven,

> RSVP is just the signalling.  Please take the time to read RFC 2205
> (and associated documents) if there is any confusion.  Perhaps, a 
> reading list (in priority order) about RSVP and Integrated Services 
> would be useful.

Thanks for the reading list.  I would agree with your (unwritten)
statement that RSVP is quite often equated with Intserv.  I still
think that for NSIS, a simplification of the RSVP signaling and
signaling model would be a good goal.

best regards,
John

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



From daemon@optimus.ietf.org  Mon Jan 21 08:48: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 IAA09571
	for <nsis-archive@odin.ietf.org>; Mon, 21 Jan 2002 08:48:24 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id IAA07600
	for nsis-archive@odin.ietf.org; Mon, 21 Jan 2002 08:48: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 IAA07306;
	Mon, 21 Jan 2002 08:39: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 IAA07271
	for <nsis@optimus.ietf.org>; Mon, 21 Jan 2002 08:39:14 -0500 (EST)
Received: from mail1.telekom.de ([62.225.183.235])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09385
	for <nsis@ietf.org>; Mon, 21 Jan 2002 08:39:11 -0500 (EST)
Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Mon, 21 Jan 2002 14:36:22 +0100
Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19)
	id <ZLG2QRMB>; Mon, 21 Jan 2002 14:37:55 +0100
Message-Id: <DFD875E85664D3118FA6080006277DE70362C834@U8PN2>
From: "Geib, Ruediger" <Ruediger.Geib@t-systems.com>
To: ykahana@comgates.co.il, dick.rr.knight@bt.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements   (unsupported domains + chi
	 c k en and eggs)
Date: Mon, 21 Jan 2002 14:37:45 +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 IAA07272
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

Dear Yaron,
 
>> If you look at inventions like e.g. "hot potato"/"cold potato" 
>> routing, it may not be desirable to allow softening up a service 
>> committment already while specifying the service. 

Y> What should happen in "a hard commitment" was given by the
Y> network, but the network "doesn't walk the talk", i.e. does
Y> not fulfills its commitment? Do you require the application
Y> to actually verify the level of service? do you think it 
Y> should happen in a very low probability (what is "low" here?)?

If the required resources are unavailble during reservation set up, a "busy" signal is appropriate. In my view (service specific) network planning and provisioning are the tools to prevent busy signals, not softened up service specifications.

If a service quality is temporary degraded while a reservation is active, usually a definition for unavailability is fixed by a contract. 

Regards, Rüdiger 

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



From daemon@optimus.ietf.org  Mon Jan 21 09:00: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 JAA09970
	for <nsis-archive@odin.ietf.org>; Mon, 21 Jan 2002 09:00:15 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id JAA08151
	for nsis-archive@odin.ietf.org; Mon, 21 Jan 2002 09:00: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 IAA07924;
	Mon, 21 Jan 2002 08:58: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 IAA07891
	for <nsis@optimus.ietf.org>; Mon, 21 Jan 2002 08:58:52 -0500 (EST)
Received: from mail1.telekom.de ([62.225.183.235])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09922
	for <nsis@ietf.org>; Mon, 21 Jan 2002 08:58:50 -0500 (EST)
Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Mon, 21 Jan 2002 14:55:47 +0100
Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19)
	id <ZLG2QS24>; Mon, 21 Jan 2002 14:57:24 +0100
Message-Id: <DFD875E85664D3118FA6080006277DE70362C835@U8PN2>
From: "Geib, Ruediger" <Ruediger.Geib@t-systems.com>
To: ykahana@comgates.co.il, "Geib, Ruediger" <Ruediger.Geib@t-systems.com>
Cc: nsis@ietf.org
Subject: RE: [NSIS] Support needed for Throughput Adaptive QoS in wireless
Date: Mon, 21 Jan 2002 14:57:18 +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 IAA07892
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

Dear Yaron,

Solutions may be different service definitions for the doctor and the standard customer, preemption or a very high service availability. I'm not sure whether a "911" call preempts busy lines in Germany. But to the best of my knowledge, services and networks which are used to support emergency calls must be very reliabile, even if preemption is added as a secondary measure to ensure success. 
I however don't favour preemption as a general tool to differentiate services. It requires additional signalling, network planning and network monitoring. Service descriptions get more complex: a preemption event means a reduced service availability. But to what degree can you control availability decrease caused by preemption?

Regards, Rüdiger 

Y> The same applies for the 2nd example - I'm not 
Y> sure, but I think the simple solution of "First
Y> Come first Served" should not apply in a service
Y> oriented world. If I am a tycoon that paid a lot
Y> to the telephone company, or if I'm a doctor 
Y> conducting en emergency phonecall, I would like
Y> the service provider to differentiate my sessions
Y> from the others (doctors :-)). This must be done
Y> by an entity that understand who is the user 
Y> behind the application.

R> Say you support re-negotiation. Your cell 
R> supports 10 QoS reservations and the ten 
R> of them are used. Number 11 wants to enter 
R> and triggers a re-negotiation. Do you 
R> re-negotiate all of the ten existing 
R> reservations? Only one? If so, how do you 
R> decide on the candidate in a fair way? 
  

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



From daemon@optimus.ietf.org  Mon Jan 21 09:04: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 JAA10063
	for <nsis-archive@odin.ietf.org>; Mon, 21 Jan 2002 09:04:43 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id JAA08638
	for nsis-archive@odin.ietf.org; Mon, 21 Jan 2002 09:04: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 JAA08621;
	Mon, 21 Jan 2002 09:03:58 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA08590
	for <nsis@optimus.ietf.org>; Mon, 21 Jan 2002 09:03:57 -0500 (EST)
Received: from mail1.telekom.de ([62.225.183.235])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10056
	for <nsis@ietf.org>; Mon, 21 Jan 2002 09:03:54 -0500 (EST)
Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Mon, 21 Jan 2002 15:01:34 +0100
Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19)
	id <ZLG2QSRV>; Mon, 21 Jan 2002 15:03:11 +0100
Message-Id: <DFD875E85664D3118FA6080006277DE70362C836@U8PN2>
From: "Geib, Ruediger" <Ruediger.Geib@t-systems.com>
To: john.loughney@nokia.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] Support needed for Throughput Adaptive QoS in wireless
Date: Mon, 21 Jan 2002 15:03:00 +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 JAA08591
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'd favour adaptive applications also in the QoS case. 
> > Network to user re-negotiation means more complexity and it 
> > requires extra signalling. Leave it to the apps. A network 
> > may overbook, if it is aware that most apps are adaptive. 
> > This requires no extra procedures.
> 
> NSIS cannot insist on adaptive applications, that is out of
> scope.  Perhaps we could think that an NSIS protocol
> could support re-negotiation (and allow a user to insist
> on no re-negotiaion - but this starts to get into policy).

I don't demand adaptive applications. All I say is that negotiation is not a basic QoS signalling requirement. 

Regards, Rüdiger

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



From daemon@optimus.ietf.org  Mon Jan 21 09:15: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 JAA10340
	for <nsis-archive@odin.ietf.org>; Mon, 21 Jan 2002 09:15:16 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id JAA08911
	for nsis-archive@odin.ietf.org; Mon, 21 Jan 2002 09:15: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 JAA08560;
	Mon, 21 Jan 2002 09:01: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 JAA08525
	for <nsis@optimus.ietf.org>; Mon, 21 Jan 2002 09:01:52 -0500 (EST)
Received: from ckmso1.proxy.att.com (ckmso1.att.com [12.20.58.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10031
	for <nsis@ietf.org>; Mon, 21 Jan 2002 09:01:48 -0500 (EST)
Received: from attrh1i.attrh.att.com ([135.71.62.10])
	by ckmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id g0LE0hZ08678
	for <nsis@ietf.org>; Mon, 21 Jan 2002 09:01:01 -0500 (EST)
Received: from occlust04evs1.ugd.att.com (135.71.164.13) by attrh1i.attrh.att.com (5.5.029)
        id 3C0BA3A50023B49F; Mon, 21 Jan 2002 08:59:31 -0500
content-class: urn:content-classes:message
Subject: RE: [NSIS] Charter of nsis
Date: Mon, 21 Jan 2002 08:59:31 -0500
Message-ID: <62DA45D4963FA747BA1B253E266760F9011E7A37@OCCLUST04EVS1.ugd.att.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Thread-Topic: [NSIS] Charter of nsis
Thread-Index: AcGigTY2YZeOHQ5uEdaVVQCQJ2GH0wAASeEA
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
From: "Roy, Radhika R, ALASO" <rrroy@att.com>
To: <john.loughney@nokia.com>, <berson@isi.edu>
Cc: <jmaeng@ipdialog.com>, <nsis@ietf.org>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id JAA08526
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, John:

I agree with you, but I add a little more [RRR].

Best regards,
Radhika

-----Original Message-----
From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]
Sent: Monday, January 21, 2002 8:28 AM
To: berson@isi.edu
Cc: jmaeng@ipdialog.com; nsis@ietf.org
Subject: RE: [NSIS] Charter of nsis


Hi Steven,

> RSVP is just the signalling.  Please take the time to read RFC 2205
> (and associated documents) if there is any confusion.  Perhaps, a 
> reading list (in priority order) about RSVP and Integrated Services 
> would be useful.

Thanks for the reading list.  I would agree with your (unwritten)
statement that RSVP is quite often equated with Intserv.  I still
think that for NSIS, a simplification of the RSVP signaling and
signaling model would be a good goal.

[RRR] It would be better if we could decouple the end-to-end QOS signaling at the application layer and the resource reservation at the transport/network/physical layer per QOS signaling.

[RRR] There is another part of it. For example, the end-to-end QOS signaling at the application layer may require resource reservation in different layers as well: 1. Transport layer (e.g., ports), 2. Network layer (e.g., IP address, bandwidth), 3. physical layer/optical layer (e.g., bandwidth) and so forth.

[RRR] Our goal will be to develop the end-to-end QOS signaling (e.g., NSIS QOS) at the application layer that will meet the requirements of the application (which may consist of different media: audio, video, and/or data). The NSIS QOS will be independent of the lower transport/network/physical layer QOS signaling.

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 Jan 21 10:06: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 KAA11610
	for <nsis-archive@odin.ietf.org>; Mon, 21 Jan 2002 10:06:20 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id KAA11149
	for nsis-archive@odin.ietf.org; Mon, 21 Jan 2002 10:06: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 JAA10029;
	Mon, 21 Jan 2002 09:53: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 JAA09999
	for <nsis@optimus.ietf.org>; Mon, 21 Jan 2002 09:53:34 -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 JAA11121
	for <nsis@ietf.org>; Mon, 21 Jan 2002 09:53:31 -0500 (EST)
Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56])
	by zcars0m9.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g0LEr2d18872;
	Mon, 21 Jan 2002 09:53:02 -0500 (EST)
Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7])
	by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g0LEqtL20848;
	Mon, 21 Jan 2002 09:52:55 -0500 (EST)
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19)
	id <C8PZXKT7>; Mon, 21 Jan 2002 09:52:57 -0500
Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA478C@zcard031.ca.nortel.com>
From: "Gary Kenward"<gkenward@nortelnetworks.com>
To: "'Schneider, Marco'" <schneider@tri.sbc.com>,
        "'Roy, Radhika R, ALASO'" <rrroy@att.com>,
        "Loughney John (NRC/Helsinki)"
	 <john.loughney@nokia.com>,
        brunner@ccrle.nec.de, Yaron Kahana
	 <ykahana@comgates.co.il>,
        "Geib, Ruediger" <Ruediger.Geib@t-systems.com>, dick.rr.knight@bt.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements
Date: Mon, 21 Jan 2002 09:52:55 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C1A28B.4F351FC0"
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_01C1A28B.4F351FC0
Content-Type: text/plain;
	charset="ISO-8859-1"

Marco:

  I believe I see why you characterize end-to-end QoS signalling to the
the session layer. What seems to be missing here is a model for how
QoS is signalled at the transport layer to set up the required transport
(and underlying mechanisms). 

  I don't believe you are proposing a "layering" of signalling protocols, 
one for session establishment, then one for transport, etc. So, the
question,
becomes, how are the QoS transport mechanisms established? In the internet 
model there is only one end-to-end transport session (e.g. TCP, RTP, UDP), 
but underneath the transport is a series of inter-connected networks, each 
with potentially different characteristics. 

  This is end-to-end QoS support structure has to be set up and maintained
in order for the end to end session QoS to be realized. The solution may be
a single protocol that travels from host to host, such as RSVP, or it may
be a collection of protocols that are optimized for each portion of the
end-to-end path: e.g. host to access network, access to core network, 
core to core network, etc.

  It is too early to determine which approach is best, but in either case,
do we not need to understand the end-to-end requirements for this signalling
capability?

Gary Kenward

> -----Original Message-----
> From: Schneider, Marco [mailto:schneider@tri.sbc.com]
> Sent: January 18, 2002 15:10
> To: 'Roy, Radhika R, ALASO'; Kenward, Gary [WDLN2:AN10:EXCH]; Loughney
> John (NRC/Helsinki); brunner@ccrle.nec.de; Yaron Kahana; 
> Geib, Ruediger;
> dick.rr.knight@bt.com
> Cc: nsis@ietf.org
> Subject: RE: [NSIS] Two kinds of requirements
> 
> 
> Hi Roy,
> 
> Below is the original text from your reponse to Gary Kenward. 
> Hopefully the
> context is clear.
> 
> "[Roy, Radhika R, ALARC]  I would say that it is the QOS needs of the
> application (e.g., SIP-based VoIP) that the user likes to express (as
> opposed to "service"). Similarly, instead of network 
> services, we would say
> network layer QOS services (e.g., RSVP, DiffServ, MPLS). We 
> would develop
> the end-to-end (application layer) QOS signaling protocol 
> (say, NSIS QOS).
> Now, there needs to have some kinds of standards how NSIS QOS 
> will be mapped
> over RSVP, DiffServ, MPLS, etc."
> 
> So by End-to-End you mean between directly between two 
> "users". This is
> session level signaling and I don't believe the signaling 
> part is within the
> scope of this working group. An application level QOS 
> specification may be. 
> 
> After a session level agreement on QOS, the 
> host/client/customer will need
> to signal an actual reservation request to the network for 
> the necessary QOS
> agreed to at the session level. This is the protocol that we 
> need to work
> on. 
> 
> This approach is discussed in the SIP draft "SIP Extensions for Media
> Authorization" (draft-ietf-sip-call-auth-03.txt) and the RAP draft
> "Framework for session set-up with media authorization"
> (draft-ietf-rap-session-auth-02.txt).
> 
> Marco Schneider
> 
> -----Original Message-----
> From: Roy, Radhika R, ALASO [mailto:rrroy@att.com]
> Sent: Friday, January 18, 2002 9:18 AM
> To: Schneider, Marco; Gary Kenward; Loughney John (NRC/Helsinki);
> brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
> dick.rr.knight@bt.com
> Cc: nsis@ietf.org
> Subject: RE: [NSIS] Two kinds of requirements
> 
> 
> Defined below [RRR]
> 
> -----Original Message-----
> From: Schneider, Marco [mailto:schneider@tri.sbc.com]
> Sent: Thursday, January 17, 2002 8:47 PM
> To: Roy, Radhika R, ALASO; Gary Kenward; Loughney John (NRC/Helsinki);
> brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
> dick.rr.knight@bt.com
> Cc: nsis@ietf.org
> Subject: RE: [NSIS] Two kinds of requirements
> 
> 
> Hi Roy,
> 
> Can you please define what you mean by "End-to-End 
> Application Layer QOS
> Signaling". Thanks.
> 
> [RRR] Suppose an user is initiation a SIP call to another 
> user with audio,
> video, and data. The use needs to express the needs of QOS 
> for audio, video,
> and data to another user. 
> 
> [RRR] The signaling mechanism that allows to express the QOS 
> parameters of
> audio, video, and data is termed as the "End-to-End 
> Application Layer QOS
> Signaling."
> 
> Marco Schneider
> 
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis
> 

------_=_NextPart_001_01C1A28B.4F351FC0
Content-Type: text/html;
	charset="ISO-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2654.89">
<TITLE>RE: [NSIS] Two kinds of requirements</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Marco:</FONT>
</P>

<P><FONT SIZE=2>&nbsp; I believe I see why you characterize end-to-end QoS signalling to the</FONT>
<BR><FONT SIZE=2>the session layer. What seems to be missing here is a model for how</FONT>
<BR><FONT SIZE=2>QoS is signalled at the transport layer to set up the required transport</FONT>
<BR><FONT SIZE=2>(and underlying mechanisms). </FONT>
</P>

<P><FONT SIZE=2>&nbsp; I don't believe you are proposing a &quot;layering&quot; of signalling protocols, </FONT>
<BR><FONT SIZE=2>one for session establishment, then one for transport, etc. So, the question,</FONT>
<BR><FONT SIZE=2>becomes, how are the QoS transport mechanisms established? In the internet </FONT>
<BR><FONT SIZE=2>model there is only one end-to-end transport session (e.g. TCP, RTP, UDP), </FONT>
<BR><FONT SIZE=2>but underneath the transport is a series of inter-connected networks, each </FONT>
<BR><FONT SIZE=2>with potentially different characteristics. </FONT>
</P>

<P><FONT SIZE=2>&nbsp; This is end-to-end QoS support structure has to be set up and maintained</FONT>
<BR><FONT SIZE=2>in order for the end to end session QoS to be realized. The solution may be</FONT>
<BR><FONT SIZE=2>a single protocol that travels from host to host, such as RSVP, or it may</FONT>
<BR><FONT SIZE=2>be a collection of protocols that are optimized for each portion of the</FONT>
<BR><FONT SIZE=2>end-to-end path: e.g. host to access network, access to core network, </FONT>
<BR><FONT SIZE=2>core to core network, etc.</FONT>
</P>

<P><FONT SIZE=2>&nbsp; It is too early to determine which approach is best, but in either case,</FONT>
<BR><FONT SIZE=2>do we not need to understand the end-to-end requirements for this signalling</FONT>
<BR><FONT SIZE=2>capability?</FONT>
</P>

<P><FONT SIZE=2>Gary Kenward</FONT>
</P>

<P><FONT SIZE=2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; From: Schneider, Marco [<A HREF="mailto:schneider@tri.sbc.com">mailto:schneider@tri.sbc.com</A>]</FONT>
<BR><FONT SIZE=2>&gt; Sent: January 18, 2002 15:10</FONT>
<BR><FONT SIZE=2>&gt; To: 'Roy, Radhika R, ALASO'; Kenward, Gary [WDLN2:AN10:EXCH]; Loughney</FONT>
<BR><FONT SIZE=2>&gt; John (NRC/Helsinki); brunner@ccrle.nec.de; Yaron Kahana; </FONT>
<BR><FONT SIZE=2>&gt; Geib, Ruediger;</FONT>
<BR><FONT SIZE=2>&gt; dick.rr.knight@bt.com</FONT>
<BR><FONT SIZE=2>&gt; Cc: nsis@ietf.org</FONT>
<BR><FONT SIZE=2>&gt; Subject: RE: [NSIS] Two kinds of requirements</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Hi Roy,</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Below is the original text from your reponse to Gary Kenward. </FONT>
<BR><FONT SIZE=2>&gt; Hopefully the</FONT>
<BR><FONT SIZE=2>&gt; context is clear.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &quot;[Roy, Radhika R, ALARC]&nbsp; I would say that it is the QOS needs of the</FONT>
<BR><FONT SIZE=2>&gt; application (e.g., SIP-based VoIP) that the user likes to express (as</FONT>
<BR><FONT SIZE=2>&gt; opposed to &quot;service&quot;). Similarly, instead of network </FONT>
<BR><FONT SIZE=2>&gt; services, we would say</FONT>
<BR><FONT SIZE=2>&gt; network layer QOS services (e.g., RSVP, DiffServ, MPLS). We </FONT>
<BR><FONT SIZE=2>&gt; would develop</FONT>
<BR><FONT SIZE=2>&gt; the end-to-end (application layer) QOS signaling protocol </FONT>
<BR><FONT SIZE=2>&gt; (say, NSIS QOS).</FONT>
<BR><FONT SIZE=2>&gt; Now, there needs to have some kinds of standards how NSIS QOS </FONT>
<BR><FONT SIZE=2>&gt; will be mapped</FONT>
<BR><FONT SIZE=2>&gt; over RSVP, DiffServ, MPLS, etc.&quot;</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; So by End-to-End you mean between directly between two </FONT>
<BR><FONT SIZE=2>&gt; &quot;users&quot;. This is</FONT>
<BR><FONT SIZE=2>&gt; session level signaling and I don't believe the signaling </FONT>
<BR><FONT SIZE=2>&gt; part is within the</FONT>
<BR><FONT SIZE=2>&gt; scope of this working group. An application level QOS </FONT>
<BR><FONT SIZE=2>&gt; specification may be. </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; After a session level agreement on QOS, the </FONT>
<BR><FONT SIZE=2>&gt; host/client/customer will need</FONT>
<BR><FONT SIZE=2>&gt; to signal an actual reservation request to the network for </FONT>
<BR><FONT SIZE=2>&gt; the necessary QOS</FONT>
<BR><FONT SIZE=2>&gt; agreed to at the session level. This is the protocol that we </FONT>
<BR><FONT SIZE=2>&gt; need to work</FONT>
<BR><FONT SIZE=2>&gt; on. </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; This approach is discussed in the SIP draft &quot;SIP Extensions for Media</FONT>
<BR><FONT SIZE=2>&gt; Authorization&quot; (draft-ietf-sip-call-auth-03.txt) and the RAP draft</FONT>
<BR><FONT SIZE=2>&gt; &quot;Framework for session set-up with media authorization&quot;</FONT>
<BR><FONT SIZE=2>&gt; (draft-ietf-rap-session-auth-02.txt).</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Marco Schneider</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; From: Roy, Radhika R, ALASO [<A HREF="mailto:rrroy@att.com">mailto:rrroy@att.com</A>]</FONT>
<BR><FONT SIZE=2>&gt; Sent: Friday, January 18, 2002 9:18 AM</FONT>
<BR><FONT SIZE=2>&gt; To: Schneider, Marco; Gary Kenward; Loughney John (NRC/Helsinki);</FONT>
<BR><FONT SIZE=2>&gt; brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;</FONT>
<BR><FONT SIZE=2>&gt; dick.rr.knight@bt.com</FONT>
<BR><FONT SIZE=2>&gt; Cc: nsis@ietf.org</FONT>
<BR><FONT SIZE=2>&gt; Subject: RE: [NSIS] Two kinds of requirements</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Defined below [RRR]</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; From: Schneider, Marco [<A HREF="mailto:schneider@tri.sbc.com">mailto:schneider@tri.sbc.com</A>]</FONT>
<BR><FONT SIZE=2>&gt; Sent: Thursday, January 17, 2002 8:47 PM</FONT>
<BR><FONT SIZE=2>&gt; To: Roy, Radhika R, ALASO; Gary Kenward; Loughney John (NRC/Helsinki);</FONT>
<BR><FONT SIZE=2>&gt; brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;</FONT>
<BR><FONT SIZE=2>&gt; dick.rr.knight@bt.com</FONT>
<BR><FONT SIZE=2>&gt; Cc: nsis@ietf.org</FONT>
<BR><FONT SIZE=2>&gt; Subject: RE: [NSIS] Two kinds of requirements</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Hi Roy,</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Can you please define what you mean by &quot;End-to-End </FONT>
<BR><FONT SIZE=2>&gt; Application Layer QOS</FONT>
<BR><FONT SIZE=2>&gt; Signaling&quot;. Thanks.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; [RRR] Suppose an user is initiation a SIP call to another </FONT>
<BR><FONT SIZE=2>&gt; user with audio,</FONT>
<BR><FONT SIZE=2>&gt; video, and data. The use needs to express the needs of QOS </FONT>
<BR><FONT SIZE=2>&gt; for audio, video,</FONT>
<BR><FONT SIZE=2>&gt; and data to another user. </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; [RRR] The signaling mechanism that allows to express the QOS </FONT>
<BR><FONT SIZE=2>&gt; parameters of</FONT>
<BR><FONT SIZE=2>&gt; audio, video, and data is termed as the &quot;End-to-End </FONT>
<BR><FONT SIZE=2>&gt; Application Layer QOS</FONT>
<BR><FONT SIZE=2>&gt; Signaling.&quot;</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Marco Schneider</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; _______________________________________________</FONT>
<BR><FONT SIZE=2>&gt; nsis mailing list</FONT>
<BR><FONT SIZE=2>&gt; nsis@ietf.org</FONT>
<BR><FONT SIZE=2>&gt; <A HREF="https://www1.ietf.org/mailman/listinfo/nsis" TARGET="_blank">https://www1.ietf.org/mailman/listinfo/nsis</A></FONT>
<BR><FONT SIZE=2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1A28B.4F351FC0--

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



From daemon@optimus.ietf.org  Mon Jan 21 10:06: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 KAA11626
	for <nsis-archive@odin.ietf.org>; Mon, 21 Jan 2002 10:06:24 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id KAA11168
	for nsis-archive@odin.ietf.org; Mon, 21 Jan 2002 10:06:26 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA10918;
	Mon, 21 Jan 2002 10:01:42 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA10850
	for <nsis@optimus.ietf.org>; Mon, 21 Jan 2002 10:01:38 -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 KAA11475
	for <nsis@ietf.org>; Mon, 21 Jan 2002 10:01:34 -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 g0LF15d02917;
	Mon, 21 Jan 2002 10:01:06 -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 g0LF13a13040;
	Mon, 21 Jan 2002 10:01:04 -0500 (EST)
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19)
	id <C8PZXK98>; Mon, 21 Jan 2002 10:01:04 -0500
Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA478D@zcard031.ca.nortel.com>
From: "Gary Kenward"<gkenward@nortelnetworks.com>
To: "'Yaron Kahana'" <ykahana@comgates.co.il>,
        "'dick.rr.knight@bt.com'"
	 <dick.rr.knight@bt.com>,
        gilbert@rsch.comm.mot.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] Support needed for Throughput Adaptive QoS in wireless
Date: Mon, 21 Jan 2002 10:01:01 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C1A28C.7108FC60"
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_01C1A28C.7108FC60
Content-Type: text/plain;
	charset="ISO-8859-1"

Yaron:
 
  The difference with handover in mobile networks is a matter of time
constraints. Handovers
can happen very frequently, and often happen during an active session. For
some applications,
such as best effort applications, re-negotiation of QoS using a high layer
protocol may be viable,
however, for many other services, most notably voice and video, there simply
is not enough time 
before the service is disrupted.
 
   The "re-negotiation" during handoff being referred to is not, I believe,
the same as the negotiation
during session set-up. If it were, then yes, it should happen at a higher
layer, and as I have alluded to
above, not likely to help the situation much. I would go so far as to say
that the situation during a
handover is not so much "re-negotiation" as "notification" of a change in
QoS. However, this gets
deep into the solution space, and unless there is a need for use to explore
it in order to understand
the requirement, we should defer the discussion.
 
Gary

-----Original Message-----
From: Yaron Kahana [mailto:ykahana@comgates.co.il]
Sent: January 19, 2002 14:27
To: Kenward, Gary [WDLN2:AN10:EXCH]; 'dick.rr.knight@bt.com';
gilbert@rsch.comm.mot.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] Support needed for Throughput Adaptive QoS in wireless


Hi all,
 
I think that the describe situation is:
1) NOT unique to the mobile case.
2) Should be handled by a "higher hierarchy".
 
I think that the described example is the derivative of unpredictable over
loading of resources, and is rather common (for example through Erlang
distribution?). The mobile case, with its relative high dynamic users, can
still perform the correct network planning work to handle such cases. The
NGN, whereas the users will have their services linked to their "entity" and
not to their landline, will have to deal with it as well.
 
I also think that the solution of over loading should be managed by a local
"higher hierarchy" and not by the End-to-End reservation. This local service
controller should be aware of the sessions, users, resources and
commitments. Hence could decide a "re-negotiation" or a drop. Think about
the case that there is an emergency call in the cell (911) and it is being
dropped or degraded?
 
I'm not sure this is within NSIS scope, but this service controller
(softswitch?) should be aware of the resources reservation and should manage
the allocation of resources and admission control (see TIPHON
DTS02009v044.doc).
 
Best Regards,
 
Yaron Kahana
COGITO Project Manager
COMGATES
www.comgates.com <http://www.comgates.com> 
 
 

-----Original Message-----
From: Gary Kenward [mailto:gkenward@nortelnetworks.com]
Sent: Friday, January 18, 2002 7:31 PM
To: 'dick.rr.knight@bt.com'; gilbert@rsch.comm.mot.com; nsis@ietf.org
Subject: RE: [NSIS] Support needed for Throughput Adaptive QoS in wireless



Steve: 

  I don't believe that Dick is proposing that NSIS accomodate 
rate adaption, I believe that the issue is QoS re-negotiation 
to allow better handoff performance. 
  
  The situation is simply that if the admission control used 
during a handoff is "all or nothing" then the likelihood the 
flows of the mobile user will be dropped when a handoff occurs is 
much higher. "Re-negotiation" of QoS allows the network to reduce 
the resource demands to the point that the new access router 
can handle the flows, at least to some degree. 

  Re-negotiation can mean many different solution scenarios. 
At the extremes, the solution could be an NSIS negotiation 
protocol between mobile and access network; a "minimum" QoS 
that the network that is allowed as a fallback to allow the 
handoff to occur. Note that in either case, the result may 
mean dropping of specific flows that cannot be support (e.g. 
the video portion of a multimedia session). 

The second scenario does not necessarly require interaction 
with the mobile or other networks and thus may 
not impact NSIS.  However, it might be a good thing for the 
network to tell the mobile that the QoS had been degraded, 
thus allowing the mobile application to "adapt". NSIS does not 
need to participate in the adaption, it would simply provide 
the information on the new QoS. 

I think the requirement here is for the NSIS wg to consider 
all the options. 

Gary 


> -----Original Message----- 
> From: dick.rr.knight@bt.com [ mailto:dick.rr.knight@bt.com
<mailto:dick.rr.knight@bt.com> ] 
> Sent: January 18, 2002 11:51 
> To: gilbert@rsch.comm.mot.com; nsis@ietf.org 
> Subject: RE: [NSIS] Support needed for Throughput Adaptive QoS in 
> wireless 
> 
> 
> 
> There are some important points in this email. Probably 
> obvious for people 
> with wireless backgrounds, but a bit more of a surprise for wired 
> backgrounds. 
> 
> I personally don't see NSIS as trying to solve the rate 
> adaptation needs of 
> the wireless access network. I can see that it is very much 
> needed, but it 
> is rather more specialised than a generic signalling protocol for QoS 
> requests. This looks like a charter debate. 
> 
> The wireless access network definitely needs some QoS 
> signalling support, 
> but as you have shown, it is specific to the technology and 
> the mobility 
> service. 
> 
> Dick 
> 
> -----Original Message----- 
> From: Steve Gilbert [ mailto:gilbert@rsch.comm.mot.com
<mailto:gilbert@rsch.comm.mot.com> ] 
> Sent: 18 January 2002 16:21 
> To: nsis@ietf.org 
> Subject: [NSIS] Support needed for Throughput Adaptive QoS in wireless 
> 
> 
> 
> 
> I tend to agree with the need which Herman identifies (below) 
> for throughput 
> adaptive capabilities in a wireless QoS system. 
> 
> The cellular wireless QoS problem is very different than that 
> of wired QoS 
> because of the need to handle the case of a user with a QoS 
> "guarantee" 
> handing 
> off into a different cell.  In the worst case, the cell which 
> it is entering 
> may 
> have its resources fully allocated to existing users. 
> Dropping the session 
> of 
> the user being handed off is not a good idea. This points out 
> the need for 
> some 
> rational way to accommodate such calls. The approach taken in 
> some wireless 
> voice systems is to reserve resources for use only by 
> sessions which are 
> handing 
> off into the cell. This may suffice if the resource needs of 
> the hand off 
> session are predictable. However, in a system in which arbitrary 
> applications 
> can utilize a wide range of throughput values, reserving 
> enough capacity to 
> handle the range of throughputs which could potentially be needed by a 
> single 
> flow may not be practical. 
> 
> What is needed is the use of throughput adaptive applications and the 
> ability 
> for a traffic flow to express its QoS preferences with regard to the 
> throughput 
> values which it may be allocated. Upon handing off into the 
> new cell, the 
> QoS 
> preferences of the handoff traffic flow and of the existing 
> traffic flows in 
> that cell would be considered and resources reallocated to 
> best meet their 
> preferences. Some of the existing traffic flows may have 
> their throughput 
> allocations reduced in order to free up resources to be 
> allocated to the 
> handoff 
> traffic flow. 
> 
> The QoS signaling needs of this approach include the ability 
> of the system 
> to 
> notify traffic flows of their new allocations, and the 
> ability for a new 
> traffic 
> flow requesting "admission" to express its QoS preferences, 
> possibly in 
> terms of 
> a list of throughput values and the benefit it receives from each. A 
> non-adaptive real-time application would indicate a single 
> throughput value 
> which it desires rather than a list of throughput values. 
> 
> One could argue that this provides no throughput "guarantee" 
> and changes 
> what it 
> means to have a QoS request "admitted". This is true. But in 
> wireless, it is 
> difficult and sometimes impractical to provide the same QoS 
> guarantees that 
> could be provided in a wireline system which doesn't have to deal with 
> handoff. In a wireless system, there is the possibility that 
> the user will 
> drive 
> into a tunnel or take the elevator to a sub-basement of a 
> building where the 
> wireless signal is lost. Radio coverage and QoS can not be 
> guaranteed under 
> all 
> possible situations.  Wireless channel resources are often 
> more scarce or 
> expensive than those of a wired channel. This generally results in the 
> motivation to utilize them more efficiently. What is more 
> realistic than 
> trying 
> to provide wireless QoS identical to that of wire-line is to 
> come up with a 
> useful approach for "QoS management" and "resource 
> allocation" which can be 
> applied in a wireless system. 
> 
> If efficient utilization of the resources by QoS flows is not a major 
> concern, 
> the QoS of admitted users could be increased (or at least 
> made less prone to 
> reductions) through over-provisioning or preventing admission 
> of new calls 
> even 
> when the level of congestion is still low. The resources not 
> guaranteed to 
> QoS 
> traffic flows could be used by best effort traffic. Systems 
> with significant 
> best effort traffic would be able to increase the overall 
> utilization of the 
> channel without negatively effecting QoS traffic flows. 
> 
> Steve 
> 
> 
> 
> > Date: Thu, 17 Jan 2002 19:49:13 +0000 
> > To: "Georgios Karagiannis (ELN)" 
> <Georgios.Karagiannis@eln.ericsson.se>, 
> >    "'Loughney John (NRC/Helsinki)'" <john.loughney@nokia.com>, 
> >    "'ext Kappler Cornelia'" <Cornelia.Kappler@icn.siemens.de> 
> > From: Hermann De Meer <h.demeer@ee.ucl.ac.uk> 
> > Cc: <nsis@ietf.org> 
> > Subject: RE: [NSIS] Two kinds of requirements 
> > 
> > Hi Georgios and all 
> > 
> > At 14:09 17/01/2002 +0100, Georgios Karagiannis (ELN) wrote: 
> > >Hi John and Cornelia 
> > > 
> > >I think that one of the requirements that should be included 
> > >in the NSIS WG requirements document is that the NSIS protocol 
> > >should be modular. Modular in the context of having 
> > >a toolkit from which one can choose the applicable tools 
> > >in order to manage QoS in a particular networking environment. 
> > 
> > I believe you are raising a very important issue with the 
> emphasis on 
> > modularity 
> > of QoS architectures/signalling. 
> > 
> > But one can generalize that: it's all about flexibility, 
> > namely flexibility of signalling/control/provisioning vs. 
> flexibility of 
> > applications/users. 
> > 
> > Flexibility does not necessarily mean complexity, often on 
> the contrary: 
> > one side being flexible makes the life for the other side 
> easier (think of 
> 
> > airline ticket pricing: 
> > the price for the *same seat* can vary in an order of 
> magnitude simply 
> > depending on how flexible you are!) 
> > 
> > QoS signalling is about indicating of how "inflexible" you 
> are from that 
> > perspective. 
> > But looking at IntServ (RSVP) or DiffServ,  an 
> interpretation of these 
> signals 
> > have traditionally been seen rather statically: 
> > 
> > - a "one-size-fits-all"  "end-to-end" implementation of the 
> mechanisms 
> > - a "take-it-or-leave-it" approach: statically defined QoS classes. 
> > 
> > this makes QoS provisioning cumbersome, complex, expensive 
> (unnecessarily) 
> > (and it may be a good deal the reason for the 
> "failure/insufficiency" of 
> > current QoS solutions/ 
> > signalling techniques). 
> > 
> > Remember, the success of IP networking has to a larger 
> extend been due to 
> > the fact of 
> > relying on flexibility and cooperation, for example, for congestion 
> handling. 
> > (or "exception" handling, if you want, by TCP-similar schemes) 
> > 
> > in <draft-demeer-nsis-analyis-00.txt> we therefore make a 
> point to extend 
> > QoS signalling for: 
> > 
> > 1) explicitly dealing with such "QoS exceptions" (there is also an 
> economic 
> > argument for this) 
> >      that is, not only signaling QoS preferences from 
> applications to the 
> > network, but also 
> >      QoS exceptions back from networks to applications or to between 
> networks, 
> >      and an expected cooperative adaptation. 
> > 
> > 2) allowing for flexible interpretations in different 
> domains (core, 
> > access, mobile, wireless, 
> >       administrative conditions, ....) 
> > 
> > 
> > The "trick" may be to modify signalling (including RSVP) 
> such that most 
> > flexibility/cooperation 
> > can be re-gained by assuring a minimum support of inflexibility 
> > (intentionally not using the 
> > the term QoS guarantee here). 
> > 
> > 
> > --Hermann 
> > 
> ... 
> 
> _______________________________________________ 
> nsis mailing list 
> nsis@ietf.org 
> https://www1.ietf.org/mailman/listinfo/nsis
<https://www1.ietf.org/mailman/listinfo/nsis>  
> 
> _______________________________________________ 
> nsis mailing list 
> nsis@ietf.org 
> https://www1.ietf.org/mailman/listinfo/nsis
<https://www1.ietf.org/mailman/listinfo/nsis>  
> 


------_=_NextPart_001_01C1A28C.7108FC60
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">
<TITLE>RE: [NSIS] Support needed for Throughput Adaptive QoS in wireless</TITLE>

<META content="MSHTML 5.00.3315.2869" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT color=#0000ff face="Comic Sans MS"><SPAN 
class=485355914-21012002>Yaron:</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face="Comic Sans MS"><SPAN 
class=485355914-21012002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face="Comic Sans MS"><SPAN 
class=485355914-21012002>&nbsp; The difference with handover in mobile networks 
is a matter of time constraints. Handovers</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face="Comic Sans MS"><SPAN class=485355914-21012002>can 
happen very frequently, and often happen during an active session. For some 
applications,</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face="Comic Sans MS"><SPAN 
class=485355914-21012002>such as best effort applications, re-negotiation of QoS 
using a high layer protocol may be viable,</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face="Comic Sans MS"><SPAN 
class=485355914-21012002>however, for many other services, most notably voice 
and video, there simply is not enough time </SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face="Comic Sans MS"><SPAN 
class=485355914-21012002>before the service is disrupted.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face="Comic Sans MS"><SPAN 
class=485355914-21012002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face="Comic Sans MS"><SPAN 
class=485355914-21012002>&nbsp;&nbsp; The "re-negotiation" during handoff being 
referred to is not, I believe, the same as the negotiation</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face="Comic Sans MS"><SPAN 
class=485355914-21012002>during session set-up. If it were, then yes, it should 
happen at a higher layer, and as I have alluded to</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face="Comic Sans MS"><SPAN 
class=485355914-21012002>above, not likely to help the situation much. I would 
go so far as to say that the situation during a</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face="Comic Sans MS"><SPAN 
class=485355914-21012002>handover is not so much "re-negotiation" as 
"notification" of a change in QoS. However, this gets</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face="Comic Sans MS"><SPAN 
class=485355914-21012002>deep into the solution space, and unless there is a 
need for use to explore it in order to understand</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face="Comic Sans MS"><SPAN class=485355914-21012002>the 
requirement, we should defer the discussion.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face="Comic Sans MS"><SPAN 
class=485355914-21012002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face="Comic Sans MS"><SPAN 
class=485355914-21012002>Gary</SPAN></FONT></DIV>
<BLOCKQUOTE dir=ltr 
style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">
  <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Yaron Kahana 
  [mailto:ykahana@comgates.co.il]<BR><B>Sent:</B> January 19, 2002 
  14:27<BR><B>To:</B> Kenward, Gary [WDLN2:AN10:EXCH]; 'dick.rr.knight@bt.com'; 
  gilbert@rsch.comm.mot.com<BR><B>Cc:</B> nsis@ietf.org<BR><B>Subject:</B> RE: 
  [NSIS] Support needed for Throughput Adaptive QoS in 
  wireless<BR><BR></DIV></FONT>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=439490919-19012002>Hi 
  all,</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=439490919-19012002></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=439490919-19012002>I 
  think that the describe situation is:</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=439490919-19012002>1) 
  NOT unique to the mobile case.</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=439490919-19012002>2) 
  Should be&nbsp;handled by a "higher hierarchy".</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=439490919-19012002></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=439490919-19012002>I 
  think that the described example is the derivative of unpredictable over 
  loading of resources, and&nbsp;is&nbsp;rather common (for example through 
  Erlang distribution?). The mobile case, with its relative high dynamic users, 
  can still perform the correct network planning work to handle such cases. The 
  NGN, whereas the users will have their services linked to their "entity" and 
  not to their landline, will have to deal with it as well.</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=439490919-19012002></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=439490919-19012002>I 
  also think that the solution of over loading should be managed by a local 
  "higher hierarchy" and not by the End-to-End reservation. This local service 
  controller should be aware of the sessions, users, resources and commitments. 
  Hence could decide a "re-negotiation" or a drop. Think about the case that 
  there is an emergency call in the cell (911) and it is being dropped or 
  degraded?</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=439490919-19012002></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=439490919-19012002>I'm 
  not sure this is within NSIS scope, but this service controller (softswitch?) 
  should be aware of the resources&nbsp;reservation and should manage the 
  allocation of resources and admission control (see TIPHON 
  DTS02009v044.doc).</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=439490919-19012002></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=439490919-19012002>Best 
  Regards,</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=439490919-19012002></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=439490919-19012002>Yaron Kahana</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=439490919-19012002>COGITO Project Manager</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=439490919-19012002>COMGATES</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=439490919-19012002><A 
  href="http://www.comgates.com">www.comgates.com</A></SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=439490919-19012002></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=439490919-19012002></SPAN></FONT>&nbsp;</DIV>
  <BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
    <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
    size=2>-----Original Message-----<BR><B>From:</B> Gary Kenward 
    [mailto:gkenward@nortelnetworks.com]<BR><B>Sent:</B> Friday, January 18, 
    2002 7:31 PM<BR><B>To:</B> 'dick.rr.knight@bt.com'; 
    gilbert@rsch.comm.mot.com; nsis@ietf.org<BR><B>Subject:</B> RE: [NSIS] 
    Support needed for Throughput Adaptive QoS in wireless<BR><BR></FONT></DIV>
    <P><FONT size=2>Steve:</FONT> </P>
    <P><FONT size=2>&nbsp; I don't believe that Dick is proposing that NSIS 
    accomodate </FONT><BR><FONT size=2>rate adaption, I believe that the issue 
    is QoS re-negotiation </FONT><BR><FONT size=2>to allow better handoff 
    performance.</FONT> <BR><FONT size=2>&nbsp;</FONT> <BR><FONT size=2>&nbsp; 
    The situation is simply that if the admission control used</FONT> <BR><FONT 
    size=2>during a handoff is "all or nothing" then the likelihood the</FONT> 
    <BR><FONT size=2>flows of the mobile user will be dropped when a handoff 
    occurs is </FONT><BR><FONT size=2>much higher. "Re-negotiation" of QoS 
    allows the network to reduce</FONT> <BR><FONT size=2>the resource demands to 
    the point that the new access router </FONT><BR><FONT size=2>can handle the 
    flows, at least to some degree.</FONT> </P>
    <P><FONT size=2>&nbsp; Re-negotiation can mean many different solution 
    scenarios.</FONT> <BR><FONT size=2>At the extremes, the solution could be an 
    NSIS negotiation </FONT><BR><FONT size=2>protocol between mobile and access 
    network; a "minimum" QoS </FONT><BR><FONT size=2>that the network that is 
    allowed as a fallback to allow the </FONT><BR><FONT size=2>handoff to occur. 
    Note that in either case, the result may</FONT> <BR><FONT size=2>mean 
    dropping of specific flows that cannot be support (e.g.</FONT> <BR><FONT 
    size=2>the video portion of a multimedia session).</FONT> </P>
    <P><FONT size=2>The second scenario does not necessarly require interaction 
    </FONT><BR><FONT size=2>with the mobile or other networks and thus 
    may</FONT> <BR><FONT size=2>not impact NSIS.&nbsp; However, it might be a 
    good thing for the</FONT> <BR><FONT size=2>network to tell the mobile that 
    the QoS had been degraded,</FONT> <BR><FONT size=2>thus allowing the mobile 
    application to "adapt". NSIS does not</FONT> <BR><FONT size=2>need to 
    participate in the adaption, it would simply provide</FONT> <BR><FONT 
    size=2>the information on the new QoS.</FONT> </P>
    <P><FONT size=2>I think the requirement here is for the NSIS wg to 
    consider</FONT> <BR><FONT size=2>all the options.</FONT> </P>
    <P><FONT size=2>Gary</FONT> </P><BR>
    <P><FONT size=2>&gt; -----Original Message-----</FONT> <BR><FONT size=2>&gt; 
    From: dick.rr.knight@bt.com [<A 
    href="mailto:dick.rr.knight@bt.com">mailto:dick.rr.knight@bt.com</A>]</FONT> 
    <BR><FONT size=2>&gt; Sent: January 18, 2002 11:51</FONT> <BR><FONT 
    size=2>&gt; To: gilbert@rsch.comm.mot.com; nsis@ietf.org</FONT> <BR><FONT 
    size=2>&gt; Subject: RE: [NSIS] Support needed for Throughput Adaptive QoS 
    in</FONT> <BR><FONT size=2>&gt; wireless</FONT> <BR><FONT size=2>&gt; 
    </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT 
    size=2>&gt; There are some important points in this email. Probably 
    </FONT><BR><FONT size=2>&gt; obvious for people</FONT> <BR><FONT size=2>&gt; 
    with wireless backgrounds, but a bit more of a surprise for wired</FONT> 
    <BR><FONT size=2>&gt; backgrounds.</FONT> <BR><FONT size=2>&gt; 
    </FONT><BR><FONT size=2>&gt; I personally don't see NSIS as trying to solve 
    the rate </FONT><BR><FONT size=2>&gt; adaptation needs of</FONT> <BR><FONT 
    size=2>&gt; the wireless access network. I can see that it is very much 
    </FONT><BR><FONT size=2>&gt; needed, but it</FONT> <BR><FONT size=2>&gt; is 
    rather more specialised than a generic signalling protocol for QoS</FONT> 
    <BR><FONT size=2>&gt; requests. This looks like a charter debate.</FONT> 
    <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; The wireless access 
    network definitely needs some QoS </FONT><BR><FONT size=2>&gt; signalling 
    support,</FONT> <BR><FONT size=2>&gt; but as you have shown, it is specific 
    to the technology and </FONT><BR><FONT size=2>&gt; the mobility</FONT> 
    <BR><FONT size=2>&gt; service.</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT 
    size=2>&gt; Dick</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; 
    -----Original Message-----</FONT> <BR><FONT size=2>&gt; From: Steve Gilbert 
    [<A 
    href="mailto:gilbert@rsch.comm.mot.com">mailto:gilbert@rsch.comm.mot.com</A>]</FONT> 
    <BR><FONT size=2>&gt; Sent: 18 January 2002 16:21</FONT> <BR><FONT 
    size=2>&gt; To: nsis@ietf.org</FONT> <BR><FONT size=2>&gt; Subject: [NSIS] 
    Support needed for Throughput Adaptive QoS in wireless</FONT> <BR><FONT 
    size=2>&gt; </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; 
    </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; I tend to agree 
    with the need which Herman identifies (below) </FONT><BR><FONT size=2>&gt; 
    for throughput</FONT> <BR><FONT size=2>&gt; adaptive capabilities in a 
    wireless QoS system.</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT 
    size=2>&gt; The cellular wireless QoS problem is very different than that 
    </FONT><BR><FONT size=2>&gt; of wired QoS</FONT> <BR><FONT size=2>&gt; 
    because of the need to handle the case of a user with a QoS </FONT><BR><FONT 
    size=2>&gt; "guarantee"</FONT> <BR><FONT size=2>&gt; handing</FONT> 
    <BR><FONT size=2>&gt; off into a different cell.&nbsp; In the worst case, 
    the cell which </FONT><BR><FONT size=2>&gt; it is entering</FONT> <BR><FONT 
    size=2>&gt; may</FONT> <BR><FONT size=2>&gt; have its resources fully 
    allocated to existing users. </FONT><BR><FONT size=2>&gt; Dropping the 
    session</FONT> <BR><FONT size=2>&gt; of</FONT> <BR><FONT size=2>&gt; the 
    user being handed off is not a good idea. This points out </FONT><BR><FONT 
    size=2>&gt; the need for</FONT> <BR><FONT size=2>&gt; some</FONT> <BR><FONT 
    size=2>&gt; rational way to accommodate such calls. The approach taken in 
    </FONT><BR><FONT size=2>&gt; some wireless</FONT> <BR><FONT size=2>&gt; 
    voice systems is to reserve resources for use only by </FONT><BR><FONT 
    size=2>&gt; sessions which are</FONT> <BR><FONT size=2>&gt; handing</FONT> 
    <BR><FONT size=2>&gt; off into the cell. This may suffice if the resource 
    needs of </FONT><BR><FONT size=2>&gt; the hand off</FONT> <BR><FONT 
    size=2>&gt; session are predictable. However, in a system in which 
    arbitrary</FONT> <BR><FONT size=2>&gt; applications</FONT> <BR><FONT 
    size=2>&gt; can utilize a wide range of throughput values, reserving 
    </FONT><BR><FONT size=2>&gt; enough capacity to</FONT> <BR><FONT size=2>&gt; 
    handle the range of throughputs which could potentially be needed by 
    a</FONT> <BR><FONT size=2>&gt; single</FONT> <BR><FONT size=2>&gt; flow may 
    not be practical.</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; 
    What is needed is the use of throughput adaptive applications and the</FONT> 
    <BR><FONT size=2>&gt; ability</FONT> <BR><FONT size=2>&gt; for a traffic 
    flow to express its QoS preferences with regard to the</FONT> <BR><FONT 
    size=2>&gt; throughput</FONT> <BR><FONT size=2>&gt; values which it may be 
    allocated. Upon handing off into the </FONT><BR><FONT size=2>&gt; new cell, 
    the</FONT> <BR><FONT size=2>&gt; QoS</FONT> <BR><FONT size=2>&gt; 
    preferences of the handoff traffic flow and of the existing </FONT><BR><FONT 
    size=2>&gt; traffic flows in</FONT> <BR><FONT size=2>&gt; that cell would be 
    considered and resources reallocated to </FONT><BR><FONT size=2>&gt; best 
    meet their</FONT> <BR><FONT size=2>&gt; preferences. Some of the existing 
    traffic flows may have </FONT><BR><FONT size=2>&gt; their throughput</FONT> 
    <BR><FONT size=2>&gt; allocations reduced in order to free up resources to 
    be </FONT><BR><FONT size=2>&gt; allocated to the</FONT> <BR><FONT 
    size=2>&gt; handoff</FONT> <BR><FONT size=2>&gt; traffic flow.</FONT> 
    <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; The QoS signaling needs 
    of this approach include the ability </FONT><BR><FONT size=2>&gt; of the 
    system</FONT> <BR><FONT size=2>&gt; to</FONT> <BR><FONT size=2>&gt; notify 
    traffic flows of their new allocations, and the </FONT><BR><FONT size=2>&gt; 
    ability for a new</FONT> <BR><FONT size=2>&gt; traffic</FONT> <BR><FONT 
    size=2>&gt; flow requesting "admission" to express its QoS preferences, 
    </FONT><BR><FONT size=2>&gt; possibly in</FONT> <BR><FONT size=2>&gt; terms 
    of</FONT> <BR><FONT size=2>&gt; a list of throughput values and the benefit 
    it receives from each. A</FONT> <BR><FONT size=2>&gt; non-adaptive real-time 
    application would indicate a single </FONT><BR><FONT size=2>&gt; throughput 
    value</FONT> <BR><FONT size=2>&gt; which it desires rather than a list of 
    throughput values.</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; 
    One could argue that this provides no throughput "guarantee" 
    </FONT><BR><FONT size=2>&gt; and changes</FONT> <BR><FONT size=2>&gt; what 
    it</FONT> <BR><FONT size=2>&gt; means to have a QoS request "admitted". This 
    is true. But in </FONT><BR><FONT size=2>&gt; wireless, it is</FONT> 
    <BR><FONT size=2>&gt; difficult and sometimes impractical to provide the 
    same QoS </FONT><BR><FONT size=2>&gt; guarantees that</FONT> <BR><FONT 
    size=2>&gt; could be provided in a wireline system which doesn't have to 
    deal with</FONT> <BR><FONT size=2>&gt; handoff. In a wireless system, there 
    is the possibility that </FONT><BR><FONT size=2>&gt; the user will</FONT> 
    <BR><FONT size=2>&gt; drive</FONT> <BR><FONT size=2>&gt; into a tunnel or 
    take the elevator to a sub-basement of a </FONT><BR><FONT size=2>&gt; 
    building where the</FONT> <BR><FONT size=2>&gt; wireless signal is lost. 
    Radio coverage and QoS can not be </FONT><BR><FONT size=2>&gt; guaranteed 
    under</FONT> <BR><FONT size=2>&gt; all</FONT> <BR><FONT size=2>&gt; possible 
    situations.&nbsp; Wireless channel resources are often </FONT><BR><FONT 
    size=2>&gt; more scarce or</FONT> <BR><FONT size=2>&gt; expensive than those 
    of a wired channel. This generally results in the</FONT> <BR><FONT 
    size=2>&gt; motivation to utilize them more efficiently. What is more 
    </FONT><BR><FONT size=2>&gt; realistic than</FONT> <BR><FONT size=2>&gt; 
    trying</FONT> <BR><FONT size=2>&gt; to provide wireless QoS identical to 
    that of wire-line is to </FONT><BR><FONT size=2>&gt; come up with a</FONT> 
    <BR><FONT size=2>&gt; useful approach for "QoS management" and "resource 
    </FONT><BR><FONT size=2>&gt; allocation" which can be</FONT> <BR><FONT 
    size=2>&gt; applied in a wireless system.</FONT> <BR><FONT size=2>&gt; 
    </FONT><BR><FONT size=2>&gt; If efficient utilization of the resources by 
    QoS flows is not a major</FONT> <BR><FONT size=2>&gt; concern,</FONT> 
    <BR><FONT size=2>&gt; the QoS of admitted users could be increased (or at 
    least </FONT><BR><FONT size=2>&gt; made less prone to</FONT> <BR><FONT 
    size=2>&gt; reductions) through over-provisioning or preventing admission 
    </FONT><BR><FONT size=2>&gt; of new calls</FONT> <BR><FONT size=2>&gt; 
    even</FONT> <BR><FONT size=2>&gt; when the level of congestion is still low. 
    The resources not </FONT><BR><FONT size=2>&gt; guaranteed to</FONT> 
    <BR><FONT size=2>&gt; QoS</FONT> <BR><FONT size=2>&gt; traffic flows could 
    be used by best effort traffic. Systems </FONT><BR><FONT size=2>&gt; with 
    significant</FONT> <BR><FONT size=2>&gt; best effort traffic would be able 
    to increase the overall </FONT><BR><FONT size=2>&gt; utilization of 
    the</FONT> <BR><FONT size=2>&gt; channel without negatively effecting QoS 
    traffic flows.</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; 
    Steve</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; 
    </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; &gt; Date: Thu, 17 
    Jan 2002 19:49:13 +0000</FONT> <BR><FONT size=2>&gt; &gt; To: "Georgios 
    Karagiannis (ELN)" </FONT><BR><FONT size=2>&gt; 
    &lt;Georgios.Karagiannis@eln.ericsson.se&gt;,</FONT> <BR><FONT size=2>&gt; 
    &gt;&nbsp;&nbsp;&nbsp; "'Loughney John (NRC/Helsinki)'" 
    &lt;john.loughney@nokia.com&gt;,</FONT> <BR><FONT size=2>&gt; 
    &gt;&nbsp;&nbsp;&nbsp; "'ext Kappler Cornelia'" 
    &lt;Cornelia.Kappler@icn.siemens.de&gt;</FONT> <BR><FONT size=2>&gt; &gt; 
    From: Hermann De Meer &lt;h.demeer@ee.ucl.ac.uk&gt;</FONT> <BR><FONT 
    size=2>&gt; &gt; Cc: &lt;nsis@ietf.org&gt;</FONT> <BR><FONT size=2>&gt; &gt; 
    Subject: RE: [NSIS] Two kinds of requirements</FONT> <BR><FONT size=2>&gt; 
    &gt; </FONT><BR><FONT size=2>&gt; &gt; Hi Georgios and all</FONT> <BR><FONT 
    size=2>&gt; &gt; </FONT><BR><FONT size=2>&gt; &gt; At 14:09 17/01/2002 
    +0100, Georgios Karagiannis (ELN) wrote:</FONT> <BR><FONT size=2>&gt; &gt; 
    &gt;Hi John and Cornelia</FONT> <BR><FONT size=2>&gt; &gt; &gt;</FONT> 
    <BR><FONT size=2>&gt; &gt; &gt;I think that one of the requirements that 
    should be included</FONT> <BR><FONT size=2>&gt; &gt; &gt;in the NSIS WG 
    requirements document is that the NSIS protocol</FONT> <BR><FONT size=2>&gt; 
    &gt; &gt;should be modular. Modular in the context of having</FONT> 
    <BR><FONT size=2>&gt; &gt; &gt;a toolkit from which one can choose the 
    applicable tools</FONT> <BR><FONT size=2>&gt; &gt; &gt;in order to manage 
    QoS in a particular networking environment.</FONT> <BR><FONT size=2>&gt; 
    &gt; </FONT><BR><FONT size=2>&gt; &gt; I believe you are raising a very 
    important issue with the </FONT><BR><FONT size=2>&gt; emphasis on 
    </FONT><BR><FONT size=2>&gt; &gt; modularity</FONT> <BR><FONT size=2>&gt; 
    &gt; of QoS architectures/signalling.</FONT> <BR><FONT size=2>&gt; &gt; 
    </FONT><BR><FONT size=2>&gt; &gt; But one can generalize that: it's all 
    about flexibility,</FONT> <BR><FONT size=2>&gt; &gt; namely flexibility of 
    signalling/control/provisioning vs. </FONT><BR><FONT size=2>&gt; flexibility 
    of </FONT><BR><FONT size=2>&gt; &gt; applications/users.</FONT> <BR><FONT 
    size=2>&gt; &gt; </FONT><BR><FONT size=2>&gt; &gt; Flexibility does not 
    necessarily mean complexity, often on </FONT><BR><FONT size=2>&gt; the 
    contrary:</FONT> <BR><FONT size=2>&gt; &gt; one side being flexible makes 
    the life for the other side </FONT><BR><FONT size=2>&gt; easier (think 
    of</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; &gt; airline 
    ticket pricing:</FONT> <BR><FONT size=2>&gt; &gt; the price for the *same 
    seat* can vary in an order of </FONT><BR><FONT size=2>&gt; magnitude 
    simply</FONT> <BR><FONT size=2>&gt; &gt; depending on how flexible you 
    are!)</FONT> <BR><FONT size=2>&gt; &gt; </FONT><BR><FONT size=2>&gt; &gt; 
    QoS signalling is about indicating of how "inflexible" you </FONT><BR><FONT 
    size=2>&gt; are from that </FONT><BR><FONT size=2>&gt; &gt; 
    perspective.</FONT> <BR><FONT size=2>&gt; &gt; But looking at IntServ (RSVP) 
    or DiffServ,&nbsp; an </FONT><BR><FONT size=2>&gt; interpretation of 
    these</FONT> <BR><FONT size=2>&gt; signals</FONT> <BR><FONT size=2>&gt; &gt; 
    have traditionally been seen rather statically:</FONT> <BR><FONT size=2>&gt; 
    &gt; </FONT><BR><FONT size=2>&gt; &gt; - a "one-size-fits-all"&nbsp; 
    "end-to-end" implementation of the </FONT><BR><FONT size=2>&gt; 
    mechanisms</FONT> <BR><FONT size=2>&gt; &gt; - a "take-it-or-leave-it" 
    approach: statically defined QoS classes.</FONT> <BR><FONT size=2>&gt; &gt; 
    </FONT><BR><FONT size=2>&gt; &gt; this makes QoS provisioning cumbersome, 
    complex, expensive </FONT><BR><FONT size=2>&gt; (unnecessarily)</FONT> 
    <BR><FONT size=2>&gt; &gt; (and it may be a good deal the reason for the 
    </FONT><BR><FONT size=2>&gt; "failure/insufficiency" of </FONT><BR><FONT 
    size=2>&gt; &gt; current QoS solutions/</FONT> <BR><FONT size=2>&gt; &gt; 
    signalling techniques).</FONT> <BR><FONT size=2>&gt; &gt; </FONT><BR><FONT 
    size=2>&gt; &gt; Remember, the success of IP networking has to a larger 
    </FONT><BR><FONT size=2>&gt; extend been due to </FONT><BR><FONT size=2>&gt; 
    &gt; the fact of</FONT> <BR><FONT size=2>&gt; &gt; relying on flexibility 
    and cooperation, for example, for congestion</FONT> <BR><FONT size=2>&gt; 
    handling.</FONT> <BR><FONT size=2>&gt; &gt; (or "exception" handling, if you 
    want, by TCP-similar schemes)</FONT> <BR><FONT size=2>&gt; &gt; 
    </FONT><BR><FONT size=2>&gt; &gt; in 
    &lt;draft-demeer-nsis-analyis-00.txt&gt; we therefore make a 
    </FONT><BR><FONT size=2>&gt; point to extend </FONT><BR><FONT size=2>&gt; 
    &gt; QoS signalling for:</FONT> <BR><FONT size=2>&gt; &gt; </FONT><BR><FONT 
    size=2>&gt; &gt; 1) explicitly dealing with such "QoS exceptions" (there is 
    also an</FONT> <BR><FONT size=2>&gt; economic </FONT><BR><FONT size=2>&gt; 
    &gt; argument for this)</FONT> <BR><FONT size=2>&gt; 
    &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; that is, not only signaling QoS 
    preferences from </FONT><BR><FONT size=2>&gt; applications to the 
    </FONT><BR><FONT size=2>&gt; &gt; network, but also</FONT> <BR><FONT 
    size=2>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; QoS exceptions back from 
    networks to applications or to between</FONT> <BR><FONT size=2>&gt; 
    networks,</FONT> <BR><FONT size=2>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    and an expected cooperative adaptation.</FONT> <BR><FONT size=2>&gt; &gt; 
    </FONT><BR><FONT size=2>&gt; &gt; 2) allowing for flexible interpretations 
    in different </FONT><BR><FONT size=2>&gt; domains (core, </FONT><BR><FONT 
    size=2>&gt; &gt; access, mobile, wireless,</FONT> <BR><FONT size=2>&gt; 
    &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; administrative conditions, 
    ....)</FONT> <BR><FONT size=2>&gt; &gt; </FONT><BR><FONT size=2>&gt; &gt; 
    </FONT><BR><FONT size=2>&gt; &gt; The "trick" may be to modify signalling 
    (including RSVP) </FONT><BR><FONT size=2>&gt; such that most 
    </FONT><BR><FONT size=2>&gt; &gt; flexibility/cooperation</FONT> <BR><FONT 
    size=2>&gt; &gt; can be re-gained by assuring a minimum support of 
    inflexibility </FONT><BR><FONT size=2>&gt; &gt; (intentionally not using 
    the</FONT> <BR><FONT size=2>&gt; &gt; the term QoS guarantee here).</FONT> 
    <BR><FONT size=2>&gt; &gt; </FONT><BR><FONT size=2>&gt; &gt; 
    </FONT><BR><FONT size=2>&gt; &gt; --Hermann</FONT> <BR><FONT size=2>&gt; 
    &gt; </FONT><BR><FONT size=2>&gt; ...</FONT> <BR><FONT size=2>&gt; 
    </FONT><BR><FONT size=2>&gt; 
    _______________________________________________</FONT> <BR><FONT size=2>&gt; 
    nsis mailing list</FONT> <BR><FONT size=2>&gt; nsis@ietf.org</FONT> 
    <BR><FONT size=2>&gt; <A href="https://www1.ietf.org/mailman/listinfo/nsis" 
    target=_blank>https://www1.ietf.org/mailman/listinfo/nsis</A></FONT> 
    <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; 
    _______________________________________________</FONT> <BR><FONT size=2>&gt; 
    nsis mailing list</FONT> <BR><FONT size=2>&gt; nsis@ietf.org</FONT> 
    <BR><FONT size=2>&gt; <A href="https://www1.ietf.org/mailman/listinfo/nsis" 
    target=_blank>https://www1.ietf.org/mailman/listinfo/nsis</A></FONT> 
    <BR><FONT size=2>&gt; </FONT></P></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C1A28C.7108FC60--

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



From daemon@optimus.ietf.org  Mon Jan 21 10:47: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 KAA13075
	for <nsis-archive@odin.ietf.org>; Mon, 21 Jan 2002 10:47:09 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id KAA13459
	for nsis-archive@odin.ietf.org; Mon, 21 Jan 2002 10:47: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 KAA13145;
	Mon, 21 Jan 2002 10:37: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 KAA13114
	for <nsis@optimus.ietf.org>; Mon, 21 Jan 2002 10:37:08 -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 KAA12748
	for <nsis@ietf.org>; Mon, 21 Jan 2002 10:37:04 -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 g0LFdDT00455;
	Mon, 21 Jan 2002 09:39:13 -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 g0LFaZY16109;
	Mon, 21 Jan 2002 09:36:35 -0600 (CST)
Received: by TRIMAIL2.ad.tri.sbc.com with Internet Mail Service (5.5.2653.19)
	id <ZND32SPZ>; Mon, 21 Jan 2002 09:37:01 -0600
Message-ID: <905A1C4ABF353F4C8CC16FA9F53DD0D6322427@TRIMAIL2.ad.tri.sbc.com>
From: "Chen, Weijing" <wchen@tri.sbc.com>
To: "'Geib, Ruediger'" <Ruediger.Geib@t-systems.com>, ykahana@comgates.co.il
Cc: nsis@ietf.org
Subject: RE: [NSIS] Support needed for Throughput Adaptive QoS in wireless
Date: Mon, 21 Jan 2002 09:36:57 -0600
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 KAA13115
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

[wj] I agreed with Rüdiger's comment. It is up to NP&E (Network Planning and
Engineering) to proper engineering the network for most frequent situations.
If network can not handle the request, it ought to return back a busy
signal. That is the job of NP&E engineers, it is their butter and bread. The
preemption service is difficult and involving a lot of regulatory and legal
issues. Don't go there.


--
Weijing Chen
SBC Technology Resources
9505 Arboretum Blvd.
Austin, TX 78759
512 372 5710
wchen@tri.sbc.com


 -----Original Message-----
From: 	Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] 
Sent:	Monday, January 21, 2002 7:57 AM
To:	ykahana@comgates.co.il; Geib, Ruediger
Cc:	nsis@ietf.org
Subject:	RE: [NSIS] Support needed for Throughput Adaptive QoS in
wireless

Dear Yaron,

Solutions may be different service definitions for the doctor and the
standard customer, preemption or a very high service availability. I'm not
sure whether a "911" call preempts busy lines in Germany. But to the best of
my knowledge, services and networks which are used to support emergency
calls must be very reliabile, even if preemption is added as a secondary
measure to ensure success. 

I however don't favour preemption as a general tool to differentiate
services. It requires additional signalling, network planning and network
monitoring. Service descriptions get more complex: a preemption event means
a reduced service availability. But to what degree can you control
availability decrease caused by preemption?

Regards, Rüdiger 

Y> The same applies for the 2nd example - I'm not 
Y> sure, but I think the simple solution of "First
Y> Come first Served" should not apply in a service
Y> oriented world. If I am a tycoon that paid a lot
Y> to the telephone company, or if I'm a doctor 
Y> conducting en emergency phonecall, I would like
Y> the service provider to differentiate my sessions
Y> from the others (doctors :-)). This must be done
Y> by an entity that understand who is the user 
Y> behind the application.

R> Say you support re-negotiation. Your cell 
R> supports 10 QoS reservations and the ten 
R> of them are used. Number 11 wants to enter 
R> and triggers a re-negotiation. Do you 
R> re-negotiate all of the ten existing 
R> reservations? Only one? If so, how do you 
R> decide on the candidate in a fair way? 
  

_______________________________________________
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 Jan 21 10:50: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 KAA13209
	for <nsis-archive@odin.ietf.org>; Mon, 21 Jan 2002 10:50:19 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id KAA13624
	for nsis-archive@odin.ietf.org; Mon, 21 Jan 2002 10:50: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 KAA13594;
	Mon, 21 Jan 2002 10:49: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 KAA13561
	for <nsis@optimus.ietf.org>; Mon, 21 Jan 2002 10:49:27 -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 KAA13145
	for <nsis@ietf.org>; Mon, 21 Jan 2002 10:49:18 -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 g0LFpRT00536;
	Mon, 21 Jan 2002 09:51:27 -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 g0LFmjd16500;
	Mon, 21 Jan 2002 09:48:45 -0600 (CST)
Received: by TRIMAIL2.ad.tri.sbc.com with Internet Mail Service (5.5.2653.19)
	id <ZND32SRV>; Mon, 21 Jan 2002 09:49:11 -0600
Message-ID: <905A1C4ABF353F4C8CC16FA9F53DD0D6322428@TRIMAIL2.ad.tri.sbc.com>
From: "Chen, Weijing" <wchen@tri.sbc.com>
To: "'Gary Kenward'" <gkenward@nortelnetworks.com>,
        "Schneider, Marco"
	 <schneider@tri.sbc.com>,
        "'Roy, Radhika R, ALASO'" <rrroy@att.com>,
        "Loughney John (NRC/Helsinki)" <john.loughney@nokia.com>,
        brunner@ccrle.nec.de, Yaron Kahana <ykahana@comgates.co.il>,
        "Geib, Ruediger" <Ruediger.Geib@t-systems.com>, dick.rr.knight@bt.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements
Date: Mon, 21 Jan 2002 09:49:06 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C1A293.28603350"
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_01C1A293.28603350
Content-Type: text/plain;
	charset="iso-8859-1"

 
-----Original Message-----
From: Gary Kenward [mailto:gkenward@nortelnetworks.com]
Sent: Monday, January 21, 2002 8:53 AM
To: Schneider, Marco; 'Roy, Radhika R, ALASO'; Loughney John (NRC/Helsinki);
brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger; dick.rr.knight@bt.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements



Marco: 

  I believe I see why you characterize end-to-end QoS signalling to the 
the session layer. What seems to be missing here is a model for how 
QoS is signalled at the transport layer to set up the required transport 
(and underlying mechanisms). 
[Chen, Weijing]  Yes, that is the case.


  I don't believe you are proposing a "layering" of signalling protocols, 
one for session establishment, then one for transport, etc. So, the
question, 
becomes, how are the QoS transport mechanisms established? In the internet 
model there is only one end-to-end transport session (e.g. TCP, RTP, UDP), 
but underneath the transport is a series of inter-connected networks, each 
with potentially different characteristics. 

  This is end-to-end QoS support structure has to be set up and maintained 
in order for the end to end session QoS to be realized. The solution may be 
a single protocol that travels from host to host, such as RSVP, or it may 
be a collection of protocols that are optimized for each portion of the 
end-to-end path: e.g. host to access network, access to core network, 
core to core network, etc. 
[Chen, Weijing] I have a doubt about a single protocol solution. It is
certainly a great goal for engineer like you and me. But in reality, either
for legacy network reason, or other business reason, a single protocol from
end-to-end has never happened, and will never happened. Look at PSTN world,
they have multiple favors of SS7. But they do have a universal
host-to-access network protocol DTMF. What we need in NSIS is DTMF
equivalent protocol for data network.

  It is too early to determine which approach is best, but in either case, 
do we not need to understand the end-to-end requirements for this signalling

capability? 


Gary Kenward 

> -----Original Message----- 
> From: Schneider, Marco [ mailto:schneider@tri.sbc.com
<mailto:schneider@tri.sbc.com> ] 
> Sent: January 18, 2002 15:10 
> To: 'Roy, Radhika R, ALASO'; Kenward, Gary [WDLN2:AN10:EXCH]; Loughney 
> John (NRC/Helsinki); brunner@ccrle.nec.de; Yaron Kahana; 
> Geib, Ruediger; 
> dick.rr.knight@bt.com 
> Cc: nsis@ietf.org 
> Subject: RE: [NSIS] Two kinds of requirements 
> 
> 
> Hi Roy, 
> 
> Below is the original text from your reponse to Gary Kenward. 
> Hopefully the 
> context is clear. 
> 
> "[Roy, Radhika R, ALARC]  I would say that it is the QOS needs of the 
> application (e.g., SIP-based VoIP) that the user likes to express (as 
> opposed to "service"). Similarly, instead of network 
> services, we would say 
> network layer QOS services (e.g., RSVP, DiffServ, MPLS). We 
> would develop 
> the end-to-end (application layer) QOS signaling protocol 
> (say, NSIS QOS). 
> Now, there needs to have some kinds of standards how NSIS QOS 
> will be mapped 
> over RSVP, DiffServ, MPLS, etc." 
> 
> So by End-to-End you mean between directly between two 
> "users". This is 
> session level signaling and I don't believe the signaling 
> part is within the 
> scope of this working group. An application level QOS 
> specification may be. 
> 
> After a session level agreement on QOS, the 
> host/client/customer will need 
> to signal an actual reservation request to the network for 
> the necessary QOS 
> agreed to at the session level. This is the protocol that we 
> need to work 
> on. 
> 
> This approach is discussed in the SIP draft "SIP Extensions for Media 
> Authorization" (draft-ietf-sip-call-auth-03.txt) and the RAP draft 
> "Framework for session set-up with media authorization" 
> (draft-ietf-rap-session-auth-02.txt). 
> 
> Marco Schneider 
> 
> -----Original Message----- 
> From: Roy, Radhika R, ALASO [ mailto:rrroy@att.com <mailto:rrroy@att.com>
] 
> Sent: Friday, January 18, 2002 9:18 AM 
> To: Schneider, Marco; Gary Kenward; Loughney John (NRC/Helsinki); 
> brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger; 
> dick.rr.knight@bt.com 
> Cc: nsis@ietf.org 
> Subject: RE: [NSIS] Two kinds of requirements 
> 
> 
> Defined below [RRR] 
> 
> -----Original Message----- 
> From: Schneider, Marco [ mailto:schneider@tri.sbc.com
<mailto:schneider@tri.sbc.com> ] 
> Sent: Thursday, January 17, 2002 8:47 PM 
> To: Roy, Radhika R, ALASO; Gary Kenward; Loughney John (NRC/Helsinki); 
> brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger; 
> dick.rr.knight@bt.com 
> Cc: nsis@ietf.org 
> Subject: RE: [NSIS] Two kinds of requirements 
> 
> 
> Hi Roy, 
> 
> Can you please define what you mean by "End-to-End 
> Application Layer QOS 
> Signaling". Thanks. 
> 
> [RRR] Suppose an user is initiation a SIP call to another 
> user with audio, 
> video, and data. The use needs to express the needs of QOS 
> for audio, video, 
> and data to another user. 
> 
> [RRR] The signaling mechanism that allows to express the QOS 
> parameters of 
> audio, video, and data is termed as the "End-to-End 
> Application Layer QOS 
> Signaling." 
> 
> Marco Schneider 
> 
> _______________________________________________ 
> nsis mailing list 
> nsis@ietf.org 
> https://www1.ietf.org/mailman/listinfo/nsis
<https://www1.ietf.org/mailman/listinfo/nsis>  
> 


------_=_NextPart_001_01C1A293.28603350
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">
<TITLE>RE: [NSIS] Two kinds of requirements</TITLE>

<META content="MSHTML 5.50.4807.2300" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT face=Arial color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
size=2>-----Original Message-----<BR><B>From:</B> Gary Kenward 
[mailto:gkenward@nortelnetworks.com]<BR><B>Sent:</B> Monday, January 21, 2002 
8:53 AM<BR><B>To:</B> Schneider, Marco; 'Roy, Radhika R, ALASO'; Loughney John 
(NRC/Helsinki); brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger; 
dick.rr.knight@bt.com<BR><B>Cc:</B> nsis@ietf.org<BR><B>Subject:</B> RE: [NSIS] 
Two kinds of requirements<BR><BR></FONT></DIV>
<P><FONT size=2>Marco:</FONT> </P>
<P><FONT size=2>&nbsp; I believe I see why you characterize end-to-end QoS 
signalling to the</FONT> <BR><FONT size=2>the session layer. What seems to be 
missing here is a model for how</FONT> <BR><FONT size=2>QoS is signalled at the 
transport layer to set up the required transport</FONT> <BR><FONT size=2>(and 
underlying mechanisms). <BR><SPAN class=627094115-21012002><FONT face=Arial 
color=#0000ff>[Chen, Weijing]&nbsp;&nbsp;Yes, that is the 
case.</FONT></SPAN><BR></FONT></P>
<P><FONT size=2>&nbsp; I don't believe you are proposing a "layering" of 
signalling protocols, </FONT><BR><FONT size=2>one for session establishment, 
then one for transport, etc. So, the question,</FONT> <BR><FONT size=2>becomes, 
how are the QoS transport mechanisms established? In the internet 
</FONT><BR><FONT size=2>model there is only one end-to-end transport session 
(e.g. TCP, RTP, UDP), </FONT><BR><FONT size=2>but underneath the transport is a 
series of inter-connected networks, each </FONT><BR><FONT size=2>with 
potentially different characteristics. </FONT></P>
<P><FONT size=2>&nbsp; This is end-to-end QoS support structure has to be set up 
and maintained</FONT> <BR><FONT size=2>in order for the end to end session QoS 
to be realized. The solution may be</FONT> <BR><FONT size=2>a single protocol 
that travels from host to host, such as RSVP, or it may</FONT> <BR><FONT 
size=2>be a collection of protocols that are optimized for each portion of 
the</FONT> <BR><FONT size=2>end-to-end path: e.g. host to access network, access 
to core network, </FONT><BR><FONT size=2>core to core network, etc.</FONT> 
<BR><SPAN class=627094115-21012002><FONT face=Arial color=#0000ff size=2>[Chen, 
Weijing]&nbsp;I have a doubt about a single protocol solution. It is certainly a 
great goal for engineer like you and me. But in reality, either for legacy 
network reason, or other&nbsp;business reason,&nbsp;a&nbsp;single protocol from 
end-to-end&nbsp;has never happened, and will never happened.&nbsp;Look at PSTN 
world, they have multiple favors of SS7. But they do have a universal 
host-to-access network protocol DTMF. What we&nbsp;need in NSIS is DTMF 
equivalent protocol for data network.</FONT></SPAN></P>
<P><FONT size=2>&nbsp; It is too early to determine which approach is best, but 
in either case,</FONT> <BR><FONT size=2>do we not need to understand the 
end-to-end requirements for this signalling</FONT> <BR><FONT 
size=2>capability?</FONT> <BR></P>
<P><FONT size=2>Gary Kenward</FONT> </P>
<P><FONT size=2>&gt; -----Original Message-----</FONT> <BR><FONT size=2>&gt; 
From: Schneider, Marco [<A 
href="mailto:schneider@tri.sbc.com">mailto:schneider@tri.sbc.com</A>]</FONT> 
<BR><FONT size=2>&gt; Sent: January 18, 2002 15:10</FONT> <BR><FONT size=2>&gt; 
To: 'Roy, Radhika R, ALASO'; Kenward, Gary [WDLN2:AN10:EXCH]; Loughney</FONT> 
<BR><FONT size=2>&gt; John (NRC/Helsinki); brunner@ccrle.nec.de; Yaron Kahana; 
</FONT><BR><FONT size=2>&gt; Geib, Ruediger;</FONT> <BR><FONT size=2>&gt; 
dick.rr.knight@bt.com</FONT> <BR><FONT size=2>&gt; Cc: nsis@ietf.org</FONT> 
<BR><FONT size=2>&gt; Subject: RE: [NSIS] Two kinds of requirements</FONT> 
<BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; 
Hi Roy,</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; Below is the 
original text from your reponse to Gary Kenward. </FONT><BR><FONT size=2>&gt; 
Hopefully the</FONT> <BR><FONT size=2>&gt; context is clear.</FONT> <BR><FONT 
size=2>&gt; </FONT><BR><FONT size=2>&gt; "[Roy, Radhika R, ALARC]&nbsp; I would 
say that it is the QOS needs of the</FONT> <BR><FONT size=2>&gt; application 
(e.g., SIP-based VoIP) that the user likes to express (as</FONT> <BR><FONT 
size=2>&gt; opposed to "service"). Similarly, instead of network 
</FONT><BR><FONT size=2>&gt; services, we would say</FONT> <BR><FONT size=2>&gt; 
network layer QOS services (e.g., RSVP, DiffServ, MPLS). We </FONT><BR><FONT 
size=2>&gt; would develop</FONT> <BR><FONT size=2>&gt; the end-to-end 
(application layer) QOS signaling protocol </FONT><BR><FONT size=2>&gt; (say, 
NSIS QOS).</FONT> <BR><FONT size=2>&gt; Now, there needs to have some kinds of 
standards how NSIS QOS </FONT><BR><FONT size=2>&gt; will be mapped</FONT> 
<BR><FONT size=2>&gt; over RSVP, DiffServ, MPLS, etc."</FONT> <BR><FONT 
size=2>&gt; </FONT><BR><FONT size=2>&gt; So by End-to-End you mean between 
directly between two </FONT><BR><FONT size=2>&gt; "users". This is</FONT> 
<BR><FONT size=2>&gt; session level signaling and I don't believe the signaling 
</FONT><BR><FONT size=2>&gt; part is within the</FONT> <BR><FONT size=2>&gt; 
scope of this working group. An application level QOS </FONT><BR><FONT 
size=2>&gt; specification may be. </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT 
size=2>&gt; After a session level agreement on QOS, the </FONT><BR><FONT 
size=2>&gt; host/client/customer will need</FONT> <BR><FONT size=2>&gt; to 
signal an actual reservation request to the network for </FONT><BR><FONT 
size=2>&gt; the necessary QOS</FONT> <BR><FONT size=2>&gt; agreed to at the 
session level. This is the protocol that we </FONT><BR><FONT size=2>&gt; need to 
work</FONT> <BR><FONT size=2>&gt; on. </FONT><BR><FONT size=2>&gt; 
</FONT><BR><FONT size=2>&gt; This approach is discussed in the SIP draft "SIP 
Extensions for Media</FONT> <BR><FONT size=2>&gt; Authorization" 
(draft-ietf-sip-call-auth-03.txt) and the RAP draft</FONT> <BR><FONT size=2>&gt; 
"Framework for session set-up with media authorization"</FONT> <BR><FONT 
size=2>&gt; (draft-ietf-rap-session-auth-02.txt).</FONT> <BR><FONT size=2>&gt; 
</FONT><BR><FONT size=2>&gt; Marco Schneider</FONT> <BR><FONT size=2>&gt; 
</FONT><BR><FONT size=2>&gt; -----Original Message-----</FONT> <BR><FONT 
size=2>&gt; From: Roy, Radhika R, ALASO [<A 
href="mailto:rrroy@att.com">mailto:rrroy@att.com</A>]</FONT> <BR><FONT 
size=2>&gt; Sent: Friday, January 18, 2002 9:18 AM</FONT> <BR><FONT size=2>&gt; 
To: Schneider, Marco; Gary Kenward; Loughney John (NRC/Helsinki);</FONT> 
<BR><FONT size=2>&gt; brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;</FONT> 
<BR><FONT size=2>&gt; dick.rr.knight@bt.com</FONT> <BR><FONT size=2>&gt; Cc: 
nsis@ietf.org</FONT> <BR><FONT size=2>&gt; Subject: RE: [NSIS] Two kinds of 
requirements</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; 
</FONT><BR><FONT size=2>&gt; Defined below [RRR]</FONT> <BR><FONT size=2>&gt; 
</FONT><BR><FONT size=2>&gt; -----Original Message-----</FONT> <BR><FONT 
size=2>&gt; From: Schneider, Marco [<A 
href="mailto:schneider@tri.sbc.com">mailto:schneider@tri.sbc.com</A>]</FONT> 
<BR><FONT size=2>&gt; Sent: Thursday, January 17, 2002 8:47 PM</FONT> <BR><FONT 
size=2>&gt; To: Roy, Radhika R, ALASO; Gary Kenward; Loughney John 
(NRC/Helsinki);</FONT> <BR><FONT size=2>&gt; brunner@ccrle.nec.de; Yaron Kahana; 
Geib, Ruediger;</FONT> <BR><FONT size=2>&gt; dick.rr.knight@bt.com</FONT> 
<BR><FONT size=2>&gt; Cc: nsis@ietf.org</FONT> <BR><FONT size=2>&gt; Subject: 
RE: [NSIS] Two kinds of requirements</FONT> <BR><FONT size=2>&gt; 
</FONT><BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; Hi Roy,</FONT> 
<BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; Can you please define what 
you mean by "End-to-End </FONT><BR><FONT size=2>&gt; Application Layer 
QOS</FONT> <BR><FONT size=2>&gt; Signaling". Thanks.</FONT> <BR><FONT 
size=2>&gt; </FONT><BR><FONT size=2>&gt; [RRR] Suppose an user is initiation a 
SIP call to another </FONT><BR><FONT size=2>&gt; user with audio,</FONT> 
<BR><FONT size=2>&gt; video, and data. The use needs to express the needs of QOS 
</FONT><BR><FONT size=2>&gt; for audio, video,</FONT> <BR><FONT size=2>&gt; and 
data to another user. </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; 
[RRR] The signaling mechanism that allows to express the QOS </FONT><BR><FONT 
size=2>&gt; parameters of</FONT> <BR><FONT size=2>&gt; audio, video, and data is 
termed as the "End-to-End </FONT><BR><FONT size=2>&gt; Application Layer 
QOS</FONT> <BR><FONT size=2>&gt; Signaling."</FONT> <BR><FONT size=2>&gt; 
</FONT><BR><FONT size=2>&gt; Marco Schneider</FONT> <BR><FONT size=2>&gt; 
</FONT><BR><FONT size=2>&gt; 
_______________________________________________</FONT> <BR><FONT size=2>&gt; 
nsis mailing list</FONT> <BR><FONT size=2>&gt; nsis@ietf.org</FONT> <BR><FONT 
size=2>&gt; <A target=_blank 
href="https://www1.ietf.org/mailman/listinfo/nsis">https://www1.ietf.org/mailman/listinfo/nsis</A></FONT> 
<BR><FONT size=2>&gt; </FONT></P></BODY></HTML>

------_=_NextPart_001_01C1A293.28603350--

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



From daemon@optimus.ietf.org  Mon Jan 21 11:05: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 LAA13975
	for <nsis-archive@odin.ietf.org>; Mon, 21 Jan 2002 11:05:04 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id LAA14982
	for nsis-archive@odin.ietf.org; Mon, 21 Jan 2002 11:05: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 LAA14869;
	Mon, 21 Jan 2002 11:04: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 LAA14839
	for <nsis@optimus.ietf.org>; Mon, 21 Jan 2002 11:03:59 -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 LAA13882
	for <nsis@ietf.org>; Mon, 21 Jan 2002 11:03:55 -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 g0LG64T00662;
	Mon, 21 Jan 2002 10:06:05 -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 g0LG3Qa17097;
	Mon, 21 Jan 2002 10:03:26 -0600 (CST)
Received: by TRIMAIL2.ad.tri.sbc.com with Internet Mail Service (5.5.2653.19)
	id <ZND32SVM>; Mon, 21 Jan 2002 10:03:52 -0600
Message-ID: <905A1C4ABF353F4C8CC16FA9F53DD0D6322429@TRIMAIL2.ad.tri.sbc.com>
From: "Chen, Weijing" <wchen@tri.sbc.com>
To: "'dick.rr.knight@bt.com'" <dick.rr.knight@bt.com>,
        "Schneider, Marco"
	 <schneider@tri.sbc.com>, rrroy@att.com,
        gkenward@nortelnetworks.com, john.loughney@nokia.com,
        brunner@ccrle.nec.de, ykahana@comgates.co.il,
        Ruediger.Geib@t-systems.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements
Date: Mon, 21 Jan 2002 10:03:44 -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

See the comments in [wj].

--
Weijing Chen
SBC Technology Resources
9505 Arboretum Blvd.
Austin, TX 78759
512 372 5710
wchen@tri.sbc.com



 -----Original Message-----
From: 	dick.rr.knight@bt.com [mailto:dick.rr.knight@bt.com] 
Sent:	Monday, January 21, 2002 4:10 AM
To:	Schneider, Marco; rrroy@att.com; gkenward@nortelnetworks.com;
john.loughney@nokia.com; brunner@ccrle.nec.de; ykahana@comgates.co.il;
Ruediger.Geib@t-systems.com; dick.rr.knight@bt.com
Cc:	nsis@ietf.org
Subject:	RE: [NSIS] Two kinds of requirements


I don't think you can do the session level QoS agreement soley between
end-users, and ignore the capabilities of the intermediate networks. Suppose
you negotiate the perfect QoS for an application, and then request a
reservation to the network, what happens when the network can fulfill the
reservation? Do you begin the session level negotiation again, and keep
going stepwise until you get to the highest possible QoS the network can
give you?
Or do you accept the highest level of QoS the network can provide and then
see if you can accept that for the session?

[wj] I think you can separate QoS of application and underline transport.
Supposed a user application negotiate (or obtain) a minimum QoS for its
application, then it uses our NSIS signaling protocol to request the network
for this QoS. If network can not fulfill the QoS reservation, too bad for
user. As a network service operator, I lost revenue and I will spank my NP&E
engineer for not doing his work. Don't combine the different thing to make
NSIS complex. For our experience with equipment suppliers, complex thing
normally does not work. In most of case, they don't even bother to implement
it.


It is in my mind, for the above reasons, that you need a protocol that can
request QoS and that request can be processed and acted upon at both user
and network nodes. It cannot be limited to user-network nor user-user.

[wj] I still think as the first step, we need to focus on how can the user
asks destination and QoS (where and how)  from network (user-to-network,
network-to-user). How the network to satisfy user request has more solutions
such as your outlines in below.

I do agree that it need not be processed on a per hop basis as it can
transverse a domain with a single QoS mechanism. That mechanism, be it
diffserv or intserv, PNNI, RSVP, or even over-provisioning, takes care of
the policing and the "path" establishment within the domain.


Dick

-----Original Message-----
From: Schneider, Marco [mailto:schneider@tri.sbc.com]
Sent: 18 January 2002 20:10
To: 'Roy, Radhika R, ALASO'; Gary Kenward; Loughney John (NRC/Helsinki);
brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
dick.rr.knight@bt.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


Hi Roy,

Below is the original text from your reponse to Gary Kenward. Hopefully the
context is clear.

"[Roy, Radhika R, ALARC]  I would say that it is the QOS needs of the
application (e.g., SIP-based VoIP) that the user likes to express (as
opposed to "service"). Similarly, instead of network services, we would say
network layer QOS services (e.g., RSVP, DiffServ, MPLS). We would develop
the end-to-end (application layer) QOS signaling protocol (say, NSIS QOS).
Now, there needs to have some kinds of standards how NSIS QOS will be mapped
over RSVP, DiffServ, MPLS, etc."

So by End-to-End you mean between directly between two "users". This is
session level signaling and I don't believe the signaling part is within the
scope of this working group. An application level QOS specification may be. 

After a session level agreement on QOS, the host/client/customer will need
to signal an actual reservation request to the network for the necessary QOS
agreed to at the session level. This is the protocol that we need to work
on. 

This approach is discussed in the SIP draft "SIP Extensions for Media
Authorization" (draft-ietf-sip-call-auth-03.txt) and the RAP draft
"Framework for session set-up with media authorization"
(draft-ietf-rap-session-auth-02.txt).

Marco Schneider

-----Original Message-----
From: Roy, Radhika R, ALASO [mailto:rrroy@att.com]
Sent: Friday, January 18, 2002 9:18 AM
To: Schneider, Marco; Gary Kenward; Loughney John (NRC/Helsinki);
brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
dick.rr.knight@bt.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


Defined below [RRR]

-----Original Message-----
From: Schneider, Marco [mailto:schneider@tri.sbc.com]
Sent: Thursday, January 17, 2002 8:47 PM
To: Roy, Radhika R, ALASO; Gary Kenward; Loughney John (NRC/Helsinki);
brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
dick.rr.knight@bt.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


Hi Roy,

Can you please define what you mean by "End-to-End Application Layer QOS
Signaling". Thanks.

[RRR] Suppose an user is initiation a SIP call to another user with audio,
video, and data. The use needs to express the needs of QOS for audio, video,
and data to another user. 

[RRR] The signaling mechanism that allows to express the QOS parameters of
audio, video, and data is termed as the "End-to-End Application Layer QOS
Signaling."

Marco Schneider

_______________________________________________
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 Jan 21 11:07: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 LAA14154
	for <nsis-archive@odin.ietf.org>; Mon, 21 Jan 2002 11:07:04 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id LAA15128
	for nsis-archive@odin.ietf.org; Mon, 21 Jan 2002 11:07: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 KAA14088;
	Mon, 21 Jan 2002 10:56: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 KAA14055
	for <nsis@optimus.ietf.org>; Mon, 21 Jan 2002 10:56:39 -0500 (EST)
Received: from netmail2.alcatel.com (netmail2.alcatel.com [128.251.168.51])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13488
	for <nsis@ietf.org>; Mon, 21 Jan 2002 10:56:35 -0500 (EST)
Received: from auds952.usa.alcatel.com (auds952.usa.alcatel.com [143.209.238.7])
	by netmail2.alcatel.com (8.9.1/8.9.1) with ESMTP id JAA08421
	for <nsis@ietf.org>; Mon, 21 Jan 2002 09:56:09 -0600 (CST)
Received: from alcatel.com (localhost [127.0.0.1])
	by auds952.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g0LFu8m22032
	for <nsis@ietf.org>; Mon, 21 Jan 2002 09:56:08 -0600 (CST)
Message-ID: <3C4C3A14.8090307@alcatel.com>
Date: Mon, 21 Jan 2002 09:56:04 -0600
From: Behcet Sarikaya <behcet.sarikaya@alcatel.com>
Organization: Alcatel USA
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2
X-Accept-Language: en-us
MIME-Version: 1.0
To: nsis@ietf.org
Subject: Re: [NSIS] Charter of nsis - Reading list
References: <0C1353ABB1DEB74DB067ADFF749C4EEF5D93CC@esebe004.NOE.Nokia.com>
Content-Type: multipart/alternative;
 boundary="------------050704050903020902070808"
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


--------------050704050903020902070808
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Hello all,
  Can we also add the following I-D:

> draft-ietf-issll-ds-map-01.txt Integrated Service Mappings for 
> Differentiated Services Networks

to the reading list?


john.loughney@nokia.com wrote:

>Hi Steven,
>
>>RSVP is just the signalling.  Please take the time to read RFC 2205
>>(and associated documents) if there is any confusion.  Perhaps, a 
>>reading list (in priority order) about RSVP and Integrated Services 
>>would be useful.
>>
>
>Thanks for the reading list.  I would agree with your (unwritten)
>statement that RSVP is quite often equated with Intserv.  I still
>think that for NSIS, a simplification of the RSVP signaling and
>signaling model would be a good goal.
>
>best regards,
>John
>
Regards,


-- 
Behcet 



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

<html>
<head>
</head>
<body>
Hello all,<br>
&nbsp; Can we also add the following I-D:<br>
<blockquote type="cite">draft-ietf-issll-ds-map-01.txt Integrated Service
Mappings for Differentiated Services Networks</blockquote>
to the reading list? <br>
  <br>
  <br>
<a class="moz-txt-link-abbreviated" href="mailto:john.loughney@nokia.com">john.loughney@nokia.com</a> wrote:<br>
  <blockquote type="cite" cite="mid:0C1353ABB1DEB74DB067ADFF749C4EEF5D93CC@esebe004.NOE.Nokia.com">
    <pre wrap="">Hi Steven,<br><br></pre>
    <blockquote type="cite">
      <pre wrap="">RSVP is just the signalling.  Please take the time to read RFC 2205<br>(and associated documents) if there is any confusion.  Perhaps, a <br>reading list (in priority order) about RSVP and Integrated Services <br>would be useful.<br></pre>
      </blockquote>
      <pre wrap=""><!----><br>Thanks for the reading list.  I would agree with your (unwritten)<br>statement that RSVP is quite often equated with Intserv.  I still<br>think that for NSIS, a simplification of the RSVP signaling and<br>signaling model would be a good goal.<br><br>best regards,<br>John<br><br></pre>
      </blockquote>
Regards,<br>
      <blockquote type="cite" cite="mid:0C1353ABB1DEB74DB067ADFF749C4EEF5D93CC@esebe004.NOE.Nokia.com"></blockquote>
        <br>
        <pre class="moz-signature" cols="$mailwrapcol">-- 
Behcet </pre>
        <br>
        </body>
        </html>

--------------050704050903020902070808--


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



From daemon@optimus.ietf.org  Mon Jan 21 11:16:26 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14604
	for <nsis-archive@odin.ietf.org>; Mon, 21 Jan 2002 11:16:26 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id LAA15531
	for nsis-archive@odin.ietf.org; Mon, 21 Jan 2002 11:16: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 LAA15111;
	Mon, 21 Jan 2002 11:06:58 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA15043
	for <nsis@optimus.ietf.org>; Mon, 21 Jan 2002 11:06:55 -0500 (EST)
Received: from ckmso1.proxy.att.com (ckmso1.att.com [12.20.58.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14128
	for <nsis@ietf.org>; Mon, 21 Jan 2002 11:06:49 -0500 (EST)
Received: from attrh1i.attrh.att.com ([135.71.62.10])
	by ckmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id g0LG6HZ24051
	for <nsis@ietf.org>; Mon, 21 Jan 2002 11:06:17 -0500 (EST)
Received: from occlust04evs1.ugd.att.com (135.71.164.13) by attrh1i.attrh.att.com (5.5.029)
        id 3C0BA3A50023EB0E; Mon, 21 Jan 2002 11:04:41 -0500
content-class: urn:content-classes:message
Subject: RE: [NSIS] Two kinds of requirements
Date: Mon, 21 Jan 2002 11:04:41 -0500
Message-ID: <62DA45D4963FA747BA1B253E266760F9011E7BA0@OCCLUST04EVS1.ugd.att.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Thread-Topic: [NSIS] Two kinds of requirements
Thread-Index: AcGgXQz/4KZKswxOEdanAgCQJ3s5nwCNowpA
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
From: "Roy, Radhika R, ALASO" <rrroy@att.com>
To: "Schneider, Marco" <schneider@tri.sbc.com>,
        "Gary Kenward" <gkenward@nortelnetworks.com>,
        "Loughney John (NRC/Helsinki)" <john.loughney@nokia.com>,
        <brunner@ccrle.nec.de>, "Yaron Kahana" <ykahana@comgates.co.il>,
        "Geib, Ruediger" <Ruediger.Geib@t-systems.com>,
        <dick.rr.knight@bt.com>
Cc: <nsis@ietf.org>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA15044
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, Marco:

Let me try to clarify from your point of view.

It seems to agree that there needs to be a session level QOS agreement. Let us analyze what is this. To make an agreement, we need to send some messages between the end points. This may be termed as "signaling."

A session expresses its QOS for its "application" that may consist of media: audio, video, and/or data.

In general, the above two items can be expressed as "Application Layer QOS signaling."

I think that we are agreeing on technical points.

Best regards,
Radhika R. Roy

-----Original Message-----
From: Schneider, Marco [mailto:schneider@tri.sbc.com]
Sent: Friday, January 18, 2002 3:10 PM
To: Roy, Radhika R, ALASO; Gary Kenward; Loughney John (NRC/Helsinki);
brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
dick.rr.knight@bt.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


Hi Roy,

Below is the original text from your reponse to Gary Kenward. Hopefully the
context is clear.

"[Roy, Radhika R, ALARC]  I would say that it is the QOS needs of the
application (e.g., SIP-based VoIP) that the user likes to express (as
opposed to "service"). Similarly, instead of network services, we would say
network layer QOS services (e.g., RSVP, DiffServ, MPLS). We would develop
the end-to-end (application layer) QOS signaling protocol (say, NSIS QOS).
Now, there needs to have some kinds of standards how NSIS QOS will be mapped
over RSVP, DiffServ, MPLS, etc."

So by End-to-End you mean between directly between two "users". This is
session level signaling and I don't believe the signaling part is within the
scope of this working group. An application level QOS specification may be. 

After a session level agreement on QOS, the host/client/customer will need
to signal an actual reservation request to the network for the necessary QOS
agreed to at the session level. This is the protocol that we need to work
on. 

This approach is discussed in the SIP draft "SIP Extensions for Media
Authorization" (draft-ietf-sip-call-auth-03.txt) and the RAP draft
"Framework for session set-up with media authorization"
(draft-ietf-rap-session-auth-02.txt).

Marco Schneider

-----Original Message-----
From: Roy, Radhika R, ALASO [mailto:rrroy@att.com]
Sent: Friday, January 18, 2002 9:18 AM
To: Schneider, Marco; Gary Kenward; Loughney John (NRC/Helsinki);
brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
dick.rr.knight@bt.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


Defined below [RRR]

-----Original Message-----
From: Schneider, Marco [mailto:schneider@tri.sbc.com]
Sent: Thursday, January 17, 2002 8:47 PM
To: Roy, Radhika R, ALASO; Gary Kenward; Loughney John (NRC/Helsinki);
brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
dick.rr.knight@bt.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


Hi Roy,

Can you please define what you mean by "End-to-End Application Layer QOS
Signaling". Thanks.

[RRR] Suppose an user is initiation a SIP call to another user with audio,
video, and data. The use needs to express the needs of QOS for audio, video,
and data to another user. 

[RRR] The signaling mechanism that allows to express the QOS parameters of
audio, video, and data is termed as the "End-to-End Application Layer QOS
Signaling."

Marco Schneider

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



From daemon@optimus.ietf.org  Mon Jan 21 11:21: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 LAA15003
	for <nsis-archive@odin.ietf.org>; Mon, 21 Jan 2002 11:21:36 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id LAA15735
	for nsis-archive@odin.ietf.org; Mon, 21 Jan 2002 11:21: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 LAA15662;
	Mon, 21 Jan 2002 11:20: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 LAA15627
	for <nsis@optimus.ietf.org>; Mon, 21 Jan 2002 11:20:30 -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 LAA14910
	for <nsis@ietf.org>; Mon, 21 Jan 2002 11:20:26 -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 g0LGMZT00820;
	Mon, 21 Jan 2002 10:22:35 -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 g0LGJvc17715;
	Mon, 21 Jan 2002 10:19:57 -0600 (CST)
Received: by TRIMAIL2.ad.tri.sbc.com with Internet Mail Service (5.5.2653.19)
	id <ZND32SY6>; Mon, 21 Jan 2002 10:20:23 -0600
Message-ID: <905A1C4ABF353F4C8CC16FA9F53DD0D632242A@TRIMAIL2.ad.tri.sbc.com>
From: "Chen, Weijing" <wchen@tri.sbc.com>
To: "'Georgios Karagiannis (ELN)'" <Georgios.Karagiannis@eln.ericsson.se>
Cc: "'nsis@ietf.org'" <nsis@ietf.org>
Subject: RE: [NSIS] Two kinds of requirements
Date: Mon, 21 Jan 2002 10:20:19 -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

I am afraid that we are creating a Utopian solution here.

>>Therefore, the [everyhop] component should be supported by the NSIS
protocol.
>>However a "host" or a "edge" should be able to activated or not.

It is not question of who activate it. It is the question of who initiate
it. Who is going to stuff the [everyhop] component into signaling message?
Don't expect it from [end host].

>>Furthermore, in my opinion the NSIS protocol should be:
>>end host - end host: the NSIS protocol is terminated at end hosts;
>>end host - proxy: the NSIS protocol is terminated at end host and proxy;

>>end host - edge: the NSIS protocol is terminated at end end host and edge;
This should be our focus now.

>>edge - edge: the NSIS protocol is terminated at egdes of one/multiple
domains;

Yes, a universal protocol used by different segments is very nice. But can
it be agreed on and implementable? The missing piece in today's protocol
soup is user-to-network signaling, sort of DTMF in data world. Let's solve
it first here in NSIS. Later on we can engage on a more ambition mission.

--
Weijing Chen
SBC Technology Resources
9505 Arboretum Blvd.
Austin, TX 78759
512 372 5710
wchen@tri.sbc.com

-----Original Message-----
From: 	Georgios Karagiannis (ELN)
[mailto:Georgios.Karagiannis@eln.ericsson.se] 
Sent:	Monday, January 21, 2002 4:30 AM
To:	'dick.rr.knight@bt.com'
Cc:	nsis@ietf.org
Subject:	RE: [NSIS] Two kinds of requirements


Hi Dick

Please see my comment in line:
[DK]>> I do agree that it need not be processed on a per hop basis as it can
[DK]>> transverse a domain with a single QoS mechanism. That mechanism, be
it
[DK]>> diffserv or intserv, PNNI, RSVP, or even over-provisioning, takes
care of
[DK]>> the policing and the "path" establishment within the domain.

Please note that at the moment there are scenarios that will need to 
process the [everyhop] component. Some of these scenarios are the Radio
Access
Network and Mobile IP,..
Therefore, the [everyhop] component should be supported by the NSIS
protocol.
However a "host" or a "edge" should be able to activated or not.

Furthermore, in my opinion the NSIS protocol should be:
end host - end host: the NSIS protocol is terminated at end hosts;
end host - proxy: the NSIS protocol is terminated at end host and proxy;
end host - edge: the NSIS protocol is terminated at end end host and edge;
edge - edge: the NSIS protocol is terminated at egdes of one/multiple
domains;


Best regards,
Georgios


-----Original Message-----
From: Schneider, Marco [mailto:schneider@tri.sbc.com]
Sent: 18 January 2002 20:10
To: 'Roy, Radhika R, ALASO'; Gary Kenward; Loughney John (NRC/Helsinki);
brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
dick.rr.knight@bt.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


Hi Roy,

Below is the original text from your reponse to Gary Kenward. Hopefully the
context is clear.

"[Roy, Radhika R, ALARC]  I would say that it is the QOS needs of the
application (e.g., SIP-based VoIP) that the user likes to express (as
opposed to "service"). Similarly, instead of network services, we would say
network layer QOS services (e.g., RSVP, DiffServ, MPLS). We would develop
the end-to-end (application layer) QOS signaling protocol (say, NSIS QOS).
Now, there needs to have some kinds of standards how NSIS QOS will be mapped
over RSVP, DiffServ, MPLS, etc."

So by End-to-End you mean between directly between two "users". This is
session level signaling and I don't believe the signaling part is within the
scope of this working group. An application level QOS specification may be. 

After a session level agreement on QOS, the host/client/customer will need
to signal an actual reservation request to the network for the necessary QOS
agreed to at the session level. This is the protocol that we need to work
on. 

This approach is discussed in the SIP draft "SIP Extensions for Media
Authorization" (draft-ietf-sip-call-auth-03.txt) and the RAP draft
"Framework for session set-up with media authorization"
(draft-ietf-rap-session-auth-02.txt).

Marco Schneider

-----Original Message-----
From: Roy, Radhika R, ALASO [mailto:rrroy@att.com]
Sent: Friday, January 18, 2002 9:18 AM
To: Schneider, Marco; Gary Kenward; Loughney John (NRC/Helsinki);
brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
dick.rr.knight@bt.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


Defined below [RRR]

-----Original Message-----
From: Schneider, Marco [mailto:schneider@tri.sbc.com]
Sent: Thursday, January 17, 2002 8:47 PM
To: Roy, Radhika R, ALASO; Gary Kenward; Loughney John (NRC/Helsinki);
brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
dick.rr.knight@bt.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


Hi Roy,

Can you please define what you mean by "End-to-End Application Layer QOS
Signaling". Thanks.

[RRR] Suppose an user is initiation a SIP call to another user with audio,
video, and data. The use needs to express the needs of QOS for audio, video,
and data to another user. 

[RRR] The signaling mechanism that allows to express the QOS parameters of
audio, video, and data is termed as the "End-to-End Application Layer QOS
Signaling."

Marco Schneider

_______________________________________________
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  Mon Jan 21 12:21:04 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17482
	for <nsis-archive@odin.ietf.org>; Mon, 21 Jan 2002 12:21:04 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id MAA19350
	for nsis-archive@odin.ietf.org; Mon, 21 Jan 2002 12:21: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 MAA19305;
	Mon, 21 Jan 2002 12:19: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 MAA19274
	for <nsis@optimus.ietf.org>; Mon, 21 Jan 2002 12:19:09 -0500 (EST)
Received: from cbibipnt03.HC.BT.COM (saturn.bt.com [193.113.57.20])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17439
	for <nsis@ietf.org>; Mon, 21 Jan 2002 12:19:04 -0500 (EST)
From: dick.rr.knight@bt.com
Received: by cbibipnt03.hc.bt.com with Internet Mail Service (5.5.2652.35)
	id <DA1WG9Z5>; Mon, 21 Jan 2002 17:18:40 -0000
Message-ID: <451D45016C2CD2119DA50000F8FE7F07080E5A51@mlngcbnt01.hc.bt.com>
To: wchen@tri.sbc.com, Georgios.Karagiannis@eln.ericsson.se
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements
Date: Mon, 21 Jan 2002 17:14:45 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
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

Weijing,

I can understand your desire to concentrate on the user-network problem
space.

However - I am concerned that the result will be an agreed and working
solution
in this problem space that is then not supported at the network-network
interface
(interdomain in IP speak, NNI in PSTN jargon).

If the user-network interface is one protocol and then the next hop is RSVP
with intserv,
then the next is MPLS with LSP and so on, will you see anything at the far
and distant end
that looks anything like the original user-network request?

Dick

-----Original Message-----
From: Chen, Weijing [mailto:wchen@tri.sbc.com]
Sent: 21 January 2002 16:20
To: 'Georgios Karagiannis (ELN)'
Cc: 'nsis@ietf.org'
Subject: RE: [NSIS] Two kinds of requirements


I am afraid that we are creating a Utopian solution here.

>>Therefore, the [everyhop] component should be supported by the NSIS
protocol.
>>However a "host" or a "edge" should be able to activated or not.

It is not question of who activate it. It is the question of who initiate
it. Who is going to stuff the [everyhop] component into signaling message?
Don't expect it from [end host].

>>Furthermore, in my opinion the NSIS protocol should be:
>>end host - end host: the NSIS protocol is terminated at end hosts;
>>end host - proxy: the NSIS protocol is terminated at end host and proxy;

>>end host - edge: the NSIS protocol is terminated at end end host and edge;
This should be our focus now.

>>edge - edge: the NSIS protocol is terminated at egdes of one/multiple
domains;

Yes, a universal protocol used by different segments is very nice. But can
it be agreed on and implementable? The missing piece in today's protocol
soup is user-to-network signaling, sort of DTMF in data world. Let's solve
it first here in NSIS. Later on we can engage on a more ambition mission.

--
Weijing Chen
SBC Technology Resources
9505 Arboretum Blvd.
Austin, TX 78759
512 372 5710
wchen@tri.sbc.com

-----Original Message-----
From: 	Georgios Karagiannis (ELN)
[mailto:Georgios.Karagiannis@eln.ericsson.se] 
Sent:	Monday, January 21, 2002 4:30 AM
To:	'dick.rr.knight@bt.com'
Cc:	nsis@ietf.org
Subject:	RE: [NSIS] Two kinds of requirements


Hi Dick

Please see my comment in line:
[DK]>> I do agree that it need not be processed on a per hop basis as it can
[DK]>> transverse a domain with a single QoS mechanism. That mechanism, be
it
[DK]>> diffserv or intserv, PNNI, RSVP, or even over-provisioning, takes
care of
[DK]>> the policing and the "path" establishment within the domain.

Please note that at the moment there are scenarios that will need to 
process the [everyhop] component. Some of these scenarios are the Radio
Access
Network and Mobile IP,..
Therefore, the [everyhop] component should be supported by the NSIS
protocol.
However a "host" or a "edge" should be able to activated or not.

Furthermore, in my opinion the NSIS protocol should be:
end host - end host: the NSIS protocol is terminated at end hosts;
end host - proxy: the NSIS protocol is terminated at end host and proxy;
end host - edge: the NSIS protocol is terminated at end end host and edge;
edge - edge: the NSIS protocol is terminated at egdes of one/multiple
domains;


Best regards,
Georgios


-----Original Message-----
From: Schneider, Marco [mailto:schneider@tri.sbc.com]
Sent: 18 January 2002 20:10
To: 'Roy, Radhika R, ALASO'; Gary Kenward; Loughney John (NRC/Helsinki);
brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
dick.rr.knight@bt.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


Hi Roy,

Below is the original text from your reponse to Gary Kenward. Hopefully the
context is clear.

"[Roy, Radhika R, ALARC]  I would say that it is the QOS needs of the
application (e.g., SIP-based VoIP) that the user likes to express (as
opposed to "service"). Similarly, instead of network services, we would say
network layer QOS services (e.g., RSVP, DiffServ, MPLS). We would develop
the end-to-end (application layer) QOS signaling protocol (say, NSIS QOS).
Now, there needs to have some kinds of standards how NSIS QOS will be mapped
over RSVP, DiffServ, MPLS, etc."

So by End-to-End you mean between directly between two "users". This is
session level signaling and I don't believe the signaling part is within the
scope of this working group. An application level QOS specification may be. 

After a session level agreement on QOS, the host/client/customer will need
to signal an actual reservation request to the network for the necessary QOS
agreed to at the session level. This is the protocol that we need to work
on. 

This approach is discussed in the SIP draft "SIP Extensions for Media
Authorization" (draft-ietf-sip-call-auth-03.txt) and the RAP draft
"Framework for session set-up with media authorization"
(draft-ietf-rap-session-auth-02.txt).

Marco Schneider

-----Original Message-----
From: Roy, Radhika R, ALASO [mailto:rrroy@att.com]
Sent: Friday, January 18, 2002 9:18 AM
To: Schneider, Marco; Gary Kenward; Loughney John (NRC/Helsinki);
brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
dick.rr.knight@bt.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


Defined below [RRR]

-----Original Message-----
From: Schneider, Marco [mailto:schneider@tri.sbc.com]
Sent: Thursday, January 17, 2002 8:47 PM
To: Roy, Radhika R, ALASO; Gary Kenward; Loughney John (NRC/Helsinki);
brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
dick.rr.knight@bt.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


Hi Roy,

Can you please define what you mean by "End-to-End Application Layer QOS
Signaling". Thanks.

[RRR] Suppose an user is initiation a SIP call to another user with audio,
video, and data. The use needs to express the needs of QOS for audio, video,
and data to another user. 

[RRR] The signaling mechanism that allows to express the QOS parameters of
audio, video, and data is termed as the "End-to-End Application Layer QOS
Signaling."

Marco Schneider

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

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

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

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



From daemon@optimus.ietf.org  Mon Jan 21 12:37:52 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17904
	for <nsis-archive@odin.ietf.org>; Mon, 21 Jan 2002 12:37:52 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id MAA20053
	for nsis-archive@odin.ietf.org; Mon, 21 Jan 2002 12:37: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 MAA20002;
	Mon, 21 Jan 2002 12:37: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 MAA19971
	for <nsis@optimus.ietf.org>; Mon, 21 Jan 2002 12:37:13 -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 MAA17895
	for <nsis@ietf.org>; Mon, 21 Jan 2002 12:37:08 -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 g0LHdHT01428
	for <nsis@ietf.org>; Mon, 21 Jan 2002 11:39:18 -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 g0LHadY21032
	for <nsis@ietf.org>; Mon, 21 Jan 2002 11:36:40 -0600 (CST)
Received: by TRIMAIL2.ad.tri.sbc.com with Internet Mail Service (5.5.2653.19)
	id <ZND32TMB>; Mon, 21 Jan 2002 11:37:06 -0600
Message-ID: <905A1C4ABF353F4C8CC16FA9F53DD0D62A6FF7@TRIMAIL2.ad.tri.sbc.com>
From: "Allen, Keith" <kallen@tri.sbc.com>
To: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements
Date: Mon, 21 Jan 2002 11:37:03 -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

Should the design of the protocol be driven by the needs of the user or the
currently implemented network?  If we choose the latter we will end up with
a protocol that will be obsolete when the next new network innovation takes
place, and it may not meet the basic needs of the subscriber.

The Object-Oriented software world has turned to user-centric requirements
(in the form of Use Cases) as the basis for analysis and design.  They are
getting good results with this process.  We should also focus on what the
user wants to do.  The user sends a request to the network, then he doesn't
care what the network has to do to meet it.  If it turns out that RSVP can't
meet the needs of the subscriber it will have to evolve or be replaced.
Unfortunately, though, we don't even know if RSVP will suffice because we
haven't captured what the user can do.

Form follows function.  The function of this protocol should be to enable
subscribers to utilize the guaranteed QoS capabilities of the network on
demand. 


Keith Allen
SBC Technology Resources
9505 Arboretum Blvd.
Austin, TX 78759
(512) 372-5741
kallen@tri.sbc.com

 -----Original Message-----
From: 	dick.rr.knight@bt.com [mailto:dick.rr.knight@bt.com] 
Sent:	Monday, January 21, 2002 11:15 AM
To:	Chen, Weijing; Georgios.Karagiannis@eln.ericsson.se
Cc:	nsis@ietf.org
Subject:	RE: [NSIS] Two kinds of requirements

Weijing,

I can understand your desire to concentrate on the user-network problem
space.

However - I am concerned that the result will be an agreed and working
solution
in this problem space that is then not supported at the network-network
interface
(interdomain in IP speak, NNI in PSTN jargon).

If the user-network interface is one protocol and then the next hop is RSVP
with intserv,
then the next is MPLS with LSP and so on, will you see anything at the far
and distant end
that looks anything like the original user-network request?

Dick

-----Original Message-----
From: Chen, Weijing [mailto:wchen@tri.sbc.com]
Sent: 21 January 2002 16:20
To: 'Georgios Karagiannis (ELN)'
Cc: 'nsis@ietf.org'
Subject: RE: [NSIS] Two kinds of requirements


I am afraid that we are creating a Utopian solution here.

>>Therefore, the [everyhop] component should be supported by the NSIS
protocol.
>>However a "host" or a "edge" should be able to activated or not.

It is not question of who activate it. It is the question of who initiate
it. Who is going to stuff the [everyhop] component into signaling message?
Don't expect it from [end host].

>>Furthermore, in my opinion the NSIS protocol should be:
>>end host - end host: the NSIS protocol is terminated at end hosts;
>>end host - proxy: the NSIS protocol is terminated at end host and proxy;

>>end host - edge: the NSIS protocol is terminated at end end host and edge;
This should be our focus now.

>>edge - edge: the NSIS protocol is terminated at egdes of one/multiple
domains;

Yes, a universal protocol used by different segments is very nice. But can
it be agreed on and implementable? The missing piece in today's protocol
soup is user-to-network signaling, sort of DTMF in data world. Let's solve
it first here in NSIS. Later on we can engage on a more ambition mission.

--
Weijing Chen
SBC Technology Resources
9505 Arboretum Blvd.
Austin, TX 78759
512 372 5710
wchen@tri.sbc.com

-----Original Message-----
From: 	Georgios Karagiannis (ELN)
[mailto:Georgios.Karagiannis@eln.ericsson.se] 
Sent:	Monday, January 21, 2002 4:30 AM
To:	'dick.rr.knight@bt.com'
Cc:	nsis@ietf.org
Subject:	RE: [NSIS] Two kinds of requirements


Hi Dick

Please see my comment in line:
[DK]>> I do agree that it need not be processed on a per hop basis as it can
[DK]>> transverse a domain with a single QoS mechanism. That mechanism, be
it
[DK]>> diffserv or intserv, PNNI, RSVP, or even over-provisioning, takes
care of
[DK]>> the policing and the "path" establishment within the domain.

Please note that at the moment there are scenarios that will need to 
process the [everyhop] component. Some of these scenarios are the Radio
Access
Network and Mobile IP,..
Therefore, the [everyhop] component should be supported by the NSIS
protocol.
However a "host" or a "edge" should be able to activated or not.

Furthermore, in my opinion the NSIS protocol should be:
end host - end host: the NSIS protocol is terminated at end hosts;
end host - proxy: the NSIS protocol is terminated at end host and proxy;
end host - edge: the NSIS protocol is terminated at end end host and edge;
edge - edge: the NSIS protocol is terminated at egdes of one/multiple
domains;


Best regards,
Georgios


-----Original Message-----
From: Schneider, Marco [mailto:schneider@tri.sbc.com]
Sent: 18 January 2002 20:10
To: 'Roy, Radhika R, ALASO'; Gary Kenward; Loughney John (NRC/Helsinki);
brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
dick.rr.knight@bt.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


Hi Roy,

Below is the original text from your reponse to Gary Kenward. Hopefully the
context is clear.

"[Roy, Radhika R, ALARC]  I would say that it is the QOS needs of the
application (e.g., SIP-based VoIP) that the user likes to express (as
opposed to "service"). Similarly, instead of network services, we would say
network layer QOS services (e.g., RSVP, DiffServ, MPLS). We would develop
the end-to-end (application layer) QOS signaling protocol (say, NSIS QOS).
Now, there needs to have some kinds of standards how NSIS QOS will be mapped
over RSVP, DiffServ, MPLS, etc."

So by End-to-End you mean between directly between two "users". This is
session level signaling and I don't believe the signaling part is within the
scope of this working group. An application level QOS specification may be. 

After a session level agreement on QOS, the host/client/customer will need
to signal an actual reservation request to the network for the necessary QOS
agreed to at the session level. This is the protocol that we need to work
on. 

This approach is discussed in the SIP draft "SIP Extensions for Media
Authorization" (draft-ietf-sip-call-auth-03.txt) and the RAP draft
"Framework for session set-up with media authorization"
(draft-ietf-rap-session-auth-02.txt).

Marco Schneider

-----Original Message-----
From: Roy, Radhika R, ALASO [mailto:rrroy@att.com]
Sent: Friday, January 18, 2002 9:18 AM
To: Schneider, Marco; Gary Kenward; Loughney John (NRC/Helsinki);
brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
dick.rr.knight@bt.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


Defined below [RRR]

-----Original Message-----
From: Schneider, Marco [mailto:schneider@tri.sbc.com]
Sent: Thursday, January 17, 2002 8:47 PM
To: Roy, Radhika R, ALASO; Gary Kenward; Loughney John (NRC/Helsinki);
brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
dick.rr.knight@bt.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


Hi Roy,

Can you please define what you mean by "End-to-End Application Layer QOS
Signaling". Thanks.

[RRR] Suppose an user is initiation a SIP call to another user with audio,
video, and data. The use needs to express the needs of QOS for audio, video,
and data to another user. 

[RRR] The signaling mechanism that allows to express the QOS parameters of
audio, video, and data is termed as the "End-to-End Application Layer QOS
Signaling."

Marco Schneider

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

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

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

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

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



From daemon@optimus.ietf.org  Mon Jan 21 12:47: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 MAA18233
	for <nsis-archive@odin.ietf.org>; Mon, 21 Jan 2002 12:47:53 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id MAA20427
	for nsis-archive@odin.ietf.org; Mon, 21 Jan 2002 12:47: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 MAA20375;
	Mon, 21 Jan 2002 12:45: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 MAA20338
	for <nsis@optimus.ietf.org>; Mon, 21 Jan 2002 12:45:53 -0500 (EST)
Received: from almso1.proxy.att.com (almso1.att.com [192.128.167.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18137
	for <nsis@ietf.org>; Mon, 21 Jan 2002 12:45:51 -0500 (EST)
Received: from attrh1i.attrh.att.com ([135.71.62.10])
	by almso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id g0LHjMW04079
	for <nsis@ietf.org>; Mon, 21 Jan 2002 12:45:22 -0500 (EST)
Received: from occlust04evs1.ugd.att.com (135.71.164.13) by attrh1i.attrh.att.com (5.5.029)
        id 3C0BA3A50024136E; Mon, 21 Jan 2002 12:44:58 -0500
content-class: urn:content-classes:message
Subject: RE: [NSIS] Support needed for Throughput Adaptive QoS in wireless
Date: Mon, 21 Jan 2002 12:44:59 -0500
Message-ID: <62DA45D4963FA747BA1B253E266760F90126C690@OCCLUST04EVS1.ugd.att.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Thread-Topic: [NSIS] Support needed for Throughput Adaptive QoS in wireless
Thread-Index: AcGigGNSh50z3g5wEda1uADgKSaxKgAIm/zw
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
From: "Roy, Radhika R, ALASO" <rrroy@att.com>
To: <john.loughney@nokia.com>, <Ruediger.Geib@t-systems.com>
Cc: <nsis@ietf.org>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id MAA20339
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, John:

I agree with you and like to add a little more [RRR].

Best regards,
Radhika

-----Original Message-----
From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]
Sent: Monday, January 21, 2002 8:25 AM
To: Ruediger.Geib@t-systems.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] Support needed for Throughput Adaptive QoS in
wireless


Hi all,

> >  I also think that the solution of over loading 
> >  should be managed by a local "higher hierarchy" 
> >  and not by the End-to-End reservation. This 
> >  local service controller should be aware of the 
> >  sessions, users, resources and commitments. 
> >  Hence could decide a "re-negotiation" or a drop.   
> 
> I'd favour adaptive applications also in the QoS case. 
> Network to user re-negotiation means more complexity and it 
> requires extra signalling. Leave it to the apps. A network 
> may overbook, if it is aware that most apps are adaptive. 
> This requires no extra procedures.

NSIS cannot insist on adaptive applications, that is out of
scope.  Perhaps we could think that an NSIS protocol
could support re-negotiation (and allow a user to insist
on no re-negotiaion - but this starts to get into policy).

[RRR] Negotiations and re-negotiations will also depend on wishes of the end users/points as well as the OQS availability in the lower layer (transport/network/physical) layers including the intermediate networks. NSIS will depend on the lower layers before the final acceptance is made. However, NSIS will not address the lower layer problems.

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 Jan 21 12:52: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 MAA18486
	for <nsis-archive@odin.ietf.org>; Mon, 21 Jan 2002 12:52:30 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id MAA20614
	for nsis-archive@odin.ietf.org; Mon, 21 Jan 2002 12:52: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 MAA20247;
	Mon, 21 Jan 2002 12:40: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 MAA20211
	for <nsis@optimus.ietf.org>; Mon, 21 Jan 2002 12:40:47 -0500 (EST)
Received: from ckmso1.proxy.att.com (ckmso1.att.com [12.20.58.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17986
	for <nsis@ietf.org>; Mon, 21 Jan 2002 12:40:42 -0500 (EST)
Received: from attrh1i.attrh.att.com ([135.71.62.10])
	by ckmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id g0LHeBZ17916
	for <nsis@ietf.org>; Mon, 21 Jan 2002 12:40:11 -0500 (EST)
Received: from occlust04evs1.ugd.att.com (135.71.164.13) by attrh1i.attrh.att.com (5.5.029)
        id 3C0BA3A500241180; Mon, 21 Jan 2002 12:39:18 -0500
content-class: urn:content-classes:message
Subject: RE: [NSIS] Two kinds of requirements
Date: Mon, 21 Jan 2002 12:39:18 -0500
Message-ID: <62DA45D4963FA747BA1B253E266760F90126C682@OCCLUST04EVS1.ugd.att.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Thread-Topic: [NSIS] Two kinds of requirements
Thread-Index: AcGiZDOdoTzaPw5QEda1uADgKSaxKgAPIyAw
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
From: "Roy, Radhika R, ALASO" <rrroy@att.com>
To: <dick.rr.knight@bt.com>, <schneider@tri.sbc.com>,
        <gkenward@nortelnetworks.com>, <john.loughney@nokia.com>,
        <brunner@ccrle.nec.de>, <ykahana@comgates.co.il>,
        <Ruediger.Geib@t-systems.com>
Cc: <nsis@ietf.org>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id MAA20212
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, Dick:

I understand what you are saying. Let me answer your questions.

1. End users (points) will be able to signal QOS on end-to-end basis (as you also pointed out). That is the charter of NSIS QOS.

2. Whether the said QOS will be accepted between the two end users is a different problem. For example, it depends on the wishes of the end users (application layer) and the lower (transport, network, physical) layers. In the network layer, there may be several intermediate network as well. We will not address the lower layer problems or the intermediate networks. We will depend on them before the final acceptance is made in the application layer between the two end users. (We can also look into the case how SIP QOS takes care of the lower layer problems.)

3. How items 1 and 2 interact is a challenge and we have to provide a pointer (if not standardized) how integrate between the NSIS QOS (application layer) and the lower layers can be done.

There are many ways to address all problems.

Best regards,
Radhika

-----Original Message-----
From: dick.rr.knight@bt.com [mailto:dick.rr.knight@bt.com]
Sent: Monday, January 21, 2002 5:10 AM
To: schneider@tri.sbc.com; Roy, Radhika R, ALASO;
gkenward@nortelnetworks.com; john.loughney@nokia.com;
brunner@ccrle.nec.de; ykahana@comgates.co.il;
Ruediger.Geib@t-systems.com; dick.rr.knight@bt.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements



I don't think you can do the session level QoS agreement soley between
end-users, and ignore the capabilities of the intermediate networks. Suppose
you negotiate the perfect QoS for an application, and then request a
reservation to the network, what happens when the network can fulfill the
reservation? Do you begin the session level negotiation again, and keep
going stepwise until you get to the highest possible QoS the network can
give you?
Or do you accept the highest level of QoS the network can provide and then
see if you can accept that for the session?

It is in my mind, for the above reasons, that you need a protocol that can
request QoS and that request can be processed and acted upon at both user
and network nodes. It cannot be limited to user-network nor user-user.

I do agree that it need not be processed on a per hop basis as it can
transverse a domain with a single QoS mechanism. That mechanism, be it
diffserv or intserv, PNNI, RSVP, or even over-provisioning, takes care of
the policing and the "path" establishment within the domain.


Dick

-----Original Message-----
From: Schneider, Marco [mailto:schneider@tri.sbc.com]
Sent: 18 January 2002 20:10
To: 'Roy, Radhika R, ALASO'; Gary Kenward; Loughney John (NRC/Helsinki);
brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
dick.rr.knight@bt.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


Hi Roy,

Below is the original text from your reponse to Gary Kenward. Hopefully the
context is clear.

"[Roy, Radhika R, ALARC]  I would say that it is the QOS needs of the
application (e.g., SIP-based VoIP) that the user likes to express (as
opposed to "service"). Similarly, instead of network services, we would say
network layer QOS services (e.g., RSVP, DiffServ, MPLS). We would develop
the end-to-end (application layer) QOS signaling protocol (say, NSIS QOS).
Now, there needs to have some kinds of standards how NSIS QOS will be mapped
over RSVP, DiffServ, MPLS, etc."

So by End-to-End you mean between directly between two "users". This is
session level signaling and I don't believe the signaling part is within the
scope of this working group. An application level QOS specification may be. 

After a session level agreement on QOS, the host/client/customer will need
to signal an actual reservation request to the network for the necessary QOS
agreed to at the session level. This is the protocol that we need to work
on. 

This approach is discussed in the SIP draft "SIP Extensions for Media
Authorization" (draft-ietf-sip-call-auth-03.txt) and the RAP draft
"Framework for session set-up with media authorization"
(draft-ietf-rap-session-auth-02.txt).

Marco Schneider

-----Original Message-----
From: Roy, Radhika R, ALASO [mailto:rrroy@att.com]
Sent: Friday, January 18, 2002 9:18 AM
To: Schneider, Marco; Gary Kenward; Loughney John (NRC/Helsinki);
brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
dick.rr.knight@bt.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


Defined below [RRR]

-----Original Message-----
From: Schneider, Marco [mailto:schneider@tri.sbc.com]
Sent: Thursday, January 17, 2002 8:47 PM
To: Roy, Radhika R, ALASO; Gary Kenward; Loughney John (NRC/Helsinki);
brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
dick.rr.knight@bt.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


Hi Roy,

Can you please define what you mean by "End-to-End Application Layer QOS
Signaling". Thanks.

[RRR] Suppose an user is initiation a SIP call to another user with audio,
video, and data. The use needs to express the needs of QOS for audio, video,
and data to another user. 

[RRR] The signaling mechanism that allows to express the QOS parameters of
audio, video, and data is termed as the "End-to-End Application Layer QOS
Signaling."

Marco Schneider

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



From daemon@optimus.ietf.org  Mon Jan 21 13:07: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 NAA19073
	for <nsis-archive@odin.ietf.org>; Mon, 21 Jan 2002 13:07:16 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id NAA21374
	for nsis-archive@odin.ietf.org; Mon, 21 Jan 2002 13:07: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 NAA21330;
	Mon, 21 Jan 2002 13:06: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 NAA21300
	for <nsis@optimus.ietf.org>; Mon, 21 Jan 2002 13:06:15 -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 NAA19012
	for <nsis@ietf.org>; Mon, 21 Jan 2002 13:06:11 -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 g0LI8HT01614;
	Mon, 21 Jan 2002 12:08:18 -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 g0LI5eM22225;
	Mon, 21 Jan 2002 12:05:40 -0600 (CST)
Received: by TRIMAIL2.ad.tri.sbc.com with Internet Mail Service (5.5.2653.19)
	id <ZND32TRV>; Mon, 21 Jan 2002 12:06:06 -0600
Message-ID: <905A1C4ABF353F4C8CC16FA9F53DD0D632242C@TRIMAIL2.ad.tri.sbc.com>
From: "Chen, Weijing" <wchen@tri.sbc.com>
To: "'dick.rr.knight@bt.com'" <dick.rr.knight@bt.com>,
        "Schneider, Marco"
	 <schneider@tri.sbc.com>
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements   (priority on the boundary 
	 b e tween a customer and the network)
Date: Mon, 21 Jan 2002 12:05:57 -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


--
Weijing Chen
SBC Technology Resources
9505 Arboretum Blvd.
Austin, TX 78759
512 372 5710
wchen@tri.sbc.com


 -----Original Message-----
From: 	dick.rr.knight@bt.com [mailto:dick.rr.knight@bt.com] 
Sent:	Monday, January 21, 2002 4:46 AM
To:	Chen, Weijing; Schneider, Marco
Cc:	nsis@ietf.org
Subject:	RE: [NSIS] Two kinds of requirements   (priority on the
boundary  b e tween a customer and the network)


I have a worry about this.

The "2" flow works as you have shown, but in reality a 
[edge]<---2---[hop]-->[edge]
is really
[edge][domain]<--2--[hop]-->[domain]  ...(cont next line)
<--2--[hop]-->[domain]<--2--[hop]-->[domain][edge]

where the flow

[domain]<--2--[hop]-->[domain]
implies a domain bounded by an interworking function and containing one or
more switching functions (i.e. at least a router or possibly a multiplexor
or switch etc.)

[wj] The inter-domain could use [host]-to-[edge] solution too. The receiving
domain is the [edge], and sending domain is the [host], and vice versa.

The inter-domain aspect is complex because of differing technology/QoS
solutions and the "who does the interworking" problems. If the interdomain
problem is solved by a standardised QoS request signalling protocol, then
this can be "mapped" down to the "2" flow you have shown.

This simplifies the interworking problem. Given a set of protocols, then the
requirement to interwork each protocol to all the others is a problem of
forever increasing complexity. If you interwork to a single generic protocol
then the interworking problem is 1x(NumProtocols). Every time you add a new
QoS mechanism, then the you only need one additional interworking solution.

[wj] If we accept the [host]-to-[edge] solution as inter-domain solution,
then the standard mapping will be every other protocol mapping to
[host]-to-[edge].


-----Original Message-----
From: Chen, Weijing [mailto:wchen@tri.sbc.com]
Sent: 18 January 2002 19:09
To: 'dick.rr.knight@bt.com'; Schneider, Marco
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements (priority on the boundary
b e tween a customer and the network)


Dick,

3 is more a function than a particular protocol or protocol component. Allow
me to illustrate the QoS service delivery chain with the diagram below:

[host]<--1--[hop]-->[edge]<---2---[hop]-->[edge]<--1--[hop]-->[host]

[host]<-------------------3----------------------------------------------->[
host]

a) The user locates the service provider or other subscriber(s) that he
wishes to contact.  The result of this step is that the subscriber will know
the network addresses of the other subscriber(s)) he wishes to contact, and
the QoS he wishes to use to contact them. (By SIP, SDP, DNS, web, or any
application level session protocol)
b) The user negotiates with the network to establish the desired
communications capabilities with the other subscriber(s). (By signaling
protocol 1)
c) The network internally allocates the resources to fulfill the
subscriber's request. (By signaling protocol 2 (e.g. PNNI, MPLS, RSVP, or
even over-provisioning) and mapping of QoS of 1 to QoS of 2)
d) The user authenticates with the other subscriber(s) and is authorized to
receive services from them. (By other security means)
e) The user then communicates with the other subscriber(s)) to receive
services. (By underline transport link reserved previously in step b and c.
)
f) At the conclusion of the session, billing information is recorded so the
subscriber can be billed for the network services.

Now 3 is the experience of the user who got QoS service from the network.
The actual protocols involved are 1 and 2. The 1 does not really go from
end-to-end, but from end-to-network, and network-to-end. The edge will do
the network-to-network. Again standardization of 1 to 2 QoS mapping is
debatable which I don't have an opinion yet.

--
Weijing Chen
SBC Technology Resources
9505 Arboretum Blvd.
Austin, TX 78759
512 372 5710
wchen@tri.sbc.com


 -----Original Message-----
From: 	dick.rr.knight@bt.com [mailto:dick.rr.knight@bt.com] 
Sent:	Friday, January 18, 2002 10:45 AM
To:	Chen, Weijing; dick.rr.knight@bt.com; Schneider, Marco;
Georgios.Karagiannis@eln.ericsson.se
Cc:	nsis@ietf.org
Subject:	RE: [NSIS] Two kinds of requirements  (priority on the
boundary b e tween a customer and the network)


There is something missing for me in your logic. What is 3?

I can better relate to the terminology of everyhop; everyedge; everyhost. Is
3 the everyhost bit?

-----Original Message-----
From: Chen, Weijing [mailto:wchen@tri.sbc.com]
Sent: 18 January 2002 16:12
To: 'dick.rr.knight@bt.com'; Schneider, Marco;
Georgios.Karagiannis@eln.ericsson.se
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements (priority on the boundary
be tween a customer and the network)


Sorry, previous picture is garbled by mailer. 


[host]<--1--[hop]-->[edge]<---2---[hop]-->[edge]<--1--[hop]-->[host]

[host]<-------------------3------------------------------------------------>
[host]


The 3 is our goal and is comprised of 1 and 2. As we know, there are
solutions for 2 (MPLS, DiffServ, PNNI, over-provisioning, etc). What we need
to solve is the 1.  Now what about translation (or mapping) between 1 and 2?
Do we need to standardize it?  If yes, where? In NSIS group or elsewhere?

Regardless, the objective of 1 is KISS and universal. The complexity of 1
and 2 mapping must be born by the [edge].



--
Weijing Chen
SBC Technology Resources
9505 Arboretum Blvd.
Austin, TX 78759
512 372 5710
wchen@tri.sbc.com



 -----Original Message-----
From: 	dick.rr.knight@bt.com [mailto:dick.rr.knight@bt.com] 
Sent:	Friday, January 18, 2002 5:12 AM
To:	Schneider, Marco; Georgios.Karagiannis@eln.ericsson.se;
dick.rr.knight@bt.com
Cc:	nsis@ietf.org
Subject:	RE: [NSIS] Two kinds of requirements (priority on the
boundary be tween a customer and the network)


I do not agree.

What is the point of completing the work enabling the customer to signal to
the network, if the network cannot signal between domains? The network can
never satisfy the request.

Dick

-----Original Message-----
From: Schneider, Marco [mailto:schneider@tri.sbc.com]
Sent: 18 January 2002 01:44
To: 'Georgios Karagiannis (ELN)'; 'dick.rr.knight@bt.com'
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


Hi Georgios,

While I agree NSIS could be used to support Interior to Interior (of one
carrier) or Edge to Core, I think that we need to prioritize on a signaling
protocol across the boundary between a customer and the network. Note that
the customer could be an individual, an ISP or another Carrier.

Marco Schneider

-----Original Message-----
From: Georgios Karagiannis (ELN)
[mailto:Georgios.Karagiannis@eln.ericsson.se]
Sent: Thursday, January 17, 2002 3:39 AM
To: 'dick.rr.knight@bt.com'
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


Hi Dick 

In principle I agree with your comment (see below).

[DK] >> To be more precise, I am suggesting a new protocol that is 
[DK] >> independent of the underlying transport technology and the QoS 
[DK] >> implemented and is also independent of the session control protocol.


However, a very important point here is that we need to 
specify a protocol that can be used independent of the underlying transport 
technology, but that can satisfy the QoS requirements imposed by these 
underlying transport technologies. Otherwise the protocol will not be
suitable
and useful.

A way of achieving this is by first creating a modular QoS signaling toolkit

that will contain mandatory and optional QoS requirements;
Second, specify how the protocol functionality should be separated in 
building blocks (protocol components) and define a minimum set 
of mandatory reservation options/features that should be 
processed by any network nodes, e.g., end-hosts,
proxies, edges and interior nodes.
An example of such a protocol decomposition is given below!
In this way each node will only process (check and use) the protocol 
components of interest.


|---------|
|---------|
|everyhost|<------------------------------------------------------->|everyho
st|
|---------|
|---------|
|         |                                                         |
|
|---------|   |---------|                             |---------|
|---------|
|everyedge|<->|everyedge|<--------------------------->|everyedge|<->|everyed
ge|
|---------|   |---------|                             |---------|
|---------|
|         |   |         |                             |         |   |
|
|---------|   |---------|   |--------|   |--------|   |---------|
|---------|
|everyhop |<->|everyhop |<->|everyhop|<->|everyhop|<->|everyhop
|<->|everyhop |
|---------|   |---------|   |--------|   |--------|   |---------|
|---------| 
    host          edge        interior    interior       edge          host


  NSIS protocol decomposition (building blocks): 
 *  "everyhost", "everyedge" and "everyhop" are protocol components;
 *  host: can be an end-host or a proxy and it can process and use the
"everyhost", 
    "everyedge", and "everyhop" protocol components;

 *  edge: can be a Diffserv edge, MPLS edge, etc., and it can process and
use 
    the "everyedge", and "everyhop" protocol components. The "everyhost" 
    protocol component is not processed (used or checked);

 *  interior: can be any router within a domain and it can process and use 
    only the "everyhop" protocol component.
    The "everyhost" and "everyedge" protocol components are not 
    processed (used or checked);


Best Regards,
Georgios

-----Original Message-----
From: dick.rr.knight@bt.com [mailto:dick.rr.knight@bt.com]
Sent: woensdag 16 januari 2002 13:00
To: brian.williams@ericsson.com.au; lieve.bos@alcatel.be
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


I was waiting for some reaction to Brian's comments, but as there aren't
any, here are my thoughts on the requirements:

I agree with the analysis that discussion has been based around
application-related signalling for QoS (at session level) and QoS signalling
protocols used to actually provision the QoS at the transport level.
Brian is right that there will never be an enhancement to a single session
protocol that will satisfy all applications.
However, for similar reasons, it is never going to be possible to prescribe
a single QoS mechanism to be used in all networks. Existing networks (or
domains) will not be changed overnight and new networks already face several
workable mechanisms to deploy QoS.

I think that what is needed is a new protocol that can signal the
requirements of any session and can be satisfied by any QoS mechanism,
existing or new.
To be more precise, I am suggesting a new protocol that is independent of
the underlying transport technology and the QoS implemented and is also
independent of the session control protocol. Such a new protocol would be
generic, optionally implemented by applications that would benefit from
end-to-end QoS, and would be complimentary to the QoS mechanisms deployed
(and of course other mechanisms, such as the routing).

I think that this implies a more abstract definition of the QoS mechanism
and may lend itself to the signalling of pre-defined QoS classes rather than
parameters.

Dick Knight

-----Original Message-----
From: Brian Williams [mailto:brian.williams@ericsson.com.au]
Sent: 22 December 2001 23:57
To: lieve.bos@alcatel.be
Cc: nsis@ietf.org
Subject: Re: [NSIS] Two kinds of requirements


Hi.
While the two types of signalling may be related, I think there is a
need to develop a QoS bearer mechanism which is independent of any
specific session signalling, and thus can be used for any application. I
believe many of the applications which have identified requirements to
the working group have their own specific session layer signalling (ie
it is not end-to-end SIP).  

Having the session and transport protocols developed separately of
course does not prohibit the two being used in conjunction for a
specific application.
/brian
 
On Fri, 2001-12-21 at 22:24, lieve.bos@alcatel.be wrote:
> Hello all,
> 
> >From the discussion in Salt Lake city and the drafts submitted, one can
> easily see that people are suggesting improvements to QoS signalling at
> two totally different levels (some at session level and some at
> transport level).
> 
> First of all, there are drafts suggesting some improvements in the
> session setup procedures (i.e. the ability to negotiate the preferred
> QoS level between end users during SDP negotiation in SIP, so before the
> actual resources are being setup). The QoS information negotiated at the
> session layer determines the QoS level both endusers have to use for 
> their local access connection. This first kind of 'session level QoS
> negotiation' happens end-to-end between the two end-users.
> 
> Secondly, there are drafts suggesting that we need
> improvements/alternatives for the QoS signalling protocols (e.g. RSVP)
> used to actually provision the QoS at the transport level between two
> endusers. This second kind of 'transport level QoS signalling' can
> consist of several phases: end-to-edge and edge-to-edge. 
> 
> It's important that everybody realises that, in order to give endusers
> true end-to-end Quality of Service, we need improvements for QoS both at
> session and transport level. Also its important to understand that they
> are not uncorrelated. Providers want to be able to control (e.g. via
> policy control mechanisms) that the QoS requested at the transport level
> is not exceeding the QoS negotiated/authorised previously at session
> level. So, what about developing in NSIS a modular framework
> incorporating both session and transport level QoS signalling with
> possible hooks between the two layers (e.g. for policy enforcement).
> 
> Lieve
> 
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis



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

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

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

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

_______________________________________________
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 Jan 21 13:10:27 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19115
	for <nsis-archive@odin.ietf.org>; Mon, 21 Jan 2002 13:10:27 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id NAA21453
	for nsis-archive@odin.ietf.org; Mon, 21 Jan 2002 13:10: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 NAA21149;
	Mon, 21 Jan 2002 13:01: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 NAA21086
	for <nsis@optimus.ietf.org>; Mon, 21 Jan 2002 13:01:03 -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 NAA18760
	for <nsis@ietf.org>; Mon, 21 Jan 2002 13:01:00 -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 g0LI37T01565;
	Mon, 21 Jan 2002 12:03:08 -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 g0LI0TE22061;
	Mon, 21 Jan 2002 12:00:30 -0600 (CST)
Received: by TRIMAIL2.ad.tri.sbc.com with Internet Mail Service (5.5.2653.19)
	id <ZND32TQY>; Mon, 21 Jan 2002 12:00:56 -0600
Message-ID: <905A1C4ABF353F4C8CC16FA9F53DD0D632242B@TRIMAIL2.ad.tri.sbc.com>
From: "Chen, Weijing" <wchen@tri.sbc.com>
To: "'dick.rr.knight@bt.com'" <dick.rr.knight@bt.com>,
        Georgios.Karagiannis@eln.ericsson.se
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements
Date: Mon, 21 Jan 2002 12:00:46 -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

Dick:  "If the user-network interface is one protocol and then the next hop
is RSVP
with intserv,
then the next is MPLS with LSP and so on, will you see anything at the far
and distant end
that looks anything like the original user-network request?"

To solve this problem, one simple way is every hops involved preserving the
original QoS sent by the user and passing to final distant end.

Again, it is always much difficult to argue against some points as "too
much" than "too little". But in the business arena, "too much" causes same
problem as "too little". They both yields non-workable situations.

--
Weijing Chen
SBC Technology Resources
9505 Arboretum Blvd.
Austin, TX 78759
512 372 5710
wchen@tri.sbc.com


 -----Original Message-----
From: 	dick.rr.knight@bt.com [mailto:dick.rr.knight@bt.com] 
Sent:	Monday, January 21, 2002 11:15 AM
To:	Chen, Weijing; Georgios.Karagiannis@eln.ericsson.se
Cc:	nsis@ietf.org
Subject:	RE: [NSIS] Two kinds of requirements

Weijing,

I can understand your desire to concentrate on the user-network problem
space.

However - I am concerned that the result will be an agreed and working
solution
in this problem space that is then not supported at the network-network
interface
(interdomain in IP speak, NNI in PSTN jargon).

If the user-network interface is one protocol and then the next hop is RSVP
with intserv,
then the next is MPLS with LSP and so on, will you see anything at the far
and distant end
that looks anything like the original user-network request?

Dick

-----Original Message-----
From: Chen, Weijing [mailto:wchen@tri.sbc.com]
Sent: 21 January 2002 16:20
To: 'Georgios Karagiannis (ELN)'
Cc: 'nsis@ietf.org'
Subject: RE: [NSIS] Two kinds of requirements


I am afraid that we are creating a Utopian solution here.

>>Therefore, the [everyhop] component should be supported by the NSIS
protocol.
>>However a "host" or a "edge" should be able to activated or not.

It is not question of who activate it. It is the question of who initiate
it. Who is going to stuff the [everyhop] component into signaling message?
Don't expect it from [end host].

>>Furthermore, in my opinion the NSIS protocol should be:
>>end host - end host: the NSIS protocol is terminated at end hosts;
>>end host - proxy: the NSIS protocol is terminated at end host and proxy;

>>end host - edge: the NSIS protocol is terminated at end end host and edge;
This should be our focus now.

>>edge - edge: the NSIS protocol is terminated at egdes of one/multiple
domains;

Yes, a universal protocol used by different segments is very nice. But can
it be agreed on and implementable? The missing piece in today's protocol
soup is user-to-network signaling, sort of DTMF in data world. Let's solve
it first here in NSIS. Later on we can engage on a more ambition mission.

--
Weijing Chen
SBC Technology Resources
9505 Arboretum Blvd.
Austin, TX 78759
512 372 5710
wchen@tri.sbc.com

-----Original Message-----
From: 	Georgios Karagiannis (ELN)
[mailto:Georgios.Karagiannis@eln.ericsson.se] 
Sent:	Monday, January 21, 2002 4:30 AM
To:	'dick.rr.knight@bt.com'
Cc:	nsis@ietf.org
Subject:	RE: [NSIS] Two kinds of requirements


Hi Dick

Please see my comment in line:
[DK]>> I do agree that it need not be processed on a per hop basis as it can
[DK]>> transverse a domain with a single QoS mechanism. That mechanism, be
it
[DK]>> diffserv or intserv, PNNI, RSVP, or even over-provisioning, takes
care of
[DK]>> the policing and the "path" establishment within the domain.

Please note that at the moment there are scenarios that will need to 
process the [everyhop] component. Some of these scenarios are the Radio
Access
Network and Mobile IP,..
Therefore, the [everyhop] component should be supported by the NSIS
protocol.
However a "host" or a "edge" should be able to activated or not.

Furthermore, in my opinion the NSIS protocol should be:
end host - end host: the NSIS protocol is terminated at end hosts;
end host - proxy: the NSIS protocol is terminated at end host and proxy;
end host - edge: the NSIS protocol is terminated at end end host and edge;
edge - edge: the NSIS protocol is terminated at egdes of one/multiple
domains;


Best regards,
Georgios


-----Original Message-----
From: Schneider, Marco [mailto:schneider@tri.sbc.com]
Sent: 18 January 2002 20:10
To: 'Roy, Radhika R, ALASO'; Gary Kenward; Loughney John (NRC/Helsinki);
brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
dick.rr.knight@bt.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


Hi Roy,

Below is the original text from your reponse to Gary Kenward. Hopefully the
context is clear.

"[Roy, Radhika R, ALARC]  I would say that it is the QOS needs of the
application (e.g., SIP-based VoIP) that the user likes to express (as
opposed to "service"). Similarly, instead of network services, we would say
network layer QOS services (e.g., RSVP, DiffServ, MPLS). We would develop
the end-to-end (application layer) QOS signaling protocol (say, NSIS QOS).
Now, there needs to have some kinds of standards how NSIS QOS will be mapped
over RSVP, DiffServ, MPLS, etc."

So by End-to-End you mean between directly between two "users". This is
session level signaling and I don't believe the signaling part is within the
scope of this working group. An application level QOS specification may be. 

After a session level agreement on QOS, the host/client/customer will need
to signal an actual reservation request to the network for the necessary QOS
agreed to at the session level. This is the protocol that we need to work
on. 

This approach is discussed in the SIP draft "SIP Extensions for Media
Authorization" (draft-ietf-sip-call-auth-03.txt) and the RAP draft
"Framework for session set-up with media authorization"
(draft-ietf-rap-session-auth-02.txt).

Marco Schneider

-----Original Message-----
From: Roy, Radhika R, ALASO [mailto:rrroy@att.com]
Sent: Friday, January 18, 2002 9:18 AM
To: Schneider, Marco; Gary Kenward; Loughney John (NRC/Helsinki);
brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
dick.rr.knight@bt.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


Defined below [RRR]

-----Original Message-----
From: Schneider, Marco [mailto:schneider@tri.sbc.com]
Sent: Thursday, January 17, 2002 8:47 PM
To: Roy, Radhika R, ALASO; Gary Kenward; Loughney John (NRC/Helsinki);
brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
dick.rr.knight@bt.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


Hi Roy,

Can you please define what you mean by "End-to-End Application Layer QOS
Signaling". Thanks.

[RRR] Suppose an user is initiation a SIP call to another user with audio,
video, and data. The use needs to express the needs of QOS for audio, video,
and data to another user. 

[RRR] The signaling mechanism that allows to express the QOS parameters of
audio, video, and data is termed as the "End-to-End Application Layer QOS
Signaling."

Marco Schneider

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

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

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

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



From daemon@optimus.ietf.org  Mon Jan 21 14:17: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 OAA20596
	for <nsis-archive@odin.ietf.org>; Mon, 21 Jan 2002 14:17:39 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id OAA23785
	for nsis-archive@odin.ietf.org; Mon, 21 Jan 2002 14:17: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 OAA23635;
	Mon, 21 Jan 2002 14:07: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 OAA23603
	for <nsis@optimus.ietf.org>; Mon, 21 Jan 2002 14:07:25 -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 OAA20242
	for <nsis@ietf.org>; Mon, 21 Jan 2002 14:07:22 -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 g0LJ9TT02005
	for <nsis@ietf.org>; Mon, 21 Jan 2002 13:09:29 -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 g0LJ6p024533
	for <nsis@ietf.org>; Mon, 21 Jan 2002 13:06:52 -0600 (CST)
Received: by TRIMAIL2.ad.tri.sbc.com with Internet Mail Service (5.5.2653.19)
	id <ZND32T6K>; Mon, 21 Jan 2002 13:07:18 -0600
Message-ID: <905A1C4ABF353F4C8CC16FA9F53DD0D62A6FF8@TRIMAIL2.ad.tri.sbc.com>
From: "Allen, Keith" <kallen@tri.sbc.com>
To: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements
Date: Mon, 21 Jan 2002 13:07:16 -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

All,

Along the lines of my earlier reference to Use Cases, what do you think
about beginning to document the requirements the protocol should meet as a
set of use cases describing how network users (or actually their network
devices) use the protocol-to-be to access the QoS capabilities of the
network.  For example, one use case could show a voice over IP caller,
another a network administrator setting up an Ethernet VPN, etc.  If the
protocol has to support mobile handoffs, we would have a use case showing
that.  It would give us a focal point instead of just e-mail.


Keith Allen
SBC Technology Resources
9505 Arboretum Blvd.
Austin, TX 78759
(512) 372-5741
kallen@tri.sbc.com

 -----Original Message-----
From: 	Allen, Keith  
Sent:	Monday, January 21, 2002 11:37 AM
To:	nsis@ietf.org
Subject:	RE: [NSIS] Two kinds of requirements

Should the design of the protocol be driven by the needs of the user or the
currently implemented network?  If we choose the latter we will end up with
a protocol that will be obsolete when the next new network innovation takes
place, and it may not meet the basic needs of the subscriber.

The Object-Oriented software world has turned to user-centric requirements
(in the form of Use Cases) as the basis for analysis and design.  They are
getting good results with this process.  We should also focus on what the
user wants to do.  The user sends a request to the network, then he doesn't
care what the network has to do to meet it.  If it turns out that RSVP can't
meet the needs of the subscriber it will have to evolve or be replaced.
Unfortunately, though, we don't even know if RSVP will suffice because we
haven't captured what the user can do.

Form follows function.  The function of this protocol should be to enable
subscribers to utilize the guaranteed QoS capabilities of the network on
demand. 


Keith Allen
SBC Technology Resources
9505 Arboretum Blvd.
Austin, TX 78759
(512) 372-5741
kallen@tri.sbc.com

 -----Original Message-----
From: 	dick.rr.knight@bt.com [mailto:dick.rr.knight@bt.com] 
Sent:	Monday, January 21, 2002 11:15 AM
To:	Chen, Weijing; Georgios.Karagiannis@eln.ericsson.se
Cc:	nsis@ietf.org
Subject:	RE: [NSIS] Two kinds of requirements

Weijing,

I can understand your desire to concentrate on the user-network problem
space.

However - I am concerned that the result will be an agreed and working
solution
in this problem space that is then not supported at the network-network
interface
(interdomain in IP speak, NNI in PSTN jargon).

If the user-network interface is one protocol and then the next hop is RSVP
with intserv,
then the next is MPLS with LSP and so on, will you see anything at the far
and distant end
that looks anything like the original user-network request?

Dick

-----Original Message-----
From: Chen, Weijing [mailto:wchen@tri.sbc.com]
Sent: 21 January 2002 16:20
To: 'Georgios Karagiannis (ELN)'
Cc: 'nsis@ietf.org'
Subject: RE: [NSIS] Two kinds of requirements


I am afraid that we are creating a Utopian solution here.

>>Therefore, the [everyhop] component should be supported by the NSIS
protocol.
>>However a "host" or a "edge" should be able to activated or not.

It is not question of who activate it. It is the question of who initiate
it. Who is going to stuff the [everyhop] component into signaling message?
Don't expect it from [end host].

>>Furthermore, in my opinion the NSIS protocol should be:
>>end host - end host: the NSIS protocol is terminated at end hosts;
>>end host - proxy: the NSIS protocol is terminated at end host and proxy;

>>end host - edge: the NSIS protocol is terminated at end end host and edge;
This should be our focus now.

>>edge - edge: the NSIS protocol is terminated at egdes of one/multiple
domains;

Yes, a universal protocol used by different segments is very nice. But can
it be agreed on and implementable? The missing piece in today's protocol
soup is user-to-network signaling, sort of DTMF in data world. Let's solve
it first here in NSIS. Later on we can engage on a more ambition mission.

--
Weijing Chen
SBC Technology Resources
9505 Arboretum Blvd.
Austin, TX 78759
512 372 5710
wchen@tri.sbc.com

-----Original Message-----
From: 	Georgios Karagiannis (ELN)
[mailto:Georgios.Karagiannis@eln.ericsson.se] 
Sent:	Monday, January 21, 2002 4:30 AM
To:	'dick.rr.knight@bt.com'
Cc:	nsis@ietf.org
Subject:	RE: [NSIS] Two kinds of requirements


Hi Dick

Please see my comment in line:
[DK]>> I do agree that it need not be processed on a per hop basis as it can
[DK]>> transverse a domain with a single QoS mechanism. That mechanism, be
it
[DK]>> diffserv or intserv, PNNI, RSVP, or even over-provisioning, takes
care of
[DK]>> the policing and the "path" establishment within the domain.

Please note that at the moment there are scenarios that will need to 
process the [everyhop] component. Some of these scenarios are the Radio
Access
Network and Mobile IP,..
Therefore, the [everyhop] component should be supported by the NSIS
protocol.
However a "host" or a "edge" should be able to activated or not.

Furthermore, in my opinion the NSIS protocol should be:
end host - end host: the NSIS protocol is terminated at end hosts;
end host - proxy: the NSIS protocol is terminated at end host and proxy;
end host - edge: the NSIS protocol is terminated at end end host and edge;
edge - edge: the NSIS protocol is terminated at egdes of one/multiple
domains;


Best regards,
Georgios


-----Original Message-----
From: Schneider, Marco [mailto:schneider@tri.sbc.com]
Sent: 18 January 2002 20:10
To: 'Roy, Radhika R, ALASO'; Gary Kenward; Loughney John (NRC/Helsinki);
brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
dick.rr.knight@bt.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


Hi Roy,

Below is the original text from your reponse to Gary Kenward. Hopefully the
context is clear.

"[Roy, Radhika R, ALARC]  I would say that it is the QOS needs of the
application (e.g., SIP-based VoIP) that the user likes to express (as
opposed to "service"). Similarly, instead of network services, we would say
network layer QOS services (e.g., RSVP, DiffServ, MPLS). We would develop
the end-to-end (application layer) QOS signaling protocol (say, NSIS QOS).
Now, there needs to have some kinds of standards how NSIS QOS will be mapped
over RSVP, DiffServ, MPLS, etc."

So by End-to-End you mean between directly between two "users". This is
session level signaling and I don't believe the signaling part is within the
scope of this working group. An application level QOS specification may be. 

After a session level agreement on QOS, the host/client/customer will need
to signal an actual reservation request to the network for the necessary QOS
agreed to at the session level. This is the protocol that we need to work
on. 

This approach is discussed in the SIP draft "SIP Extensions for Media
Authorization" (draft-ietf-sip-call-auth-03.txt) and the RAP draft
"Framework for session set-up with media authorization"
(draft-ietf-rap-session-auth-02.txt).

Marco Schneider

-----Original Message-----
From: Roy, Radhika R, ALASO [mailto:rrroy@att.com]
Sent: Friday, January 18, 2002 9:18 AM
To: Schneider, Marco; Gary Kenward; Loughney John (NRC/Helsinki);
brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
dick.rr.knight@bt.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


Defined below [RRR]

-----Original Message-----
From: Schneider, Marco [mailto:schneider@tri.sbc.com]
Sent: Thursday, January 17, 2002 8:47 PM
To: Roy, Radhika R, ALASO; Gary Kenward; Loughney John (NRC/Helsinki);
brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
dick.rr.knight@bt.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


Hi Roy,

Can you please define what you mean by "End-to-End Application Layer QOS
Signaling". Thanks.

[RRR] Suppose an user is initiation a SIP call to another user with audio,
video, and data. The use needs to express the needs of QOS for audio, video,
and data to another user. 

[RRR] The signaling mechanism that allows to express the QOS parameters of
audio, video, and data is termed as the "End-to-End Application Layer QOS
Signaling."

Marco Schneider

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

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

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

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

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

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



From daemon@optimus.ietf.org  Mon Jan 21 15:40: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 PAA23461
	for <nsis-archive@odin.ietf.org>; Mon, 21 Jan 2002 15:40:05 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id PAA26584
	for nsis-archive@odin.ietf.org; Mon, 21 Jan 2002 15:40: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 PAA25954;
	Mon, 21 Jan 2002 15:24: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 PAA25931
	for <nsis@optimus.ietf.org>; Mon, 21 Jan 2002 15:24:44 -0500 (EST)
Received: from picard.ee.ucl.ac.uk (picard.ee.ucl.ac.uk [128.40.42.82])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22885
	for <nsis@ietf.org>; Mon, 21 Jan 2002 15:24:35 -0500 (EST)
Received: from dipsy.ee.ucl.ac.uk (dipsy [128.40.42.35])
	by picard.ee.ucl.ac.uk (8.10.2+Sun/8.10.2) with ESMTP id g0LKNoO17589;
	Mon, 21 Jan 2002 20:23:50 GMT
Message-Id: <5.1.0.14.0.20020121200343.06a67b60@pop1.ee.ucl.ac.uk>
X-Sender: hdemeer@pop1.ee.ucl.ac.uk
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Mon, 21 Jan 2002 20:16:35 +0000
To: "Geib, Ruediger" <Ruediger.Geib@t-systems.com>, ykahana@comgates.co.il,
        gkenward@nortelnetworks.com, dick.rr.knight@bt.com,
        gilbert@rsch.comm.mot.com
From: Hermann De Meer <h.demeer@ee.ucl.ac.uk>
Subject: RE: [NSIS] Support needed for Throughput Adaptive QoS in
  wireless
Cc: nsis@ietf.org
In-Reply-To: <DFD875E85664D3118FA6080006277DE70362C82D@U8PN2>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id PAA25932
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,
Georgios,

At 10:15 21/01/2002 +0100, Geib, Ruediger wrote:
> >  I also think that the solution of over loading
> >  should be managed by a local "higher hierarchy"
> >  and not by the End-to-End reservation. This
> >  local service controller should be aware of the
> >  sessions, users, resources and commitments.
> >  Hence could decide a "re-negotiation" or a drop.
>
>I'd favour adaptive applications also in the QoS case. Network to user 
>re-negotiation means more complexity and it requires extra signalling. 
>Leave it to the apps. A network may overbook, if it is aware that most 
>apps are adaptive. This requires no extra procedures.

I tend to agree ...


>Two further arguments:
>- Plain old telephony used a compression scheme
>   to save transatlantic capacity during high
>   congestion (called DCME). No user was
>   aware of that. The only extra signalling
>   occured  between DCME units.

this is a good observation!
what it needs, however, from the signalling side is congestion 
indication/notification.
Now this is something that has traditionally been ignored within QoS 
architectures
and would be very useful  to be incorporated within NSIS, therefore.

more generally, as pointed out by Georgios, this can be referred to as QoS 
violation signalling:
network to network or network to edge/host etc.

extending Georgios' view:
- it may as well be required in wired network segments (not only in 
wireless segments)
- does not only apply to individual flows but also to whole aggregates in 
the DiffServ sense,
   for example.

Please note, this does not necessarily mean re-negotiation.

Regards,
Hermann



>- Say you support re-negotiation. Your cell
>   supports 10 QoS reservations and the ten
>   of them are used. Number 11 wants to enter
>   and triggers a re-negotiation. Do you
>   re-negotiate all of the ten existing
>   reservations? Only one? If so, how do you
>   decide on the candidate in a fair way?
>
>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@ns.ietf.org  Mon Jan 21 18:44: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 SAA28262
	for <nsis-archive@odin.ietf.org>; Mon, 21 Jan 2002 18:44:49 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id SAA02303
	for nsis-archive@odin.ietf.org; Mon, 21 Jan 2002 18:44: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 SAA02049;
	Mon, 21 Jan 2002 18:34: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 SAA01981
	for <nsis@ns.ietf.org>; Mon, 21 Jan 2002 18:34:01 -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 SAA28146
	for <nsis@ietf.org>; Mon, 21 Jan 2002 18:33:11 -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 g0LNZKT03998;
	Mon, 21 Jan 2002 17:35:20 -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 g0LNWfc00688;
	Mon, 21 Jan 2002 17:32:41 -0600 (CST)
Received: by TRIMAIL2.ad.tri.sbc.com with Internet Mail Service (5.5.2653.19)
	id <ZND32VLK>; Mon, 21 Jan 2002 17:33:07 -0600
Message-ID: <905A1C4ABF353F4C8CC16FA9F53DD0D638B9A4@TRIMAIL2.ad.tri.sbc.com>
From: "Schneider, Marco" <schneider@tri.sbc.com>
To: "'dick.rr.knight@bt.com'" <dick.rr.knight@bt.com>, rrroy@att.com,
        gkenward@nortelnetworks.com, john.loughney@nokia.com,
        brunner@ccrle.nec.de, ykahana@comgates.co.il,
        Ruediger.Geib@t-systems.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements
Date: Mon, 21 Jan 2002 17:32:58 -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

Dick,

In your example below the session participants can agree upon what they
prefer and what is acceptable. In other words, an ordered set of QOS
preferences. So if the network cannot fulfull the first preference it
attempts to fill the second and so on. If none of the preferences can be
filled then the session fails. The semantics of the session is: I want a
connection with at least this QOS or I don't want it all. Note that the "at
least this QOS" could be best effort.

Marco

-----Original Message-----
From: dick.rr.knight@bt.com [mailto:dick.rr.knight@bt.com]
Sent: Monday, January 21, 2002 4:10 AM
To: Schneider, Marco; rrroy@att.com; gkenward@nortelnetworks.com;
john.loughney@nokia.com; brunner@ccrle.nec.de; ykahana@comgates.co.il;
Ruediger.Geib@t-systems.com; dick.rr.knight@bt.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements



I don't think you can do the session level QoS agreement soley between
end-users, and ignore the capabilities of the intermediate networks. Suppose
you negotiate the perfect QoS for an application, and then request a
reservation to the network, what happens when the network can fulfill the
reservation? Do you begin the session level negotiation again, and keep
going stepwise until you get to the highest possible QoS the network can
give you?
Or do you accept the highest level of QoS the network can provide and then
see if you can accept that for the session?

It is in my mind, for the above reasons, that you need a protocol that can
request QoS and that request can be processed and acted upon at both user
and network nodes. It cannot be limited to user-network nor user-user.

I do agree that it need not be processed on a per hop basis as it can
transverse a domain with a single QoS mechanism. That mechanism, be it
diffserv or intserv, PNNI, RSVP, or even over-provisioning, takes care of
the policing and the "path" establishment within the domain.


Dick

-----Original Message-----
From: Schneider, Marco [mailto:schneider@tri.sbc.com]
Sent: 18 January 2002 20:10
To: 'Roy, Radhika R, ALASO'; Gary Kenward; Loughney John (NRC/Helsinki);
brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
dick.rr.knight@bt.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


Hi Roy,

Below is the original text from your reponse to Gary Kenward. Hopefully the
context is clear.

"[Roy, Radhika R, ALARC]  I would say that it is the QOS needs of the
application (e.g., SIP-based VoIP) that the user likes to express (as
opposed to "service"). Similarly, instead of network services, we would say
network layer QOS services (e.g., RSVP, DiffServ, MPLS). We would develop
the end-to-end (application layer) QOS signaling protocol (say, NSIS QOS).
Now, there needs to have some kinds of standards how NSIS QOS will be mapped
over RSVP, DiffServ, MPLS, etc."

So by End-to-End you mean between directly between two "users". This is
session level signaling and I don't believe the signaling part is within the
scope of this working group. An application level QOS specification may be. 

After a session level agreement on QOS, the host/client/customer will need
to signal an actual reservation request to the network for the necessary QOS
agreed to at the session level. This is the protocol that we need to work
on. 

This approach is discussed in the SIP draft "SIP Extensions for Media
Authorization" (draft-ietf-sip-call-auth-03.txt) and the RAP draft
"Framework for session set-up with media authorization"
(draft-ietf-rap-session-auth-02.txt).

Marco Schneider

-----Original Message-----
From: Roy, Radhika R, ALASO [mailto:rrroy@att.com]
Sent: Friday, January 18, 2002 9:18 AM
To: Schneider, Marco; Gary Kenward; Loughney John (NRC/Helsinki);
brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
dick.rr.knight@bt.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


Defined below [RRR]

-----Original Message-----
From: Schneider, Marco [mailto:schneider@tri.sbc.com]
Sent: Thursday, January 17, 2002 8:47 PM
To: Roy, Radhika R, ALASO; Gary Kenward; Loughney John (NRC/Helsinki);
brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
dick.rr.knight@bt.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


Hi Roy,

Can you please define what you mean by "End-to-End Application Layer QOS
Signaling". Thanks.

[RRR] Suppose an user is initiation a SIP call to another user with audio,
video, and data. The use needs to express the needs of QOS for audio, video,
and data to another user. 

[RRR] The signaling mechanism that allows to express the QOS parameters of
audio, video, and data is termed as the "End-to-End Application Layer QOS
Signaling."

Marco Schneider

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



From daemon@ns.ietf.org  Mon Jan 21 19: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 TAA28665
	for <nsis-archive@odin.ietf.org>; Mon, 21 Jan 2002 19:12:25 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id TAA03387
	for nsis-archive@odin.ietf.org; Mon, 21 Jan 2002 19: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 TAA03176;
	Mon, 21 Jan 2002 19:03: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 TAA03149
	for <nsis@ns.ietf.org>; Mon, 21 Jan 2002 19:03:21 -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 TAA28570
	for <nsis@ietf.org>; Mon, 21 Jan 2002 19:03:18 -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 g0M05QT04156;
	Mon, 21 Jan 2002 18:05:26 -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 g0M02gp02793;
	Mon, 21 Jan 2002 18:02:42 -0600 (CST)
Received: by TRIMAIL2.ad.tri.sbc.com with Internet Mail Service (5.5.2653.19)
	id <ZND32VPK>; Mon, 21 Jan 2002 18:03:08 -0600
Message-ID: <905A1C4ABF353F4C8CC16FA9F53DD0D638B9A5@TRIMAIL2.ad.tri.sbc.com>
From: "Schneider, Marco" <schneider@tri.sbc.com>
To: "'Georgios Karagiannis (ELN)'" <Georgios.Karagiannis@eln.ericsson.se>,
        "'dick.rr.knight@bt.com'" <dick.rr.knight@bt.com>
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements
Date: Mon, 21 Jan 2002 18:03:00 -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 Georgios, All

If by x -- y you mean a protocol that runs directly between x and y (e.g.
end host -- end host, end host -- proxy...) then strictly speaking we are
discussing four  functionally distinct interfaces and thus four functionally
distinct protocols(possibly three if we group end host -- proxy and  end
host -- edge together). In my opinion: First we need to decide which of
these interfaces are in scope. Second we need to decide which one(s) we will
address first. Third we need to define the requirements for each for each of
the interfaces independently. 

With respect to scope and priority, I think we need to address in order:
1) end host -- edge/proxy
2) domain edge -- domain edge

 
Marco


-----Original Message-----
From: Georgios Karagiannis (ELN)
[mailto:Georgios.Karagiannis@eln.ericsson.se]
Sent: Monday, January 21, 2002 4:30 AM
To: 'dick.rr.knight@bt.com'
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements



Hi Dick

Please see my comment in line:
[DK]>> I do agree that it need not be processed on a per hop basis as it can
[DK]>> transverse a domain with a single QoS mechanism. That mechanism, be
it
[DK]>> diffserv or intserv, PNNI, RSVP, or even over-provisioning, takes
care of
[DK]>> the policing and the "path" establishment within the domain.

Please note that at the moment there are scenarios that will need to 
process the [everyhop] component. Some of these scenarios are the Radio
Access
Network and Mobile IP,..
Therefore, the [everyhop] component should be supported by the NSIS
protocol.
However a "host" or a "edge" should be able to activated or not.

Furthermore, in my opinion the NSIS protocol should be:
end host - end host: the NSIS protocol is terminated at end hosts;
end host - proxy: the NSIS protocol is terminated at end host and proxy;
end host - edge: the NSIS protocol is terminated at end end host and edge;
edge - edge: the NSIS protocol is terminated at egdes of one/multiple
domains;


Best regards,
Georgios


-----Original Message-----
From: Schneider, Marco [mailto:schneider@tri.sbc.com]
Sent: 18 January 2002 20:10
To: 'Roy, Radhika R, ALASO'; Gary Kenward; Loughney John (NRC/Helsinki);
brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
dick.rr.knight@bt.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


Hi Roy,

Below is the original text from your reponse to Gary Kenward. Hopefully the
context is clear.

"[Roy, Radhika R, ALARC]  I would say that it is the QOS needs of the
application (e.g., SIP-based VoIP) that the user likes to express (as
opposed to "service"). Similarly, instead of network services, we would say
network layer QOS services (e.g., RSVP, DiffServ, MPLS). We would develop
the end-to-end (application layer) QOS signaling protocol (say, NSIS QOS).
Now, there needs to have some kinds of standards how NSIS QOS will be mapped
over RSVP, DiffServ, MPLS, etc."

So by End-to-End you mean between directly between two "users". This is
session level signaling and I don't believe the signaling part is within the
scope of this working group. An application level QOS specification may be. 

After a session level agreement on QOS, the host/client/customer will need
to signal an actual reservation request to the network for the necessary QOS
agreed to at the session level. This is the protocol that we need to work
on. 

This approach is discussed in the SIP draft "SIP Extensions for Media
Authorization" (draft-ietf-sip-call-auth-03.txt) and the RAP draft
"Framework for session set-up with media authorization"
(draft-ietf-rap-session-auth-02.txt).

Marco Schneider

-----Original Message-----
From: Roy, Radhika R, ALASO [mailto:rrroy@att.com]
Sent: Friday, January 18, 2002 9:18 AM
To: Schneider, Marco; Gary Kenward; Loughney John (NRC/Helsinki);
brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
dick.rr.knight@bt.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


Defined below [RRR]

-----Original Message-----
From: Schneider, Marco [mailto:schneider@tri.sbc.com]
Sent: Thursday, January 17, 2002 8:47 PM
To: Roy, Radhika R, ALASO; Gary Kenward; Loughney John (NRC/Helsinki);
brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
dick.rr.knight@bt.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


Hi Roy,

Can you please define what you mean by "End-to-End Application Layer QOS
Signaling". Thanks.

[RRR] Suppose an user is initiation a SIP call to another user with audio,
video, and data. The use needs to express the needs of QOS for audio, video,
and data to another user. 

[RRR] The signaling mechanism that allows to express the QOS parameters of
audio, video, and data is termed as the "End-to-End Application Layer QOS
Signaling."

Marco Schneider

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

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

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



From daemon@ns.ietf.org  Mon Jan 21 20:57:31 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29875
	for <nsis-archive@odin.ietf.org>; Mon, 21 Jan 2002 20:57:31 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id UAA06384
	for nsis-archive@odin.ietf.org; Mon, 21 Jan 2002 20:57:34 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA06237;
	Mon, 21 Jan 2002 20:48: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 UAA06177
	for <nsis@ns.ietf.org>; Mon, 21 Jan 2002 20:47:58 -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 UAA29746
	for <nsis@ietf.org>; Mon, 21 Jan 2002 20:47:54 -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 g0M1o2T04608;
	Mon, 21 Jan 2002 19:50:02 -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 g0M1lDK05323;
	Mon, 21 Jan 2002 19:47:13 -0600 (CST)
Received: by TRIMAIL2.ad.tri.sbc.com with Internet Mail Service (5.5.2653.19)
	id <ZND32VY4>; Mon, 21 Jan 2002 19:47:39 -0600
Message-ID: <905A1C4ABF353F4C8CC16FA9F53DD0D638B9A6@TRIMAIL2.ad.tri.sbc.com>
From: "Schneider, Marco" <schneider@tri.sbc.com>
To: "'Gary Kenward'" <gkenward@nortelnetworks.com>,
        "'Roy, Radhika R, ALASO'" <rrroy@att.com>,
        "Loughney John (NRC/Helsinki)"
	 <john.loughney@nokia.com>,
        brunner@ccrle.nec.de, Yaron Kahana
	 <ykahana@comgates.co.il>,
        "Geib, Ruediger" <Ruediger.Geib@t-systems.com>, dick.rr.knight@bt.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements
Date: Mon, 21 Jan 2002 19:47:30 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C1A2E6.C0C33180"
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_01C1A2E6.C0C33180
Content-Type: text/plain;
	charset="iso-8859-1"

Gary, 
 
Please see my comments preceeded by [MS] below.
 
Marco

-----Original Message-----
From: Gary Kenward [mailto:gkenward@nortelnetworks.com]
Sent: Monday, January 21, 2002 8:53 AM
To: Schneider, Marco; 'Roy, Radhika R, ALASO'; Loughney John (NRC/Helsinki);
brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger; dick.rr.knight@bt.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements



Marco: 

  I believe I see why you characterize end-to-end QoS signalling to the 
the session layer. What seems to be missing here is a model for how 
QoS is signalled at the transport layer to set up the required transport 
(and underlying mechanisms). 
[MS]  Yes, exactly.

  I don't believe you are proposing a "layering" of signalling protocols, 
one for session establishment, then one for transport, etc. 
[MS]  This is exactly what has been proposed in RAP and SIP working groups
to the best of my understanding. Because there does not exist a proxy
signaling capability that allows a session to setup a connection on the
users behalf, the session forwards a token to the end-system and then the
end-system includes that token in the RSVP path message so that the
reservation will go through. In this manner the session layer does not need
to communicate directly with the transport layer.

So, the question, 
becomes, how are the QoS transport mechanisms established? In the internet 
model there is only one end-to-end transport session (e.g. TCP, RTP, UDP), 
but underneath the transport is a series of inter-connected networks, each 
with potentially different characteristics. 

  This is end-to-end QoS support structure has to be set up and maintained 
in order for the end to end session QoS to be realized. The solution may be 
a single protocol that travels from host to host, such as RSVP, or it may 
be a collection of protocols that are optimized for each portion of the 
end-to-end path: e.g. host to access network, access to core network, 
core to core network, etc. 

  It is too early to determine which approach is best, but in either case, 
do we not need to understand the end-to-end requirements for this signalling

capability? 
[MS]  So by end-to-end you are referring to both the end-systems and the
devices in between. As a point of clarification, I asked Roy what he meant
by "End-to-End Application Layer QOS Signaling" and his answer implied user
(end-system) to user (end-system).  We have been using the term end-to-end
in different ways (contexts). The way I normally use the term "end-to-end"
is to include everything in between (all the hops). 

[MS] I think our basic requirement is that an end-system be able to request
(and receive) a QOS connection to some other end-system (NSIS UNI). The
request part entails an NSIS UNI. As you say the realization of this request
can be achieved in a number of different ways. Now one solution is to invent
an NSIS NNI that runs between domains. If we develop requirements for such
an NSIS UNI then we have already preproposed a solution ahead of
requirements. 


[Schneider, Marco]  

Gary Kenward 

> -----Original Message----- 
> From: Schneider, Marco [ mailto:schneider@tri.sbc.com
<mailto:schneider@tri.sbc.com> ] 
> Sent: January 18, 2002 15:10 
> To: 'Roy, Radhika R, ALASO'; Kenward, Gary [WDLN2:AN10:EXCH]; Loughney 
> John (NRC/Helsinki); brunner@ccrle.nec.de; Yaron Kahana; 
> Geib, Ruediger; 
> dick.rr.knight@bt.com 
> Cc: nsis@ietf.org 
> Subject: RE: [NSIS] Two kinds of requirements 
> 
> 
> Hi Roy, 
> 
> Below is the original text from your reponse to Gary Kenward. 
> Hopefully the 
> context is clear. 
> 
> "[Roy, Radhika R, ALARC]  I would say that it is the QOS needs of the 
> application (e.g., SIP-based VoIP) that the user likes to express (as 
> opposed to "service"). Similarly, instead of network 
> services, we would say 
> network layer QOS services (e.g., RSVP, DiffServ, MPLS). We 
> would develop 
> the end-to-end (application layer) QOS signaling protocol 
> (say, NSIS QOS). 
> Now, there needs to have some kinds of standards how NSIS QOS 
> will be mapped 
> over RSVP, DiffServ, MPLS, etc." 
> 
> So by End-to-End you mean between directly between two 
> "users". This is 
> session level signaling and I don't believe the signaling 
> part is within the 
> scope of this working group. An application level QOS 
> specification may be. 
> 
> After a session level agreement on QOS, the 
> host/client/customer will need 
> to signal an actual reservation request to the network for 
> the necessary QOS 
> agreed to at the session level. This is the protocol that we 
> need to work 
> on. 
> 
> This approach is discussed in the SIP draft "SIP Extensions for Media 
> Authorization" (draft-ietf-sip-call-auth-03.txt) and the RAP draft 
> "Framework for session set-up with media authorization" 
> (draft-ietf-rap-session-auth-02.txt). 
> 
> Marco Schneider 
> 
> -----Original Message----- 
> From: Roy, Radhika R, ALASO [ mailto:rrroy@att.com <mailto:rrroy@att.com>
] 
> Sent: Friday, January 18, 2002 9:18 AM 
> To: Schneider, Marco; Gary Kenward; Loughney John (NRC/Helsinki); 
> brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger; 
> dick.rr.knight@bt.com 
> Cc: nsis@ietf.org 
> Subject: RE: [NSIS] Two kinds of requirements 
> 
> 
> Defined below [RRR] 
> 
> -----Original Message----- 
> From: Schneider, Marco [ mailto:schneider@tri.sbc.com
<mailto:schneider@tri.sbc.com> ] 
> Sent: Thursday, January 17, 2002 8:47 PM 
> To: Roy, Radhika R, ALASO; Gary Kenward; Loughney John (NRC/Helsinki); 
> brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger; 
> dick.rr.knight@bt.com 
> Cc: nsis@ietf.org 
> Subject: RE: [NSIS] Two kinds of requirements 
> 
> 
> Hi Roy, 
> 
> Can you please define what you mean by "End-to-End 
> Application Layer QOS 
> Signaling". Thanks. 
> 
> [RRR] Suppose an user is initiation a SIP call to another 
> user with audio, 
> video, and data. The use needs to express the needs of QOS 
> for audio, video, 
> and data to another user. 
> 
> [RRR] The signaling mechanism that allows to express the QOS 
> parameters of 
> audio, video, and data is termed as the "End-to-End 
> Application Layer QOS 
> Signaling." 
> 
> Marco Schneider 
> 
> _______________________________________________ 
> nsis mailing list 
> nsis@ietf.org 
> https://www1.ietf.org/mailman/listinfo/nsis
<https://www1.ietf.org/mailman/listinfo/nsis>  
> 


------_=_NextPart_001_01C1A2E6.C0C33180
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">
<TITLE>RE: [NSIS] Two kinds of requirements</TITLE>

<META content="MSHTML 5.50.4616.200" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=501142100-22012002><FONT face=Arial color=#0000ff size=2>Gary, 
</FONT></SPAN></DIV>
<DIV><SPAN class=501142100-22012002><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=501142100-22012002><FONT face=Arial color=#0000ff size=2>Please 
see my comments preceeded by&nbsp;[MS] below.</FONT></SPAN></DIV>
<DIV><SPAN class=501142100-22012002><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=501142100-22012002><FONT face=Arial color=#0000ff 
size=2>Marco</FONT></SPAN></DIV>
<BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Gary Kenward 
  [mailto:gkenward@nortelnetworks.com]<BR><B>Sent:</B> Monday, January 21, 2002 
  8:53 AM<BR><B>To:</B> Schneider, Marco; 'Roy, Radhika R, ALASO'; Loughney John 
  (NRC/Helsinki); brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger; 
  dick.rr.knight@bt.com<BR><B>Cc:</B> nsis@ietf.org<BR><B>Subject:</B> RE: 
  [NSIS] Two kinds of requirements<BR><BR></FONT></DIV>
  <P><FONT size=2>Marco:</FONT> </P>
  <P><FONT size=2>&nbsp; I believe I see why you characterize end-to-end QoS 
  signalling to the</FONT> <BR><FONT size=2>the session layer. What seems to be 
  missing here is a model for how</FONT> <BR><FONT size=2>QoS is signalled at 
  the transport layer to set up the required transport</FONT> <BR><FONT 
  size=2>(and underlying mechanisms). <BR><SPAN class=501142100-22012002><FONT 
  face=Arial color=#0000ff>[MS]&nbsp;&nbsp;Yes, 
exactly.</FONT></SPAN></FONT></P>
  <P><FONT size=2>&nbsp; I don't believe you are proposing a "layering" of 
  signalling protocols, </FONT><BR><FONT size=2>one for session establishment, 
  then one for transport, etc. <BR><SPAN class=501142100-22012002><FONT 
  face=Arial color=#0000ff>[MS]&nbsp;</FONT></SPAN></FONT><FONT size=2><SPAN 
  class=501142100-22012002>&nbsp;<FONT face=Arial color=#0000ff>This is exactly 
  what has been proposed in RAP and SIP working groups to the best of my 
  understanding. Because there does not exist a proxy signaling capability that 
  allows a session to setup a connection on the users behalf, the session 
  forwards a token to the end-system and then the end-system includes that token 
  in the RSVP&nbsp;path message&nbsp;so that&nbsp;the reservation&nbsp;will go 
  through. In this manner the session layer does not need to communicate 
  directly with the transport layer.</FONT></SPAN></FONT></P>
  <P><FONT size=2><SPAN class=501142100-22012002></SPAN>So, the question,</FONT> 
  <BR><FONT size=2>becomes, how are the QoS transport mechanisms established? In 
  the internet </FONT><BR><FONT size=2>model there is only one end-to-end 
  transport session (e.g. TCP, RTP, UDP), </FONT><BR><FONT size=2>but underneath 
  the transport is a series of inter-connected networks, each </FONT><BR><FONT 
  size=2>with potentially different characteristics. </FONT></P>
  <P><FONT size=2>&nbsp; This is end-to-end QoS support structure has to be set 
  up and maintained</FONT> <BR><FONT size=2>in order for the end to end session 
  QoS to be realized. The solution may be</FONT> <BR><FONT size=2>a single 
  protocol that travels from host to host, such as RSVP, or it may</FONT> 
  <BR><FONT size=2>be a collection of protocols that are optimized for each 
  portion of the</FONT> <BR><FONT size=2>end-to-end path: e.g. host to access 
  network, access to core network, </FONT><BR><FONT size=2>core to core network, 
  etc.</FONT> </P>
  <P><FONT size=2>&nbsp; It is too early to determine which approach is best, 
  but in either case,</FONT> <BR><FONT size=2>do we not need to understand the 
  end-to-end requirements for this signalling</FONT> <BR><FONT 
  size=2>capability?</FONT> <BR><SPAN class=501142100-22012002><FONT face=Arial 
  color=#0000ff size=2>[MS]&nbsp;&nbsp;So by end-to-end you are referring to 
  both the end-systems and the devices in between. </FONT></SPAN><SPAN 
  class=501142100-22012002></SPAN><SPAN class=501142100-22012002><FONT 
  face=Arial color=#0000ff size=2>As a point of clarification, I asked Roy what 
  he meant by <FONT size=2>"End-to-End Application Layer QOS Signaling" and his 
  answer implied user (end-system) to user (end-system).&nbsp; We have been 
  using the term end-to-end in different ways (contexts). The way I normally use 
  the term "end-to-end" is to include everything in between (all the hops). 
  </FONT></FONT></SPAN></P>
  <P><SPAN class=501142100-22012002><FONT face=Arial color=#0000ff size=2><FONT 
  size=2>[MS] I think our basic requirement is that an end-system be able to 
  request (and receive) a QOS connection to some other end-system (NSIS UNI). 
  The request part entails an NSIS UNI. As you say the realization of this 
  request can be achieved in a number of different ways. Now one solution is to 
  invent an NSIS NNI that runs between domains. If we develop requirements for 
  such an NSIS UNI then we have already preproposed a solution ahead of 
  requirements. </FONT></FONT></SPAN></P>
  <P><SPAN class=501142100-22012002><FONT face=Arial color=#0000ff 
  size=2></FONT></SPAN><BR><FONT size=2><SPAN class=501142100-22012002><FONT 
  face=Arial color=#0000ff>[Schneider, 
  Marco]&nbsp;&nbsp;</FONT></SPAN></FONT></P>
  <P><FONT size=2><SPAN class=501142100-22012002></SPAN>Gary Kenward</FONT> </P>
  <P><FONT size=2>&gt; -----Original Message-----</FONT> <BR><FONT size=2>&gt; 
  From: Schneider, Marco [<A 
  href="mailto:schneider@tri.sbc.com">mailto:schneider@tri.sbc.com</A>]</FONT> 
  <BR><FONT size=2>&gt; Sent: January 18, 2002 15:10</FONT> <BR><FONT 
  size=2>&gt; To: 'Roy, Radhika R, ALASO'; Kenward, Gary [WDLN2:AN10:EXCH]; 
  Loughney</FONT> <BR><FONT size=2>&gt; John (NRC/Helsinki); 
  brunner@ccrle.nec.de; Yaron Kahana; </FONT><BR><FONT size=2>&gt; Geib, 
  Ruediger;</FONT> <BR><FONT size=2>&gt; dick.rr.knight@bt.com</FONT> <BR><FONT 
  size=2>&gt; Cc: nsis@ietf.org</FONT> <BR><FONT size=2>&gt; Subject: RE: [NSIS] 
  Two kinds of requirements</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT 
  size=2>&gt; </FONT><BR><FONT size=2>&gt; Hi Roy,</FONT> <BR><FONT size=2>&gt; 
  </FONT><BR><FONT size=2>&gt; Below is the original text from your reponse to 
  Gary Kenward. </FONT><BR><FONT size=2>&gt; Hopefully the</FONT> <BR><FONT 
  size=2>&gt; context is clear.</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT 
  size=2>&gt; "[Roy, Radhika R, ALARC]&nbsp; I would say that it is the QOS 
  needs of the</FONT> <BR><FONT size=2>&gt; application (e.g., SIP-based VoIP) 
  that the user likes to express (as</FONT> <BR><FONT size=2>&gt; opposed to 
  "service"). Similarly, instead of network </FONT><BR><FONT size=2>&gt; 
  services, we would say</FONT> <BR><FONT size=2>&gt; network layer QOS services 
  (e.g., RSVP, DiffServ, MPLS). We </FONT><BR><FONT size=2>&gt; would 
  develop</FONT> <BR><FONT size=2>&gt; the end-to-end (application layer) QOS 
  signaling protocol </FONT><BR><FONT size=2>&gt; (say, NSIS QOS).</FONT> 
  <BR><FONT size=2>&gt; Now, there needs to have some kinds of standards how 
  NSIS QOS </FONT><BR><FONT size=2>&gt; will be mapped</FONT> <BR><FONT 
  size=2>&gt; over RSVP, DiffServ, MPLS, etc."</FONT> <BR><FONT size=2>&gt; 
  </FONT><BR><FONT size=2>&gt; So by End-to-End you mean between directly 
  between two </FONT><BR><FONT size=2>&gt; "users". This is</FONT> <BR><FONT 
  size=2>&gt; session level signaling and I don't believe the signaling 
  </FONT><BR><FONT size=2>&gt; part is within the</FONT> <BR><FONT size=2>&gt; 
  scope of this working group. An application level QOS </FONT><BR><FONT 
  size=2>&gt; specification may be. </FONT><BR><FONT size=2>&gt; 
  </FONT><BR><FONT size=2>&gt; After a session level agreement on QOS, the 
  </FONT><BR><FONT size=2>&gt; host/client/customer will need</FONT> <BR><FONT 
  size=2>&gt; to signal an actual reservation request to the network for 
  </FONT><BR><FONT size=2>&gt; the necessary QOS</FONT> <BR><FONT size=2>&gt; 
  agreed to at the session level. This is the protocol that we </FONT><BR><FONT 
  size=2>&gt; need to work</FONT> <BR><FONT size=2>&gt; on. </FONT><BR><FONT 
  size=2>&gt; </FONT><BR><FONT size=2>&gt; This approach is discussed in the SIP 
  draft "SIP Extensions for Media</FONT> <BR><FONT size=2>&gt; Authorization" 
  (draft-ietf-sip-call-auth-03.txt) and the RAP draft</FONT> <BR><FONT 
  size=2>&gt; "Framework for session set-up with media authorization"</FONT> 
  <BR><FONT size=2>&gt; (draft-ietf-rap-session-auth-02.txt).</FONT> <BR><FONT 
  size=2>&gt; </FONT><BR><FONT size=2>&gt; Marco Schneider</FONT> <BR><FONT 
  size=2>&gt; </FONT><BR><FONT size=2>&gt; -----Original Message-----</FONT> 
  <BR><FONT size=2>&gt; From: Roy, Radhika R, ALASO [<A 
  href="mailto:rrroy@att.com">mailto:rrroy@att.com</A>]</FONT> <BR><FONT 
  size=2>&gt; Sent: Friday, January 18, 2002 9:18 AM</FONT> <BR><FONT 
  size=2>&gt; To: Schneider, Marco; Gary Kenward; Loughney John 
  (NRC/Helsinki);</FONT> <BR><FONT size=2>&gt; brunner@ccrle.nec.de; Yaron 
  Kahana; Geib, Ruediger;</FONT> <BR><FONT size=2>&gt; 
  dick.rr.knight@bt.com</FONT> <BR><FONT size=2>&gt; Cc: nsis@ietf.org</FONT> 
  <BR><FONT size=2>&gt; Subject: RE: [NSIS] Two kinds of requirements</FONT> 
  <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT 
  size=2>&gt; Defined below [RRR]</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT 
  size=2>&gt; -----Original Message-----</FONT> <BR><FONT size=2>&gt; From: 
  Schneider, Marco [<A 
  href="mailto:schneider@tri.sbc.com">mailto:schneider@tri.sbc.com</A>]</FONT> 
  <BR><FONT size=2>&gt; Sent: Thursday, January 17, 2002 8:47 PM</FONT> 
  <BR><FONT size=2>&gt; To: Roy, Radhika R, ALASO; Gary Kenward; Loughney John 
  (NRC/Helsinki);</FONT> <BR><FONT size=2>&gt; brunner@ccrle.nec.de; Yaron 
  Kahana; Geib, Ruediger;</FONT> <BR><FONT size=2>&gt; 
  dick.rr.knight@bt.com</FONT> <BR><FONT size=2>&gt; Cc: nsis@ietf.org</FONT> 
  <BR><FONT size=2>&gt; Subject: RE: [NSIS] Two kinds of requirements</FONT> 
  <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT 
  size=2>&gt; Hi Roy,</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; 
  Can you please define what you mean by "End-to-End </FONT><BR><FONT 
  size=2>&gt; Application Layer QOS</FONT> <BR><FONT size=2>&gt; Signaling". 
  Thanks.</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; [RRR] 
  Suppose an user is initiation a SIP call to another </FONT><BR><FONT 
  size=2>&gt; user with audio,</FONT> <BR><FONT size=2>&gt; video, and data. The 
  use needs to express the needs of QOS </FONT><BR><FONT size=2>&gt; for audio, 
  video,</FONT> <BR><FONT size=2>&gt; and data to another user. </FONT><BR><FONT 
  size=2>&gt; </FONT><BR><FONT size=2>&gt; [RRR] The signaling mechanism that 
  allows to express the QOS </FONT><BR><FONT size=2>&gt; parameters of</FONT> 
  <BR><FONT size=2>&gt; audio, video, and data is termed as the "End-to-End 
  </FONT><BR><FONT size=2>&gt; Application Layer QOS</FONT> <BR><FONT 
  size=2>&gt; Signaling."</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT 
  size=2>&gt; Marco Schneider</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT 
  size=2>&gt; _______________________________________________</FONT> <BR><FONT 
  size=2>&gt; nsis mailing list</FONT> <BR><FONT size=2>&gt; 
  nsis@ietf.org</FONT> <BR><FONT size=2>&gt; <A target=_blank 
  href="https://www1.ietf.org/mailman/listinfo/nsis">https://www1.ietf.org/mailman/listinfo/nsis</A></FONT> 
  <BR><FONT size=2>&gt; </FONT></P></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C1A2E6.C0C33180--

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



From daemon@optimus.ietf.org  Tue Jan 22 04:18: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 EAA14333
	for <nsis-archive@odin.ietf.org>; Tue, 22 Jan 2002 04:18:47 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id EAA28086
	for nsis-archive@odin.ietf.org; Tue, 22 Jan 2002 04:18: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 EAA27851;
	Tue, 22 Jan 2002 04:08: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 EAA27817
	for <nsis@optimus.ietf.org>; Tue, 22 Jan 2002 04:08:52 -0500 (EST)
Received: from mail1.telekom.de ([62.225.183.235])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14195
	for <nsis@ietf.org>; Tue, 22 Jan 2002 04:08:49 -0500 (EST)
Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Tue, 22 Jan 2002 10:03:13 +0100
Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19)
	id <ZLG2R19A>; Tue, 22 Jan 2002 10:04:49 +0100
Message-Id: <DFD875E85664D3118FA6080006277DE70362C83A@U8PN2>
From: "Geib, Ruediger" <Ruediger.Geib@t-systems.com>
To: kallen@tri.sbc.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements
Date: Tue, 22 Jan 2002 10:04:45 +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 EAA27818
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

Allen,

I'm not sure on IETF terminology, but what you suggest may be a framework document. As framework documents are usual if new IETF activities begin, your suggestion is a good one. I'd however favour a requirements document. I am volunteering to co-author one (means contribution and review). 

Regards, Rüdiger

> Along the lines of my earlier reference to Use Cases, what do 
> you think about beginning to document the requirements the
> protocol should meet as a set of use cases describing how
> network users (or actually  their network devices) use the
> protocol-to-be to access the QoS capabilities of the
> network.  For example, one use case could show a voice over
> IP caller, another a network administrator setting up an
> Ethernet VPN, etc.  If the protocol has to support mobile
> handoffs, we would have a use  case showing
> that. It would give us a focal point instead of just e-mail.
 

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



From daemon@optimus.ietf.org  Tue Jan 22 04:48: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 EAA14617
	for <nsis-archive@odin.ietf.org>; Tue, 22 Jan 2002 04:48:44 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id EAA29327
	for nsis-archive@odin.ietf.org; Tue, 22 Jan 2002 04:48: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 EAA29062;
	Tue, 22 Jan 2002 04:39: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 EAA28991
	for <nsis@optimus.ietf.org>; Tue, 22 Jan 2002 04:39:16 -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 EAA14522
	for <nsis@ietf.org>; Tue, 22 Jan 2002 04:39:12 -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 g0M9dDIB010567
	for <nsis@ietf.org>; Tue, 22 Jan 2002 10:39:13 +0100 (MET)
Received: FROM esealnt747.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Tue Jan 22 10:38:54 2002 +0100
Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <YHKTLDXS>; Tue, 22 Jan 2002 10:38:54 +0100
Message-ID: <E244E44D6AB85E40AEEF7EAABE3545FA82338D@enleent104.nl.eu.ericsson.se>
From: "Georgios Karagiannis (ELN)" <Georgios.Karagiannis@eln.ericsson.se>
To: "'Schneider, Marco'" <schneider@tri.sbc.com>
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements
Date: Tue, 22 Jan 2002 10:39:08 +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 Marco

The possible NSIS protocol components that can be 
used on the different NSIS protocol types are the following:

 * used components in "end host to end host" NSIS scenario: 
      [everyhost], [everyedge], [everyhop]

 * used components in "end host to proxy" NSIS scenario: 
      [everyhost], [everyedge], [everyhop]

 * used components in "end host to edge" NSIS scenario: 
      [everyedge], [everyhop]
 
 * used components in "edge to edge" NSIS scenario: 
      [everyedge], [everyhop]

Regarding the priority, we should decide it after the requirements,
architecture and framework drafts are done!

Best regards,
Georgios

-----Original Message-----
From: Schneider, Marco [mailto:schneider@tri.sbc.com]
Sent: dinsdag 22 januari 2002 1:03
To: 'Georgios Karagiannis (ELN)'; 'dick.rr.knight@bt.com'
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


Hi Georgios, All

If by x -- y you mean a protocol that runs directly between x and y (e.g.
end host -- end host, end host -- proxy...) then strictly speaking we are
discussing four  functionally distinct interfaces and thus four functionally
distinct protocols(possibly three if we group end host -- proxy and  end
host -- edge together). In my opinion: First we need to decide which of
these interfaces are in scope. Second we need to decide which one(s) we will
address first. Third we need to define the requirements for each for each of
the interfaces independently. 

With respect to scope and priority, I think we need to address in order:
1) end host -- edge/proxy
2) domain edge -- domain edge

 
Marco


-----Original Message-----
From: Georgios Karagiannis (ELN)
[mailto:Georgios.Karagiannis@eln.ericsson.se]
Sent: Monday, January 21, 2002 4:30 AM
To: 'dick.rr.knight@bt.com'
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements



Hi Dick

Please see my comment in line:
[DK]>> I do agree that it need not be processed on a per hop basis as it can
[DK]>> transverse a domain with a single QoS mechanism. That mechanism, be
it
[DK]>> diffserv or intserv, PNNI, RSVP, or even over-provisioning, takes
care of
[DK]>> the policing and the "path" establishment within the domain.

Please note that at the moment there are scenarios that will need to 
process the [everyhop] component. Some of these scenarios are the Radio
Access
Network and Mobile IP,..
Therefore, the [everyhop] component should be supported by the NSIS
protocol.
However a "host" or a "edge" should be able to activated or not.

Furthermore, in my opinion the NSIS protocol should be:
end host - end host: the NSIS protocol is terminated at end hosts;
end host - proxy: the NSIS protocol is terminated at end host and proxy;
end host - edge: the NSIS protocol is terminated at end end host and edge;
edge - edge: the NSIS protocol is terminated at egdes of one/multiple
domains;


Best regards,
Georgios


-----Original Message-----
From: Schneider, Marco [mailto:schneider@tri.sbc.com]
Sent: 18 January 2002 20:10
To: 'Roy, Radhika R, ALASO'; Gary Kenward; Loughney John (NRC/Helsinki);
brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
dick.rr.knight@bt.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


Hi Roy,

Below is the original text from your reponse to Gary Kenward. Hopefully the
context is clear.

"[Roy, Radhika R, ALARC]  I would say that it is the QOS needs of the
application (e.g., SIP-based VoIP) that the user likes to express (as
opposed to "service"). Similarly, instead of network services, we would say
network layer QOS services (e.g., RSVP, DiffServ, MPLS). We would develop
the end-to-end (application layer) QOS signaling protocol (say, NSIS QOS).
Now, there needs to have some kinds of standards how NSIS QOS will be mapped
over RSVP, DiffServ, MPLS, etc."

So by End-to-End you mean between directly between two "users". This is
session level signaling and I don't believe the signaling part is within the
scope of this working group. An application level QOS specification may be. 

After a session level agreement on QOS, the host/client/customer will need
to signal an actual reservation request to the network for the necessary QOS
agreed to at the session level. This is the protocol that we need to work
on. 

This approach is discussed in the SIP draft "SIP Extensions for Media
Authorization" (draft-ietf-sip-call-auth-03.txt) and the RAP draft
"Framework for session set-up with media authorization"
(draft-ietf-rap-session-auth-02.txt).

Marco Schneider

-----Original Message-----
From: Roy, Radhika R, ALASO [mailto:rrroy@att.com]
Sent: Friday, January 18, 2002 9:18 AM
To: Schneider, Marco; Gary Kenward; Loughney John (NRC/Helsinki);
brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
dick.rr.knight@bt.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


Defined below [RRR]

-----Original Message-----
From: Schneider, Marco [mailto:schneider@tri.sbc.com]
Sent: Thursday, January 17, 2002 8:47 PM
To: Roy, Radhika R, ALASO; Gary Kenward; Loughney John (NRC/Helsinki);
brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
dick.rr.knight@bt.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


Hi Roy,

Can you please define what you mean by "End-to-End Application Layer QOS
Signaling". Thanks.

[RRR] Suppose an user is initiation a SIP call to another user with audio,
video, and data. The use needs to express the needs of QOS for audio, video,
and data to another user. 

[RRR] The signaling mechanism that allows to express the QOS parameters of
audio, video, and data is termed as the "End-to-End Application Layer QOS
Signaling."

Marco Schneider

_______________________________________________
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 Jan 22 04:59: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 EAA14756
	for <nsis-archive@odin.ietf.org>; Tue, 22 Jan 2002 04:59:16 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id EAA29613
	for nsis-archive@odin.ietf.org; Tue, 22 Jan 2002 04:59: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 EAA29309;
	Tue, 22 Jan 2002 04:48: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 EAA29280
	for <nsis@optimus.ietf.org>; Tue, 22 Jan 2002 04:48:20 -0500 (EST)
Received: from mail1.telekom.de ([62.225.183.235])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14612
	for <nsis@ietf.org>; Tue, 22 Jan 2002 04:48:16 -0500 (EST)
Received: from g8pbq.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Tue, 22 Jan 2002 10:45:05 +0100
Received: by G8PBQ.blf01.telekom.de with Internet Mail Service (5.5.2653.19)
	id <CRH1CSSX>; Tue, 22 Jan 2002 10:46:37 +0100
Message-Id: <DFD875E85664D3118FA6080006277DE70362C839@U8PN2>
From: "Geib, Ruediger" <Ruediger.Geib@t-systems.com>
To: h.demeer@ee.ucl.ac.uk
Cc: nsis@ietf.org
Subject: RE: [NSIS] Support needed for Throughput Adaptive QoS in wireless
Date: Tue, 22 Jan 2002 09:57:27 +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 EAA29281
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

Hermann

> more generally, as pointed out by Georgios, this can be 
> referred to as QoS violation signalling:
> network to network or network to edge/host etc.
> 
> extending Georgios' view:
> - it may as well be required in wired network segments (not only in 
>   wireless segments)
> - does not only apply to individual flows but also to whole 
>   aggregates in the DiffServ sense, for example.
> 
> Please note, this does not necessarily mean re-negotiation.

Sounds like some kind of "congestion notification". An adaptive application would provide it on application level. Alternatively, a network service may provide it. I guess it is not a general requirement but may be useful for some services. Did we find a useful feature which doesn't have to be part of a generic NSIS protocol? I would agree, it should (or even must) be possible to add service specific congestion notification to an NSIS protocol.

Regards, Rüdiger 

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



From daemon@optimus.ietf.org  Tue Jan 22 05:10: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 FAA14908
	for <nsis-archive@odin.ietf.org>; Tue, 22 Jan 2002 05:10:24 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id FAA00351
	for nsis-archive@odin.ietf.org; Tue, 22 Jan 2002 05: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 FAA00066;
	Tue, 22 Jan 2002 05:01: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 FAA00031
	for <nsis@optimus.ietf.org>; Tue, 22 Jan 2002 05:01:02 -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 FAA14787
	for <nsis@ietf.org>; Tue, 22 Jan 2002 05:00:57 -0500 (EST)
From: Gabor.Fodor@era-t.ericsson.se
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 g0MA0xw21109;
	Tue, 22 Jan 2002 11:00:59 +0100 (MET)
Received: from erafodo by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T))
	id LAA21045; Tue, 22 Jan 2002 11:00:58 +0100
Message-Id: <200201221000.LAA21045@era-t.ericsson.se>
To: gilbert@rsch.comm.mot.com
Date: Tue, 22 Jan 2002 11:01:33 +0000
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Re: [NSIS] Support needed for Throughput Adaptive QoS in wireles
Reply-to: Gabor.Fodor@era-t.ericsson.se
CC: nsis@ietf.org
Priority: normal
In-reply-to: <200201181620.KAA13558@samichlaus.rsch.comm.mot.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

Steve, All,

I agree with what you write in your mail, Steve, and in my opinion this is a 
very good summary of the wireless characteristics. In fact, your description of 
the wireless characteristics are much in line with our draft about wireless 
issues :
http://www.ietf.org/internet-drafts/draft-fodor-intserv-wireless-issues-00.txt

Let me try to summarize the main characteristics (C1-C3) of the wireless 
transport that may impact the requirements on the QoS protocol at the IP level 
in an IP over wireless situation.

C1: The wireless resources (frequency, time slot, power, code-point, etc.) are 
scarce and therefore expensive. In addition they may change in time due to 
mobility, hand-over, interference, etc.

C2: The wireless link  imposes often significant delay on the bits that are 
transmitted over it. This delay is typically order(s) of magnitude longer than 
that imposed by the fixed (e.g optical) transmission links.

C3: It causes bit errors with typically orders of magnitude higher probability 
than that caused by the fixed transmission links.

From these one can easily derive at least two main objectives of the wireless 
link resource management :

O1. To provide the required QoS for the entity (e.g. an IP application running 
on a mobile station) that requests the wireless transport service over the 
air interface. The QoS of the wireless transport service is typically 
characterized by C2 and C3 above.

O2. To make as efficient use of the wireless resources as possible (because of 
C1 above).

From these two objectives it follows that the radio resource management 
requires information about (1) the required QoS and (2) the characteristics of 
the traffic that is transported over the wireless link. These two pieces of 
information are required in order to exercise admission control and to allocate 
the necessary resources.

In a scenario, where the wireless link provides the transport service for 
applications running over IP, it is a challenging task to provide these two 
pieces of information, because the application may not be aware of the wireless 
link. Therefore, in such a scenario, the QoS and resource reservation mechanism 
at the IP layer (e.g. resource reservation and/or signaling protocols and the 
IP level bearer service) need to provide support for the resource management at 
the wireless link layer.

From this observation it follows that we need fine grained QoS and traffic 
characteriztaion per user IP flow in the host-edge part. In fact, there are
applications, such as adaptive codecs, see :

http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-amr-10.txt

that allow QoS differentiation within an IP packet by employing the so called 
unequal bit protection technique. We may need to support this technique as 
well. Therefore, in my opinion it is important that we consider which 
paramaters (information elements) we support in the protocol. 


/Gabor

> Date:          Fri, 18 Jan 2002 10:20:50 -0600 (CST)
> To:            nsis@ietf.org
> From:          "Steve Gilbert" <gilbert@rsch.comm.mot.com>
> Reply-to:      gilbert@rsch.comm.mot.com
> Subject:       [NSIS] Support needed for Throughput Adaptive QoS in wireless

> 
> 
> I tend to agree with the need which Herman identifies (below) for throughput
> adaptive capabilities in a wireless QoS system.
> 
> The cellular wireless QoS problem is very different than that of wired QoS
> because of the need to handle the case of a user with a QoS "guarantee"
> handing off into a different cell.  In the worst case, the cell which it is
> entering may have its resources fully allocated to existing users. Dropping
> the session of the user being handed off is not a good idea. This points out
> the need for some rational way to accommodate such calls. The approach taken
> in some wireless voice systems is to reserve resources for use only by
> sessions which are handing off into the cell. This may suffice if the resource
> needs of the hand off session are predictable. However, in a system in which
> arbitrary applications can utilize a wide range of throughput values,
> reserving enough capacity to handle the range of throughputs which could
> potentially be needed by a single flow may not be practical.
> 
> What is needed is the use of throughput adaptive applications and the ability
> for a traffic flow to express its QoS preferences with regard to the
> throughput values which it may be allocated. Upon handing off into the new
> cell, the QoS preferences of the handoff traffic flow and of the existing
> traffic flows in that cell would be considered and resources reallocated to
> best meet their preferences. Some of the existing traffic flows may have their
> throughput allocations reduced in order to free up resources to be allocated
> to the handoff traffic flow.
> 
> The QoS signaling needs of this approach include the ability of the system to
> notify traffic flows of their new allocations, and the ability for a new
> traffic flow requesting "admission" to express its QoS preferences, possibly
> in terms of a list of throughput values and the benefit it receives from each.
> A non-adaptive real-time application would indicate a single throughput value
> which it desires rather than a list of throughput values.
> 
> One could argue that this provides no throughput "guarantee" and changes what
> it means to have a QoS request "admitted". This is true. But in wireless, it
> is difficult and sometimes impractical to provide the same QoS guarantees that
> could be provided in a wireline system which doesn't have to deal with
> handoff. In a wireless system, there is the possibility that the user will
> drive into a tunnel or take the elevator to a sub-basement of a building where
> the wireless signal is lost. Radio coverage and QoS can not be guaranteed
> under all possible situations.  Wireless channel resources are often more
> scarce or expensive than those of a wired channel. This generally results in
> the motivation to utilize them more efficiently. What is more realistic than
> trying to provide wireless QoS identical to that of wire-line is to come up
> with a useful approach for "QoS management" and "resource allocation" which
> can be applied in a wireless system.
> 
> If efficient utilization of the resources by QoS flows is not a major concern,
> the QoS of admitted users could be increased (or at least made less prone to
> reductions) through over-provisioning or preventing admission of new calls
> even when the level of congestion is still low. The resources not guaranteed
> to QoS traffic flows could be used by best effort traffic. Systems with
> significant best effort traffic would be able to increase the overall
> utilization of the channel without negatively effecting QoS traffic flows.
> 
> Steve
> 
> 
> 
> > Date: Thu, 17 Jan 2002 19:49:13 +0000
> > To: "Georgios Karagiannis (ELN)" <Georgios.Karagiannis@eln.ericsson.se>,
> >    "'Loughney John (NRC/Helsinki)'" <john.loughney@nokia.com>,
> >    "'ext Kappler Cornelia'" <Cornelia.Kappler@icn.siemens.de>
> > From: Hermann De Meer <h.demeer@ee.ucl.ac.uk>
> > Cc: <nsis@ietf.org>
> > Subject: RE: [NSIS] Two kinds of requirements
> > 
> > Hi Georgios and all
> > 
> > At 14:09 17/01/2002 +0100, Georgios Karagiannis (ELN) wrote:
> > >Hi John and Cornelia
> > >
> > >I think that one of the requirements that should be included
> > >in the NSIS WG requirements document is that the NSIS protocol
> > >should be modular. Modular in the context of having
> > >a toolkit from which one can choose the applicable tools
> > >in order to manage QoS in a particular networking environment.
> > 
> > I believe you are raising a very important issue with the emphasis on 
> > modularity
> > of QoS architectures/signalling.
> > 
> > But one can generalize that: it's all about flexibility,
> > namely flexibility of signalling/control/provisioning vs. flexibility of 
> > applications/users.
> > 
> > Flexibility does not necessarily mean complexity, often on the contrary:
> > one side being flexible makes the life for the other side easier (think of 
> > airline ticket pricing:
> > the price for the *same seat* can vary in an order of magnitude simply
> > depending on how flexible you are!)
> > 
> > QoS signalling is about indicating of how "inflexible" you are from that 
> > perspective.
> > But looking at IntServ (RSVP) or DiffServ,  an interpretation of these signals
> > have traditionally been seen rather statically:
> > 
> > - a "one-size-fits-all"  "end-to-end" implementation of the mechanisms
> > - a "take-it-or-leave-it" approach: statically defined QoS classes.
> > 
> > this makes QoS provisioning cumbersome, complex, expensive (unnecessarily)
> > (and it may be a good deal the reason for the "failure/insufficiency" of 
> > current QoS solutions/
> > signalling techniques).
> > 
> > Remember, the success of IP networking has to a larger extend been due to 
> > the fact of
> > relying on flexibility and cooperation, for example, for congestion handling.
> > (or "exception" handling, if you want, by TCP-similar schemes)
> > 
> > in <draft-demeer-nsis-analyis-00.txt> we therefore make a point to extend 
> > QoS signalling for:
> > 
> > 1) explicitly dealing with such "QoS exceptions" (there is also an economic 
> > argument for this)
> >      that is, not only signaling QoS preferences from applications to the 
> > network, but also
> >      QoS exceptions back from networks to applications or to between networks,
> >      and an expected cooperative adaptation.
> > 
> > 2) allowing for flexible interpretations in different domains (core, 
> > access, mobile, wireless,
> >       administrative conditions, ....)
> > 
> > 
> > The "trick" may be to modify signalling (including RSVP) such that most 
> > flexibility/cooperation
> > can be re-gained by assuring a minimum support of inflexibility 
> > (intentionally not using the
> > the term QoS guarantee here).
> > 
> > 
> > --Hermann
> > 
> ...
> 
> _______________________________________________
> 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 Jan 22 06:06: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 GAA15493
	for <nsis-archive@odin.ietf.org>; Tue, 22 Jan 2002 06:06:04 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id GAA02037
	for nsis-archive@odin.ietf.org; Tue, 22 Jan 2002 06:06: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 FAA01474;
	Tue, 22 Jan 2002 05:53: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 FAA01446
	for <nsis@optimus.ietf.org>; Tue, 22 Jan 2002 05:53:51 -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 FAA15400
	for <nsis@ietf.org>; Tue, 22 Jan 2002 05:53:46 -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 g0MArq903947
	for <nsis@ietf.org>; Tue, 22 Jan 2002 12:53:52 +0200 (EET)
Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T589aab212aac158f23077@esvir03nok.nokia.com>;
 Tue, 22 Jan 2002 12:53:48 +0200
Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779);
	 Tue, 22 Jan 2002 12:53:48 +0200
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [NSIS] Two kinds of requirements
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
Date: Tue, 22 Jan 2002 12:53:48 +0200
Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF5D93E0@esebe004.NOE.Nokia.com>
Thread-Topic: [NSIS] Two kinds of requirements
Thread-Index: AcGiolGJLVRtY5scShmUfXg3o9NqzgAkLVPA
To: <kallen@tri.sbc.com>, <nsis@ietf.org>
X-OriginalArrivalTime: 22 Jan 2002 10:53:48.0538 (UTC) FILETIME=[12191DA0:01C1A333]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id FAA01447
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 Keith,

> The Object-Oriented software world has turned to user-centric 
> requirements (in the form of Use Cases) as the basis for analysis and 
> design.  They are getting good results with this process.  We should also focus 
> on what the user wants to do.  The user sends a request to the network, 
> then he doesn't care what the network has to do to meet it.  If it turns out 
> that RSVP can't meet the needs of the subscriber it will have to evolve or be 
> replaced. Unfortunately, though, we don't even know if RSVP will 
> suffice because we haven't captured what the user can do.

I agree.

John

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



From daemon@optimus.ietf.org  Tue Jan 22 09:45: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 JAA20092
	for <nsis-archive@odin.ietf.org>; Tue, 22 Jan 2002 09:45:55 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id JAA10752
	for nsis-archive@odin.ietf.org; Tue, 22 Jan 2002 09:45: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 JAA09114;
	Tue, 22 Jan 2002 09:34: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 JAA09078
	for <nsis@optimus.ietf.org>; Tue, 22 Jan 2002 09:34:24 -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 JAA19604
	for <nsis@ietf.org>; Tue, 22 Jan 2002 09:34:19 -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 g0MEaRT06923
	for <nsis@ietf.org>; Tue, 22 Jan 2002 08:36:27 -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 g0MEXlB18979
	for <nsis@ietf.org>; Tue, 22 Jan 2002 08:33:47 -0600 (CST)
Received: by TRIMAIL2.ad.tri.sbc.com with Internet Mail Service (5.5.2653.19)
	id <ZND32X1Z>; Tue, 22 Jan 2002 08:34:15 -0600
Message-ID: <905A1C4ABF353F4C8CC16FA9F53DD0D62A7003@TRIMAIL2.ad.tri.sbc.com>
From: "Allen, Keith" <kallen@tri.sbc.com>
To: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements
Date: Tue, 22 Jan 2002 08:34:10 -0600
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 JAA09079
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

Rüdiger,

I was, in fact, proposing a requirements document.  I was merely suggesting
that the requirements for the protocol be captured with a technique used in
the OO software industry (as well as elsewhere) called Use Cases.  The idea
behind Use Cases, simply put, is to describe the requirements for a system
from the user's point of view.  This is done with a set of use cases, each
one being a scenario describing how the user utilizes the system to
accomplish some task.  The descriptions of all the tasks performed by the
user represent the requirements the system must meet.  I have not seen Use
Cases applied to protocol development but I see no reason why it couldn't
be.  Simply identifying the user will help us to settle all these
edge-host-hop-proxy discussions.

Use cases are good at capturing functional requirements, but aren't so
applicable to other types of requirements.  For example, if someone out
there is insistent that one of the requirements is "Must interwork with
RSVP-TE," that's not so easily captured in a use case.  If we decide to use
Use Cases we might have to amend them with more traditional requirements.


Keith Allen
SBC Technology Resources
9505 Arboretum Blvd.
Austin, TX 78759
(512) 372-5741
kallen@tri.sbc.com

This e-mail and any files transmitted with it are the property of SBC, are
confidential, and are intended solely for the use of the individual or
entity to whom this e-mail is addressed. If you are not one of the named
recipient(s) or otherwise have reason to believe that you have received this
message in error, please notify the sender at (512) 372-5000 and delete this
message immediately from your computer. Any other use, retention,
dissemination, forwarding, printing, or copying of this e-mail is strictly
prohibited.


 -----Original Message-----
From: 	Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] 
Sent:	Tuesday, January 22, 2002 3:05 AM
To:	Allen, Keith
Cc:	nsis@ietf.org
Subject:	RE: [NSIS] Two kinds of requirements

Allen,

I'm not sure on IETF terminology, but what you suggest may be a framework
document. As framework documents are usual if new IETF activities begin,
your suggestion is a good one. I'd however favour a requirements document. I
am volunteering to co-author one (means contribution and review). 

Regards, Rüdiger

> Along the lines of my earlier reference to Use Cases, what do 
> you think about beginning to document the requirements the
> protocol should meet as a set of use cases describing how
> network users (or actually  their network devices) use the
> protocol-to-be to access the QoS capabilities of the
> network.  For example, one use case could show a voice over
> IP caller, another a network administrator setting up an
> Ethernet VPN, etc.  If the protocol has to support mobile
> handoffs, we would have a use  case showing
> that. It would give us a focal point instead of just e-mail.
 

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



From daemon@optimus.ietf.org  Tue Jan 22 10:12: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 KAA25564
	for <nsis-archive@odin.ietf.org>; Tue, 22 Jan 2002 10:12:11 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id KAA12285
	for nsis-archive@odin.ietf.org; Tue, 22 Jan 2002 10:12: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 KAA12047;
	Tue, 22 Jan 2002 10:02: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 KAA11982
	for <nsis@optimus.ietf.org>; Tue, 22 Jan 2002 10:02:23 -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 KAA24133
	for <nsis@ietf.org>; Tue, 22 Jan 2002 10:02:18 -0500 (EST)
Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56])
	by zcars0m9.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g0MF1hS29390;
	Tue, 22 Jan 2002 10:01:43 -0500 (EST)
Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7])
	by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g0MF1dT25554;
	Tue, 22 Jan 2002 10:01:40 -0500 (EST)
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19)
	id <C8PZYH58>; Tue, 22 Jan 2002 10:01:40 -0500
Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA478F@zcard031.ca.nortel.com>
From: "Gary Kenward"<gkenward@nortelnetworks.com>
To: "'Schneider, Marco'" <schneider@tri.sbc.com>,
        "'Roy, Radhika R, ALASO'" <rrroy@att.com>,
        "Loughney John (NRC/Helsinki)"
	 <john.loughney@nokia.com>,
        brunner@ccrle.nec.de, Yaron Kahana
	 <ykahana@comgates.co.il>,
        "Geib, Ruediger" <Ruediger.Geib@t-systems.com>, dick.rr.knight@bt.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements
Date: Tue, 22 Jan 2002 10:01:39 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C1A355.B2171790"
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_01C1A355.B2171790
Content-Type: text/plain;
	charset="ISO-8859-1"

Marco:

-----Original Message-----
> From: Schneider, Marco [mailto:schneider@tri.sbc.com]
> Sent: January 21, 2002 20:48
> To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Roy, Radhika R, ALASO'; Loughney
John > 
> (NRC/Helsinki); brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
dick.rr.knight@bt.com
> Cc: nsis@ietf.org
> Subject: RE: [NSIS] Two kinds of requirements
> 
> 
> Gary, 
>  
> Please see my comments preceeded by [MS] below.
>  
> Marco
> -----Original Message-----
> From: Gary Kenward [mailto:gkenward@nortelnetworks.com]
> Sent: Monday, January 21, 2002 8:53 AM
> To: Schneider, Marco; 'Roy, Radhika R, ALASO'; Loughney John
(NRC/Helsinki); 
> brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger; dick.rr.knight@bt.com
> Cc: nsis@ietf.org
> Subject: RE: [NSIS] Two kinds of requirements


> Marco: 
>   I believe I see why you characterize end-to-end QoS signalling to the 
> the session layer. What seems to be missing here is a model for how 
> QoS is signalled at the transport layer to set up the required transport 
> (and underlying mechanisms). 
> [MS]  Yes, exactly.
>   I don't believe you are proposing a "layering" of signalling protocols, 
> one for session establishment, then one for transport, etc. 
> [MS]  This is exactly what has been proposed in RAP and SIP working groups
to the best 
> of my understanding. Because there does not exist a proxy signaling
capability that 
> allows a session to setup a connection on the users behalf, the session
forwards a 
> token to the end-system and then the end-system includes that token in the
RSVP path 
> message so that the reservation will go through. In this manner the
session layer does 
> not need to communicate directly with the transport layer.

[gwk] I do not understand what "the session" represents in the above. It
would seem 
to me that you must have a session level entity, and that to "forward a
token to the
end-system", it must have an interface/api to the "end-system". If this
"end-system"
is including tokens in RSVP, then it is the entity setting up the transport
QoS (although
it is not necessarly a transport layer entity, but rather a signalling
entity. If these
two entites are co-located, then you do not have layered signalling
protocols.

Have I missed something?

BTW: for many links, particularly wireless, layered signalling is not a good
idea.
And, in general, layered signalling will always be slower then a single
signalling protocol.

> So, the question, 
> becomes, how are the QoS transport mechanisms established? In the internet

> model there is only one end-to-end transport session (e.g. TCP, RTP, UDP),

> but underneath the transport is a series of inter-connected networks, each

> with potentially different characteristics. 
>   This is end-to-end QoS support structure has to be set up and maintained

> in order for the end to end session QoS to be realized. The solution may
be 
> a single protocol that travels from host to host, such as RSVP, or it may 
> be a collection of protocols that are optimized for each portion of the 
> end-to-end path: e.g. host to access network, access to core network, 
> core to core network, etc. 
>   It is too early to determine which approach is best, but in either case,

> do we not need to understand the end-to-end requirements for this
signalling 
> capability? 
> [MS]  So by end-to-end you are referring to both the end-systems and the
devices in 
> between. As a point of clarification, I asked Roy what he meant by
"End-to-End 
> Application Layer QOS Signaling" and his answer implied user (end-system)
to user (end-
> system).  We have been using the term end-to-end in different ways
(contexts). The way 
> I normally use the term "end-to-end" is to include everything in between
(all the 
> hops). 

[gwk] I see the difference. I would say that I tend towards your definition,
in the 
following sense: the only QoS that matters is what the end-user sees, so as
a service
characteristic, it must be provided between the two end systems / hosts. In
order to do 
this, however, some level of support is required at each hop along the path.


  So, establishing QoS between the end systems requires a peer-to-peer
agreement between
the end systems, a host-to-cloud agreement for the transport of the packets,
and 
some mechanism within the cloud to ensure that the agreed upon QoS is
provided.
Depending upon the complexity of the cloud, the latter could imply all sorts
of QoS
agreements between networks and even nodes, for packet forwarding.

  Note that I have purposely NOT stated that any of these agreements are
negotiated or
require a signalling protocol. My opinion is that it is better in the long
term to
support negotiated services using signalling, as it provides more
flexibility. However,
this can be overdone, say, as a silly example, by having the end-system
negotiate with
every node in the network. So, the compromise is that some of the QoS
agreements will
be incorporated into the network design (e.g. Diff Serv), some will be
configured by
the operator(s) (e.g. through traffic engineering and policy management),
and others
will be signalled. NSIS seems to be about determining where signalling is
appropriate,
and what are the signalling peers, and what is the best protocol solution or
solutions.
The catch is that the first two approaches actually encompass a wide variety
of technologies
and scenarios.

  Sorry for stating the obvious. There is clearly some concern over the use,
for example,
of RSVP, and I suspect that some people are concerned that "end-to-end
signalling" also
means "hop-by-hop" ala RSVP. It could, but it does not have to.

  So, my view is that NSIS needs to ensure that the end-to-end QoS is
provided for, and
develope the protocols where they are needed (but not where they are not).
At this point,
that would seem to be host to edge, edge to edge, and at the very least,
with enough
end to end semantics to ensure that the complete path supports QoS. I am
concerned about
node to node signalling, as there are so many different approaches to
supporting node-to-node
QoS. At the very least, I would like to see a framework, and the edge
solutions defined
before we delve into "intra-network" issues.

  BTW: in writing this, it dawned upon me that it might be best to write a
series of
requirements rather then just one - i.e. tackle the problem piece by piece.
This approach
does have drawbacks, but working groups seem to work better when they focus
on contained
problem domains. A strawman framework might be useful in keeping the
incremental solutions
coherent.


> [MS] I think our basic requirement is that an end-system be able to
request (and 
> receive) a QOS connection to some other end-system (NSIS UNI). The request
part entails 
> an NSIS UNI. As you say the realization of this request can be achieved in
a number of 
> different ways. Now one solution is to invent an NSIS NNI that runs
between domains. If 
> we develop requirements for such an NSIS UNI then we have already
preproposed a 
> solution ahead of requirements. 

[gwk] We have to be extremely careful not to become pre-occupied with
requirements
definition. All productive requirements definition efforts begin with
assumptions 
concerning the solution. In my view, requirements specifications are a
balance between
presumption and prediction, particularly when dealing with "soft"
techologies such as
protocols. The issue really is not whether a requirement is a "MAY" or a
"SHOULD" or
whatever, the issue is whether a requirement actually helps us define the
solution
(there are lot's of examples of "SHOULD" requirements that do not bring
value to the
design process).

Given my observation above about writing a series of requirements, I would
recommend 
that we roughly map out the solution(some would call this a "framework").
This map would 
form the preliminary list of deliverables for the wg charter, and then pick
a focussed 
problem area to begin with requirements. This is not "top down" design, but
"top down" 
processes seldom work. If this seems too abstract, what I am saying is that
I have no 
problem identifying that there are N problem areas to be addressed - e.g.
host to edge, 
edge to edge, node to node, etc. - and picking anyone for the first design
attempt. Of 
course, the challenge would be to keep an eye on the "big picture" or
end-to-end 
requirements in the process.

Just my deluded point of view.
Cheers,
Gary

[Schneider, Marco]  
*snip*

------_=_NextPart_001_01C1A355.B2171790
Content-Type: text/html;
	charset="ISO-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2654.89">
<TITLE>RE: [NSIS] Two kinds of requirements</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Marco:</FONT>
</P>

<P><FONT SIZE=2>-----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; From: Schneider, Marco [<A HREF="mailto:schneider@tri.sbc.com">mailto:schneider@tri.sbc.com</A>]</FONT>
<BR><FONT SIZE=2>&gt; Sent: January 21, 2002 20:48</FONT>
<BR><FONT SIZE=2>&gt; To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Roy, Radhika R, ALASO'; Loughney John &gt; </FONT>
<BR><FONT SIZE=2>&gt; (NRC/Helsinki); brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger; dick.rr.knight@bt.com</FONT>
<BR><FONT SIZE=2>&gt; Cc: nsis@ietf.org</FONT>
<BR><FONT SIZE=2>&gt; Subject: RE: [NSIS] Two kinds of requirements</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Gary, </FONT>
<BR><FONT SIZE=2>&gt;&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; Please see my comments preceeded by [MS] below.</FONT>
<BR><FONT SIZE=2>&gt;&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; Marco</FONT>
<BR><FONT SIZE=2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; From: Gary Kenward [<A HREF="mailto:gkenward@nortelnetworks.com">mailto:gkenward@nortelnetworks.com</A>]</FONT>
<BR><FONT SIZE=2>&gt; Sent: Monday, January 21, 2002 8:53 AM</FONT>
<BR><FONT SIZE=2>&gt; To: Schneider, Marco; 'Roy, Radhika R, ALASO'; Loughney John (NRC/Helsinki); </FONT>
<BR><FONT SIZE=2>&gt; brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger; dick.rr.knight@bt.com</FONT>
<BR><FONT SIZE=2>&gt; Cc: nsis@ietf.org</FONT>
<BR><FONT SIZE=2>&gt; Subject: RE: [NSIS] Two kinds of requirements</FONT>
</P>
<BR>

<P><FONT SIZE=2>&gt; Marco: </FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp; I believe I see why you characterize end-to-end QoS signalling to the </FONT>
<BR><FONT SIZE=2>&gt; the session layer. What seems to be missing here is a model for how </FONT>
<BR><FONT SIZE=2>&gt; QoS is signalled at the transport layer to set up the required transport </FONT>
<BR><FONT SIZE=2>&gt; (and underlying mechanisms). </FONT>
<BR><FONT SIZE=2>&gt; [MS]&nbsp; Yes, exactly.</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp; I don't believe you are proposing a &quot;layering&quot; of signalling protocols, </FONT>
<BR><FONT SIZE=2>&gt; one for session establishment, then one for transport, etc. </FONT>
<BR><FONT SIZE=2>&gt; [MS]&nbsp; This is exactly what has been proposed in RAP and SIP working groups to the best </FONT>
<BR><FONT SIZE=2>&gt; of my understanding. Because there does not exist a proxy signaling capability that </FONT>
<BR><FONT SIZE=2>&gt; allows a session to setup a connection on the users behalf, the session forwards a </FONT>
<BR><FONT SIZE=2>&gt; token to the end-system and then the end-system includes that token in the RSVP path </FONT>
<BR><FONT SIZE=2>&gt; message so that the reservation will go through. In this manner the session layer does </FONT>
<BR><FONT SIZE=2>&gt; not need to communicate directly with the transport layer.</FONT>
</P>

<P><FONT SIZE=2>[gwk] I do not understand what &quot;the session&quot; represents in the above. It would seem </FONT>
<BR><FONT SIZE=2>to me that you must have a session level entity, and that to &quot;forward a token to the</FONT>
<BR><FONT SIZE=2>end-system&quot;, it must have an interface/api to the &quot;end-system&quot;. If this &quot;end-system&quot;</FONT>
<BR><FONT SIZE=2>is including tokens in RSVP, then it is the entity setting up the transport QoS (although</FONT>
<BR><FONT SIZE=2>it is not necessarly a transport layer entity, but rather a signalling entity. If these</FONT>
<BR><FONT SIZE=2>two entites are co-located, then you do not have layered signalling protocols.</FONT>
</P>

<P><FONT SIZE=2>Have I missed something?</FONT>
</P>

<P><FONT SIZE=2>BTW: for many links, particularly wireless, layered signalling is not a good idea.</FONT>
<BR><FONT SIZE=2>And, in general, layered signalling will always be slower then a single signalling protocol.</FONT>
</P>

<P><FONT SIZE=2>&gt; So, the question, </FONT>
<BR><FONT SIZE=2>&gt; becomes, how are the QoS transport mechanisms established? In the internet </FONT>
<BR><FONT SIZE=2>&gt; model there is only one end-to-end transport session (e.g. TCP, RTP, UDP), </FONT>
<BR><FONT SIZE=2>&gt; but underneath the transport is a series of inter-connected networks, each </FONT>
<BR><FONT SIZE=2>&gt; with potentially different characteristics. </FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp; This is end-to-end QoS support structure has to be set up and maintained </FONT>
<BR><FONT SIZE=2>&gt; in order for the end to end session QoS to be realized. The solution may be </FONT>
<BR><FONT SIZE=2>&gt; a single protocol that travels from host to host, such as RSVP, or it may </FONT>
<BR><FONT SIZE=2>&gt; be a collection of protocols that are optimized for each portion of the </FONT>
<BR><FONT SIZE=2>&gt; end-to-end path: e.g. host to access network, access to core network, </FONT>
<BR><FONT SIZE=2>&gt; core to core network, etc. </FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp; It is too early to determine which approach is best, but in either case, </FONT>
<BR><FONT SIZE=2>&gt; do we not need to understand the end-to-end requirements for this signalling </FONT>
<BR><FONT SIZE=2>&gt; capability? </FONT>
<BR><FONT SIZE=2>&gt; [MS]&nbsp; So by end-to-end you are referring to both the end-systems and the devices in </FONT>
<BR><FONT SIZE=2>&gt; between. As a point of clarification, I asked Roy what he meant by &quot;End-to-End </FONT>
<BR><FONT SIZE=2>&gt; Application Layer QOS Signaling&quot; and his answer implied user (end-system) to user (end-</FONT>
<BR><FONT SIZE=2>&gt; system).&nbsp; We have been using the term end-to-end in different ways (contexts). The way </FONT>
<BR><FONT SIZE=2>&gt; I normally use the term &quot;end-to-end&quot; is to include everything in between (all the </FONT>
<BR><FONT SIZE=2>&gt; hops). </FONT>
</P>

<P><FONT SIZE=2>[gwk] I see the difference. I would say that I tend towards your definition, in the </FONT>
<BR><FONT SIZE=2>following sense: the only QoS that matters is what the end-user sees, so as a service</FONT>
<BR><FONT SIZE=2>characteristic, it must be provided between the two end systems / hosts. In order to do </FONT>
<BR><FONT SIZE=2>this, however, some level of support is required at each hop along the path. </FONT>
</P>

<P><FONT SIZE=2>&nbsp; So, establishing QoS between the end systems requires a peer-to-peer agreement between</FONT>
<BR><FONT SIZE=2>the end systems, a host-to-cloud agreement for the transport of the packets, and </FONT>
<BR><FONT SIZE=2>some mechanism within the cloud to ensure that the agreed upon QoS is provided.</FONT>
<BR><FONT SIZE=2>Depending upon the complexity of the cloud, the latter could imply all sorts of QoS</FONT>
<BR><FONT SIZE=2>agreements between networks and even nodes, for packet forwarding.</FONT>
</P>

<P><FONT SIZE=2>&nbsp; Note that I have purposely NOT stated that any of these agreements are negotiated or</FONT>
<BR><FONT SIZE=2>require a signalling protocol. My opinion is that it is better in the long term to</FONT>
<BR><FONT SIZE=2>support negotiated services using signalling, as it provides more flexibility. However,</FONT>
<BR><FONT SIZE=2>this can be overdone, say, as a silly example, by having the end-system negotiate with</FONT>
<BR><FONT SIZE=2>every node in the network. So, the compromise is that some of the QoS agreements will</FONT>
<BR><FONT SIZE=2>be incorporated into the network design (e.g. Diff Serv), some will be configured by</FONT>
<BR><FONT SIZE=2>the operator(s) (e.g. through traffic engineering and policy management), and others</FONT>
<BR><FONT SIZE=2>will be signalled. NSIS seems to be about determining where signalling is appropriate,</FONT>
<BR><FONT SIZE=2>and what are the signalling peers, and what is the best protocol solution or solutions.</FONT>
<BR><FONT SIZE=2>The catch is that the first two approaches actually encompass a wide variety of technologies</FONT>
<BR><FONT SIZE=2>and scenarios.</FONT>
</P>

<P><FONT SIZE=2>&nbsp; Sorry for stating the obvious. There is clearly some concern over the use, for example,</FONT>
<BR><FONT SIZE=2>of RSVP, and I suspect that some people are concerned that &quot;end-to-end signalling&quot; also</FONT>
<BR><FONT SIZE=2>means &quot;hop-by-hop&quot; ala RSVP. It could, but it does not have to.</FONT>
</P>

<P><FONT SIZE=2>&nbsp; So, my view is that NSIS needs to ensure that the end-to-end QoS is provided for, and</FONT>
<BR><FONT SIZE=2>develope the protocols where they are needed (but not where they are not). At this point,</FONT>
<BR><FONT SIZE=2>that would seem to be host to edge, edge to edge, and at the very least, with enough</FONT>
<BR><FONT SIZE=2>end to end semantics to ensure that the complete path supports QoS. I am concerned about</FONT>
<BR><FONT SIZE=2>node to node signalling, as there are so many different approaches to supporting node-to-node</FONT>
<BR><FONT SIZE=2>QoS. At the very least, I would like to see a framework, and the edge solutions defined</FONT>
<BR><FONT SIZE=2>before we delve into &quot;intra-network&quot; issues.</FONT>
</P>

<P><FONT SIZE=2>&nbsp; BTW: in writing this, it dawned upon me that it might be best to write a series of</FONT>
<BR><FONT SIZE=2>requirements rather then just one - i.e. tackle the problem piece by piece. This approach</FONT>
<BR><FONT SIZE=2>does have drawbacks, but working groups seem to work better when they focus on contained</FONT>
<BR><FONT SIZE=2>problem domains. A strawman framework might be useful in keeping the incremental solutions</FONT>
<BR><FONT SIZE=2>coherent.</FONT>
</P>
<BR>

<P><FONT SIZE=2>&gt; [MS] I think our basic requirement is that an end-system be able to request (and </FONT>
<BR><FONT SIZE=2>&gt; receive) a QOS connection to some other end-system (NSIS UNI). The request part entails </FONT>
<BR><FONT SIZE=2>&gt; an NSIS UNI. As you say the realization of this request can be achieved in a number of </FONT>
<BR><FONT SIZE=2>&gt; different ways. Now one solution is to invent an NSIS NNI that runs between domains. If </FONT>
<BR><FONT SIZE=2>&gt; we develop requirements for such an NSIS UNI then we have already preproposed a </FONT>
<BR><FONT SIZE=2>&gt; solution ahead of requirements. </FONT>
</P>

<P><FONT SIZE=2>[gwk] We have to be extremely careful not to become pre-occupied with requirements</FONT>
<BR><FONT SIZE=2>definition. All productive requirements definition efforts begin with assumptions </FONT>
<BR><FONT SIZE=2>concerning the solution. In my view, requirements specifications are a balance between</FONT>
<BR><FONT SIZE=2>presumption and prediction, particularly when dealing with &quot;soft&quot; techologies such as</FONT>
<BR><FONT SIZE=2>protocols. The issue really is not whether a requirement is a &quot;MAY&quot; or a &quot;SHOULD&quot; or</FONT>
<BR><FONT SIZE=2>whatever, the issue is whether a requirement actually helps us define the solution</FONT>
<BR><FONT SIZE=2>(there are lot's of examples of &quot;SHOULD&quot; requirements that do not bring value to the</FONT>
<BR><FONT SIZE=2>design process).</FONT>
</P>

<P><FONT SIZE=2>Given my observation above about writing a series of requirements, I would recommend </FONT>
<BR><FONT SIZE=2>that we roughly map out the solution(some would call this a &quot;framework&quot;). This map would </FONT>
<BR><FONT SIZE=2>form the preliminary list of deliverables for the wg charter, and then pick a focussed </FONT>
<BR><FONT SIZE=2>problem area to begin with requirements. This is not &quot;top down&quot; design, but &quot;top down&quot; </FONT>
<BR><FONT SIZE=2>processes seldom work. If this seems too abstract, what I am saying is that I have no </FONT>
<BR><FONT SIZE=2>problem identifying that there are N problem areas to be addressed - e.g. host to edge, </FONT>
<BR><FONT SIZE=2>edge to edge, node to node, etc. - and picking anyone for the first design attempt. Of </FONT>
<BR><FONT SIZE=2>course, the challenge would be to keep an eye on the &quot;big picture&quot; or end-to-end </FONT>
<BR><FONT SIZE=2>requirements in the process.</FONT>
</P>

<P><FONT SIZE=2>Just my deluded point of view.</FONT>
<BR><FONT SIZE=2>Cheers,</FONT>
<BR><FONT SIZE=2>Gary</FONT>
</P>

<P><FONT SIZE=2>[Schneider, Marco]&nbsp; </FONT>
<BR><FONT SIZE=2>*snip*</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1A355.B2171790--

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



From daemon@optimus.ietf.org  Tue Jan 22 11:59: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 LAA00341
	for <nsis-archive@odin.ietf.org>; Tue, 22 Jan 2002 11:59:12 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id LAA23857
	for nsis-archive@odin.ietf.org; Tue, 22 Jan 2002 11:59: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 LAA20663;
	Tue, 22 Jan 2002 11:46: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 LAA20632
	for <nsis@optimus.ietf.org>; Tue, 22 Jan 2002 11:46:50 -0500 (EST)
Received: from cbibipnt03.HC.BT.COM (saturn.bt.com [193.113.57.20])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29546
	for <nsis@ietf.org>; Tue, 22 Jan 2002 11:46:46 -0500 (EST)
From: dick.rr.knight@bt.com
Received: by cbibipnt03.hc.bt.com with Internet Mail Service (5.5.2652.35)
	id <DA1W22F3>; Tue, 22 Jan 2002 16:46:08 -0000
Message-ID: <451D45016C2CD2119DA50000F8FE7F07080E5A5E@mlngcbnt01.hc.bt.com>
To: Georgios.Karagiannis@eln.ericsson.se, schneider@tri.sbc.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements
Date: Tue, 22 Jan 2002 16:45:53 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
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


I support Georgios. This is a nice conclusion that he has reached:
We cannot decide on a priority until the requirements are known.

Dick

-----Original Message-----
From: Georgios Karagiannis (ELN)
[mailto:Georgios.Karagiannis@eln.ericsson.se]
Sent: 22 January 2002 09:39
To: 'Schneider, Marco'
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


Hi Marco

The possible NSIS protocol components that can be 
used on the different NSIS protocol types are the following:

 * used components in "end host to end host" NSIS scenario: 
      [everyhost], [everyedge], [everyhop]

 * used components in "end host to proxy" NSIS scenario: 
      [everyhost], [everyedge], [everyhop]

 * used components in "end host to edge" NSIS scenario: 
      [everyedge], [everyhop]
 
 * used components in "edge to edge" NSIS scenario: 
      [everyedge], [everyhop]

Regarding the priority, we should decide it after the requirements,
architecture and framework drafts are done!

Best regards,
Georgios

-----Original Message-----
From: Schneider, Marco [mailto:schneider@tri.sbc.com]
Sent: dinsdag 22 januari 2002 1:03
To: 'Georgios Karagiannis (ELN)'; 'dick.rr.knight@bt.com'
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


Hi Georgios, All

If by x -- y you mean a protocol that runs directly between x and y (e.g.
end host -- end host, end host -- proxy...) then strictly speaking we are
discussing four  functionally distinct interfaces and thus four functionally
distinct protocols(possibly three if we group end host -- proxy and  end
host -- edge together). In my opinion: First we need to decide which of
these interfaces are in scope. Second we need to decide which one(s) we will
address first. Third we need to define the requirements for each for each of
the interfaces independently. 

With respect to scope and priority, I think we need to address in order:
1) end host -- edge/proxy
2) domain edge -- domain edge

 
Marco


-----Original Message-----
From: Georgios Karagiannis (ELN)
[mailto:Georgios.Karagiannis@eln.ericsson.se]
Sent: Monday, January 21, 2002 4:30 AM
To: 'dick.rr.knight@bt.com'
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements



Hi Dick

Please see my comment in line:
[DK]>> I do agree that it need not be processed on a per hop basis as it can
[DK]>> transverse a domain with a single QoS mechanism. That mechanism, be
it
[DK]>> diffserv or intserv, PNNI, RSVP, or even over-provisioning, takes
care of
[DK]>> the policing and the "path" establishment within the domain.

Please note that at the moment there are scenarios that will need to 
process the [everyhop] component. Some of these scenarios are the Radio
Access
Network and Mobile IP,..
Therefore, the [everyhop] component should be supported by the NSIS
protocol.
However a "host" or a "edge" should be able to activated or not.

Furthermore, in my opinion the NSIS protocol should be:
end host - end host: the NSIS protocol is terminated at end hosts;
end host - proxy: the NSIS protocol is terminated at end host and proxy;
end host - edge: the NSIS protocol is terminated at end end host and edge;
edge - edge: the NSIS protocol is terminated at egdes of one/multiple
domains;


Best regards,
Georgios


-----Original Message-----
From: Schneider, Marco [mailto:schneider@tri.sbc.com]
Sent: 18 January 2002 20:10
To: 'Roy, Radhika R, ALASO'; Gary Kenward; Loughney John (NRC/Helsinki);
brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
dick.rr.knight@bt.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


Hi Roy,

Below is the original text from your reponse to Gary Kenward. Hopefully the
context is clear.

"[Roy, Radhika R, ALARC]  I would say that it is the QOS needs of the
application (e.g., SIP-based VoIP) that the user likes to express (as
opposed to "service"). Similarly, instead of network services, we would say
network layer QOS services (e.g., RSVP, DiffServ, MPLS). We would develop
the end-to-end (application layer) QOS signaling protocol (say, NSIS QOS).
Now, there needs to have some kinds of standards how NSIS QOS will be mapped
over RSVP, DiffServ, MPLS, etc."

So by End-to-End you mean between directly between two "users". This is
session level signaling and I don't believe the signaling part is within the
scope of this working group. An application level QOS specification may be. 

After a session level agreement on QOS, the host/client/customer will need
to signal an actual reservation request to the network for the necessary QOS
agreed to at the session level. This is the protocol that we need to work
on. 

This approach is discussed in the SIP draft "SIP Extensions for Media
Authorization" (draft-ietf-sip-call-auth-03.txt) and the RAP draft
"Framework for session set-up with media authorization"
(draft-ietf-rap-session-auth-02.txt).

Marco Schneider

-----Original Message-----
From: Roy, Radhika R, ALASO [mailto:rrroy@att.com]
Sent: Friday, January 18, 2002 9:18 AM
To: Schneider, Marco; Gary Kenward; Loughney John (NRC/Helsinki);
brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
dick.rr.knight@bt.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


Defined below [RRR]

-----Original Message-----
From: Schneider, Marco [mailto:schneider@tri.sbc.com]
Sent: Thursday, January 17, 2002 8:47 PM
To: Roy, Radhika R, ALASO; Gary Kenward; Loughney John (NRC/Helsinki);
brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
dick.rr.knight@bt.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


Hi Roy,

Can you please define what you mean by "End-to-End Application Layer QOS
Signaling". Thanks.

[RRR] Suppose an user is initiation a SIP call to another user with audio,
video, and data. The use needs to express the needs of QOS for audio, video,
and data to another user. 

[RRR] The signaling mechanism that allows to express the QOS parameters of
audio, video, and data is termed as the "End-to-End Application Layer QOS
Signaling."

Marco Schneider

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

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

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

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



From daemon@optimus.ietf.org  Tue Jan 22 12:08:42 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00714
	for <nsis-archive@odin.ietf.org>; Tue, 22 Jan 2002 12:08:42 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id MAA29284
	for nsis-archive@odin.ietf.org; Tue, 22 Jan 2002 12:08: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 LAA23904;
	Tue, 22 Jan 2002 11:59: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 LAA23872
	for <nsis@optimus.ietf.org>; Tue, 22 Jan 2002 11:59:34 -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 LAA00360
	for <nsis@ietf.org>; Tue, 22 Jan 2002 11:59:29 -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 g0MH1bT07987;
	Tue, 22 Jan 2002 11:01:37 -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 g0MGwrL25750;
	Tue, 22 Jan 2002 10:58:58 -0600 (CST)
Received: by TRIMAIL2.ad.tri.sbc.com with Internet Mail Service (5.5.2653.19)
	id <ZND32YGH>; Tue, 22 Jan 2002 10:59:20 -0600
Message-ID: <905A1C4ABF353F4C8CC16FA9F53DD0D6322437@TRIMAIL2.ad.tri.sbc.com>
From: "Chen, Weijing" <wchen@tri.sbc.com>
To: "'Georgios Karagiannis (ELN)'" <Georgios.Karagiannis@eln.ericsson.se>,
        "Schneider, Marco" <schneider@tri.sbc.com>
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements
Date: Tue, 22 Jan 2002 10:59:20 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: nsis-admin@ietf.org
Errors-To: nsis-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Next Steps in Signaling <nsis.ietf.org>
X-BeenThere: nsis@ietf.org

Georgios,

Do you mean the "protocol component" in the same semantic of "information
element" or "information object" in traditional signaling protocol?



--
Weijing Chen
SBC Technology Resources
9505 Arboretum Blvd.
Austin, TX 78759
512 372 5710
wchen@tri.sbc.com


-----Original Message-----
From: Georgios Karagiannis (ELN)
[mailto:Georgios.Karagiannis@eln.ericsson.se] 
Sent: Tuesday, January 22, 2002 3:39 AM
To: Schneider, Marco
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements

Hi Marco

The possible NSIS protocol components that can be 
used on the different NSIS protocol types are the following:

 * used components in "end host to end host" NSIS scenario: 
      [everyhost], [everyedge], [everyhop]

 * used components in "end host to proxy" NSIS scenario: 
      [everyhost], [everyedge], [everyhop]

 * used components in "end host to edge" NSIS scenario: 
      [everyedge], [everyhop]
 
 * used components in "edge to edge" NSIS scenario: 
      [everyedge], [everyhop]

Regarding the priority, we should decide it after the requirements,
architecture and framework drafts are done!

Best regards,
Georgios

-----Original Message-----
From: Schneider, Marco [mailto:schneider@tri.sbc.com]
Sent: dinsdag 22 januari 2002 1:03
To: 'Georgios Karagiannis (ELN)'; 'dick.rr.knight@bt.com'
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


Hi Georgios, All

If by x -- y you mean a protocol that runs directly between x and y (e.g.
end host -- end host, end host -- proxy...) then strictly speaking we are
discussing four  functionally distinct interfaces and thus four functionally
distinct protocols(possibly three if we group end host -- proxy and  end
host -- edge together). In my opinion: First we need to decide which of
these interfaces are in scope. Second we need to decide which one(s) we will
address first. Third we need to define the requirements for each for each of
the interfaces independently. 

With respect to scope and priority, I think we need to address in order:
1) end host -- edge/proxy
2) domain edge -- domain edge

 
Marco


-----Original Message-----
From: Georgios Karagiannis (ELN)
[mailto:Georgios.Karagiannis@eln.ericsson.se]
Sent: Monday, January 21, 2002 4:30 AM
To: 'dick.rr.knight@bt.com'
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements



Hi Dick

Please see my comment in line:
[DK]>> I do agree that it need not be processed on a per hop basis as it can
[DK]>> transverse a domain with a single QoS mechanism. That mechanism, be
it
[DK]>> diffserv or intserv, PNNI, RSVP, or even over-provisioning, takes
care of
[DK]>> the policing and the "path" establishment within the domain.

Please note that at the moment there are scenarios that will need to 
process the [everyhop] component. Some of these scenarios are the Radio
Access
Network and Mobile IP,..
Therefore, the [everyhop] component should be supported by the NSIS
protocol.
However a "host" or a "edge" should be able to activated or not.

Furthermore, in my opinion the NSIS protocol should be:
end host - end host: the NSIS protocol is terminated at end hosts;
end host - proxy: the NSIS protocol is terminated at end host and proxy;
end host - edge: the NSIS protocol is terminated at end end host and edge;
edge - edge: the NSIS protocol is terminated at egdes of one/multiple
domains;


Best regards,
Georgios


-----Original Message-----
From: Schneider, Marco [mailto:schneider@tri.sbc.com]
Sent: 18 January 2002 20:10
To: 'Roy, Radhika R, ALASO'; Gary Kenward; Loughney John (NRC/Helsinki);
brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
dick.rr.knight@bt.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


Hi Roy,

Below is the original text from your reponse to Gary Kenward. Hopefully the
context is clear.

"[Roy, Radhika R, ALARC]  I would say that it is the QOS needs of the
application (e.g., SIP-based VoIP) that the user likes to express (as
opposed to "service"). Similarly, instead of network services, we would say
network layer QOS services (e.g., RSVP, DiffServ, MPLS). We would develop
the end-to-end (application layer) QOS signaling protocol (say, NSIS QOS).
Now, there needs to have some kinds of standards how NSIS QOS will be mapped
over RSVP, DiffServ, MPLS, etc."

So by End-to-End you mean between directly between two "users". This is
session level signaling and I don't believe the signaling part is within the
scope of this working group. An application level QOS specification may be. 

After a session level agreement on QOS, the host/client/customer will need
to signal an actual reservation request to the network for the necessary QOS
agreed to at the session level. This is the protocol that we need to work
on. 

This approach is discussed in the SIP draft "SIP Extensions for Media
Authorization" (draft-ietf-sip-call-auth-03.txt) and the RAP draft
"Framework for session set-up with media authorization"
(draft-ietf-rap-session-auth-02.txt).

Marco Schneider

-----Original Message-----
From: Roy, Radhika R, ALASO [mailto:rrroy@att.com]
Sent: Friday, January 18, 2002 9:18 AM
To: Schneider, Marco; Gary Kenward; Loughney John (NRC/Helsinki);
brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
dick.rr.knight@bt.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


Defined below [RRR]

-----Original Message-----
From: Schneider, Marco [mailto:schneider@tri.sbc.com]
Sent: Thursday, January 17, 2002 8:47 PM
To: Roy, Radhika R, ALASO; Gary Kenward; Loughney John (NRC/Helsinki);
brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
dick.rr.knight@bt.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


Hi Roy,

Can you please define what you mean by "End-to-End Application Layer QOS
Signaling". Thanks.

[RRR] Suppose an user is initiation a SIP call to another user with audio,
video, and data. The use needs to express the needs of QOS for audio, video,
and data to another user. 

[RRR] The signaling mechanism that allows to express the QOS parameters of
audio, video, and data is termed as the "End-to-End Application Layer QOS
Signaling."

Marco Schneider

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

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

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

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



From daemon@optimus.ietf.org  Tue Jan 22 12:45: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 MAA01958
	for <nsis-archive@odin.ietf.org>; Tue, 22 Jan 2002 12:45:09 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id MAA01028
	for nsis-archive@odin.ietf.org; Tue, 22 Jan 2002 12:45: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 MAA00730;
	Tue, 22 Jan 2002 12:35: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 MAA00698
	for <nsis@optimus.ietf.org>; Tue, 22 Jan 2002 12:35:10 -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 MAA01686
	for <nsis@ietf.org>; Tue, 22 Jan 2002 12:35:05 -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 g0MHbCT08196;
	Tue, 22 Jan 2002 11:37:12 -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 g0MHYOR27360;
	Tue, 22 Jan 2002 11:34:30 -0600 (CST)
Received: by TRIMAIL2.ad.tri.sbc.com with Internet Mail Service (5.5.2653.19)
	id <ZND32YP9>; Tue, 22 Jan 2002 11:34:52 -0600
Message-ID: <905A1C4ABF353F4C8CC16FA9F53DD0D6322438@TRIMAIL2.ad.tri.sbc.com>
From: "Chen, Weijing" <wchen@tri.sbc.com>
To: "'Gary Kenward'" <gkenward@nortelnetworks.com>,
        "Schneider, Marco"
	 <schneider@tri.sbc.com>,
        "'Roy, Radhika R, ALASO'" <rrroy@att.com>,
        "Loughney John (NRC/Helsinki)" <john.loughney@nokia.com>,
        brunner@ccrle.nec.de, Yaron Kahana <ykahana@comgates.co.il>,
        "Geib, Ruediger" <Ruediger.Geib@t-systems.com>, dick.rr.knight@bt.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements
Date: Tue, 22 Jan 2002 11:34:49 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C1A36B.17CB6B80"
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_01C1A36B.17CB6B80
Content-Type: text/plain

            

[gwk] I see the difference. I would say that I tend towards your definition,
in the 
following sense: the only QoS that matters is what the end-user sees, so as
a service 
characteristic, it must be provided between the two end systems / hosts. In
order to do 
this, however, some level of support is required at each hop along the path.


  So, establishing QoS between the end systems requires a peer-to-peer
agreement between 
the end systems, a host-to-cloud agreement for the transport of the packets,
and 
some mechanism within the cloud to ensure that the agreed upon QoS is
provided. 
Depending upon the complexity of the cloud, the latter could imply all sorts
of QoS 
agreements between networks and even nodes, for packet forwarding. 

[Chen, Weijing] Excellent statement.

  Note that I have purposely NOT stated that any of these agreements are
negotiated or 
require a signalling protocol. My opinion is that it is better in the long
term to 
support negotiated services using signalling, as it provides more
flexibility. However, 
this can be overdone, say, as a silly example, by having the end-system
negotiate with 
every node in the network. So, the compromise is that some of the QoS
agreements will 
be incorporated into the network design (e.g. Diff Serv), some will be
configured by 
the operator(s) (e.g. through traffic engineering and policy management),
and others 
will be signalled. NSIS seems to be about determining where signalling is
appropriate, 
and what are the signalling peers, and what is the best protocol solution or
solutions. 
The catch is that the first two approaches actually encompass a wide variety
of technologies 
and scenarios. 

[Chen, Weijing] From our experience the signaling is the necessary one.
Certainly if we extend the signaling to "having the end-system negotiate
with every node in the network", that would be very silly. Unfortunately
that is most of people thinking about how to do signaling. That is why we
are keeping emphasis on user-to-network and make it: a) independent of how
network doing QoS, b) multiprotocol (multidomain) capable of support
different transport layer.

  Sorry for stating the obvious. There is clearly some concern over the use,
for example, 
of RSVP, and I suspect that some people are concerned that "end-to-end
signalling" also 
means "hop-by-hop" ala RSVP. It could, but it does not have to. 

[Chen, Weijing] This is the danger tendency that most of us engineer fall
into. Signaling does not imply "hop-by-hop" for a single protocol. For
example, as the following diagram, we have at least two protocols: A and B
for "end-to-end" signaling.

[host]<--A--[hop]-->[edge]<--B--[hop]-->[edge]<--A--[hop]-->[host]

 

  So, my view is that NSIS needs to ensure that the end-to-end QoS is
provided for, and 
develope the protocols where they are needed (but not where they are not).
At this point, 
that would seem to be host to edge, edge to edge, and at the very least,
with enough 
end to end semantics to ensure that the complete path supports QoS. I am
concerned about 
node to node signalling, as there are so many different approaches to
supporting node-to-node 
QoS. At the very least, I would like to see a framework, and the edge
solutions defined 
before we delve into "intra-network" issues. 

[Chen, Weijing] Agreed.

--

Weijing Chen

SBC Technology Resources

9505 Arboretum Blvd.

Austin, TX 78759

512 372 5710

 <mailto:wchen@tri.sbc.com> wchen@tri.sbc.com

 

 


------_=_NextPart_001_01C1A36B.17CB6B80
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<html>

<head>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">


<meta name=Generator content="Microsoft Word 10 (filtered)">
<title>RE: [NSIS] Two kinds of requirements</title>

<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:"\@SimSun";
	panose-1:2 1 6 0 3 1 1 1 1 1;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:blue;
	text-decoration:underline;}
p
	{margin-right:0in;
	margin-left:0in;
	font-size:12.0pt;
	font-family:"Times New Roman";}
span.EmailStyle18
	{font-family:Arial;
	color:navy;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=EN-US link=blue vlink=blue>

<div class=Section1>

<p class=MsoNormal><font size=2 face=Tahoma><span style='font-size:10.0pt;
font-family:Tahoma'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></font></p>

<p><font size=2 face="Times New Roman"><span style='font-size:10.0pt'>[gwk] I
see the difference. I would say that I tend towards your definition, in the </span></font><br>
<font size=2><span style='font-size:10.0pt'>following sense: the only QoS that
matters is what the end-user sees, so as a service</span></font> <br>
<font size=2><span style='font-size:10.0pt'>characteristic, it must be provided
between the two end systems / hosts. In order to do </span></font><br>
<font size=2><span style='font-size:10.0pt'>this, however, some level of
support is required at each hop along the path. </span></font></p>

<p><font size=2 face="Times New Roman"><span style='font-size:10.0pt'>&nbsp;
So, establishing QoS between the end systems requires a peer-to-peer agreement
between</span></font> <br>
<font size=2><span style='font-size:10.0pt'>the end systems, a host-to-cloud
agreement for the transport of the packets, and </span></font><br>
<font size=2><span style='font-size:10.0pt'>some mechanism within the cloud to
ensure that the agreed upon QoS is provided.</span></font> <br>
<font size=2><span style='font-size:10.0pt'>Depending upon the complexity of
the cloud, the latter could imply all sorts of QoS</span></font> <br>
<font size=2><span style='font-size:10.0pt'>agreements between networks and
even nodes, for packet forwarding.</span></font> </p>

<p><font size=2 color=navy face=Arial><span style='font-size:10.0pt;font-family:
Arial;color:navy'>[Chen, Weijing] Excellent statement.</span></font></p>

<p><font size=2 face="Times New Roman"><span style='font-size:10.0pt'>&nbsp;
Note that I have purposely NOT stated that any of these agreements are
negotiated or</span></font> <br>
<font size=2><span style='font-size:10.0pt'>require a signalling protocol. My
opinion is that it is better in the long term to</span></font> <br>
<font size=2><span style='font-size:10.0pt'>support negotiated services using
signalling, as it provides more flexibility. However,</span></font> <br>
<font size=2><span style='font-size:10.0pt'>this can be overdone, say, as a
silly example, by having the end-system negotiate with</span></font> <br>
<font size=2><span style='font-size:10.0pt'>every node in the network. So, the
compromise is that some of the QoS agreements will</span></font> <br>
<font size=2><span style='font-size:10.0pt'>be incorporated into the network
design (e.g. Diff Serv), some will be configured by</span></font> <br>
<font size=2><span style='font-size:10.0pt'>the operator(s) (e.g. through
traffic engineering and policy management), and others</span></font> <br>
<font size=2><span style='font-size:10.0pt'>will be signalled. NSIS seems to be
about determining where signalling is appropriate,</span></font> <br>
<font size=2><span style='font-size:10.0pt'>and what are the signalling peers,
and what is the best protocol solution or solutions.</span></font> <br>
<font size=2><span style='font-size:10.0pt'>The catch is that the first two
approaches actually encompass a wide variety of technologies</span></font> <br>
<font size=2><span style='font-size:10.0pt'>and scenarios.</span></font> </p>

<p><font size=2 color=navy face=Arial><span style='font-size:10.0pt;font-family:
Arial;color:navy'>[Chen, Weijing] From our experience the signaling is the
necessary one. Certainly if we extend the signaling to "</span></font><font
size=2><span style='font-size:10.0pt'>having the end-system negotiate with</span></font>
<font size=2><span style='font-size:10.0pt'>every node in the network",
that would be very silly. Unfortunately that is most of people thinking about
how to do signaling. That is why we are keeping emphasis on user-to-network and
make it: a) independent of how network doing QoS, b) multiprotocol (multidomain)
capable of support different transport layer.</span></font></p>

<p><font size=2 face="Times New Roman"><span style='font-size:10.0pt'>&nbsp;
Sorry for stating the obvious. There is clearly some concern over the use, for
example,</span></font> <br>
<font size=2><span style='font-size:10.0pt'>of RSVP, and I suspect that some
people are concerned that &quot;end-to-end signalling&quot; also</span></font> <br>
<font size=2><span style='font-size:10.0pt'>means &quot;hop-by-hop&quot; ala
RSVP. It could, but it does not have to.</span></font> </p>

<p><font size=2 color=navy face=Arial><span style='font-size:10.0pt;font-family:
Arial;color:navy'>[Chen, Weijing] This is the danger tendency that most of us
engineer fall into. Signaling does not imply "hop-by-hop" for a
single protocol. For example, as the following diagram, we have at least two
protocols: A and B for "end-to-end" signaling.</span></font></p>

<p><font size=2 color=navy face=Arial><span style='font-size:10.0pt;font-family:
Arial;color:navy'>[host]&lt;--A--[hop]--&gt;[edge]&lt;--B--[hop]--&gt;[edge]&lt;--A--[hop]--&gt;[host]</span></font></p>

<p><font size=2 color=navy face=Arial><span style='font-size:10.0pt;font-family:
Arial;color:navy'>&nbsp;</span></font></p>

<p><font size=2 face="Times New Roman"><span style='font-size:10.0pt'>&nbsp;
So, my view is that NSIS needs to ensure that the end-to-end QoS is provided
for, and</span></font> <br>
<font size=2><span style='font-size:10.0pt'>develope the protocols where they
are needed (but not where they are not). At this point,</span></font> <br>
<font size=2><span style='font-size:10.0pt'>that would seem to be host to edge,
edge to edge, and at the very least, with enough</span></font> <br>
<font size=2><span style='font-size:10.0pt'>end to end semantics to ensure that
the complete path supports QoS. I am concerned about</span></font> <br>
<font size=2><span style='font-size:10.0pt'>node to node signalling, as there
are so many different approaches to supporting node-to-node</span></font> <br>
<font size=2><span style='font-size:10.0pt'>QoS. At the very least, I would
like to see a framework, and the edge solutions defined</span></font> <br>
<font size=2><span style='font-size:10.0pt'>before we delve into
&quot;intra-network&quot; issues.</span></font> </p>

<p><font size=2 color=navy face=Arial><span style='font-size:10.0pt;font-family:
Arial;color:navy'>[Chen, Weijing] Agreed.</span></font></p>

<p class=MsoNormal style='text-align:justify;text-justify:inter-ideograph'><i><font
size=2 color=navy face="Times New Roman"><span style='font-size:10.0pt;
color:navy;layout-grid-mode:line;font-style:italic'>--</span></font></i></p>

<p class=MsoNormal style='text-align:justify;text-justify:inter-ideograph'><i><font
size=2 color=navy face="Times New Roman"><span style='font-size:10.0pt;
color:navy;layout-grid-mode:line;font-style:italic'>Weijing Chen</span></font></i></p>

<p class=MsoNormal style='text-align:justify;text-justify:inter-ideograph'><i><font
size=2 color=navy face="Times New Roman"><span style='font-size:10.0pt;
color:navy;layout-grid-mode:line;font-style:italic'>SBC Technology Resources</span></font></i></p>

<p class=MsoNormal style='text-align:justify;text-justify:inter-ideograph'><i><font
  size=2 color=navy face="Times New Roman"><span style='font-size:10.0pt;
  color:navy;layout-grid-mode:line;font-style:italic'>9505 Arboretum Blvd.</span></font></i></p>

<p class=MsoNormal style='text-align:justify;text-justify:inter-ideograph'><i><font
  size=2 color=navy face="Times New Roman"><span style='font-size:10.0pt;
  color:navy;layout-grid-mode:line;font-style:italic'>Austin</span></font></i><i><font
 size=2 color=navy><span style='font-size:10.0pt;color:navy;layout-grid-mode:
 line;font-style:italic'>, </span></font></i><i><font size=2 color=navy><span
  style='font-size:10.0pt;color:navy;layout-grid-mode:line;font-style:italic'>TX</span></font></i><i><font
 size=2 color=navy><span style='font-size:10.0pt;color:navy;layout-grid-mode:
 line;font-style:italic'> </span></font></i><i><font size=2 color=navy><span
  style='font-size:10.0pt;color:navy;layout-grid-mode:line;font-style:italic'>78759</span></font></i></p>

<p class=MsoNormal style='text-align:justify;text-justify:inter-ideograph'><i><font
size=2 color=navy face="Times New Roman"><span style='font-size:10.0pt;
color:navy;layout-grid-mode:line;font-style:italic'>512 372 5710</span></font></i></p>

<p class=MsoNormal style='text-align:justify;text-justify:inter-ideograph'><i><font
size=2 color=navy face="Times New Roman"><span style='font-size:10.0pt;
color:navy;layout-grid-mode:line;font-style:italic'><a
href="mailto:wchen@tri.sbc.com"><span style='layout-grid-mode:both'>wchen@tri.sbc.com</span></a></span></font></i></p>

<p class=MsoNormal style='text-align:justify;text-justify:inter-ideograph'><i><font
size=2 color=navy face="Times New Roman"><span style='font-size:10.0pt;
color:navy;layout-grid-mode:line;font-style:italic'>&nbsp;</span></font></i></p>

<p><font size=2 color=navy face=Arial><span style='font-size:10.0pt;font-family:
Arial;color:navy'>&nbsp;</span></font></p>

</div>

</body>

</html>

------_=_NextPart_001_01C1A36B.17CB6B80--

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



From daemon@ns.ietf.org  Tue Jan 22 13:44:55 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04281
	for <nsis-archive@odin.ietf.org>; Tue, 22 Jan 2002 13:44:51 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id NAA03904
	for nsis-archive@odin.ietf.org; Tue, 22 Jan 2002 13:44: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 NAA03382;
	Tue, 22 Jan 2002 13:34: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 NAA03345
	for <nsis@ns.ietf.org>; Tue, 22 Jan 2002 13:34:33 -0500 (EST)
Received: from howler.tri.sbc.com (howler.tri.sbc.com [205.173.58.4])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03918
	for <nsis@ietf.org>; Tue, 22 Jan 2002 13:34:30 -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 g0MIacT08641;
	Tue, 22 Jan 2002 12:36:38 -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 g0MIXwN29822;
	Tue, 22 Jan 2002 12:33:58 -0600 (CST)
Received: by TRIMAIL2.ad.tri.sbc.com with Internet Mail Service (5.5.2653.19)
	id <ZND32Y8P>; Tue, 22 Jan 2002 12:34:25 -0600
Message-ID: <905A1C4ABF353F4C8CC16FA9F53DD0D638B9A8@TRIMAIL2.ad.tri.sbc.com>
From: "Schneider, Marco" <schneider@tri.sbc.com>
To: "'Georgios Karagiannis (ELN)'" <Georgios.Karagiannis@eln.ericsson.se>
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements
Date: Tue, 22 Jan 2002 12:34:20 -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

Georgios,

Are you suggesting that we organize our requirements according to the
implementation solution you have proposed below? If that is the case then I
strongly disagree. 

Marco
-----Original Message-----
From: Georgios Karagiannis (ELN)
[mailto:Georgios.Karagiannis@eln.ericsson.se]
Sent: Tuesday, January 22, 2002 3:39 AM
To: Schneider, Marco
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


Hi Marco

The possible NSIS protocol components that can be 
used on the different NSIS protocol types are the following:

 * used components in "end host to end host" NSIS scenario: 
      [everyhost], [everyedge], [everyhop]

 * used components in "end host to proxy" NSIS scenario: 
      [everyhost], [everyedge], [everyhop]

 * used components in "end host to edge" NSIS scenario: 
      [everyedge], [everyhop]
 
 * used components in "edge to edge" NSIS scenario: 
      [everyedge], [everyhop]

Regarding the priority, we should decide it after the requirements,
architecture and framework drafts are done!

Best regards,
Georgios

-----Original Message-----
From: Schneider, Marco [mailto:schneider@tri.sbc.com]
Sent: dinsdag 22 januari 2002 1:03
To: 'Georgios Karagiannis (ELN)'; 'dick.rr.knight@bt.com'
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


Hi Georgios, All

If by x -- y you mean a protocol that runs directly between x and y (e.g.
end host -- end host, end host -- proxy...) then strictly speaking we are
discussing four  functionally distinct interfaces and thus four functionally
distinct protocols(possibly three if we group end host -- proxy and  end
host -- edge together). In my opinion: First we need to decide which of
these interfaces are in scope. Second we need to decide which one(s) we will
address first. Third we need to define the requirements for each for each of
the interfaces independently. 

With respect to scope and priority, I think we need to address in order:
1) end host -- edge/proxy
2) domain edge -- domain edge

 
Marco


-----Original Message-----
From: Georgios Karagiannis (ELN)
[mailto:Georgios.Karagiannis@eln.ericsson.se]
Sent: Monday, January 21, 2002 4:30 AM
To: 'dick.rr.knight@bt.com'
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements



Hi Dick

Please see my comment in line:
[DK]>> I do agree that it need not be processed on a per hop basis as it can
[DK]>> transverse a domain with a single QoS mechanism. That mechanism, be
it
[DK]>> diffserv or intserv, PNNI, RSVP, or even over-provisioning, takes
care of
[DK]>> the policing and the "path" establishment within the domain.

Please note that at the moment there are scenarios that will need to 
process the [everyhop] component. Some of these scenarios are the Radio
Access
Network and Mobile IP,..
Therefore, the [everyhop] component should be supported by the NSIS
protocol.
However a "host" or a "edge" should be able to activated or not.

Furthermore, in my opinion the NSIS protocol should be:
end host - end host: the NSIS protocol is terminated at end hosts;
end host - proxy: the NSIS protocol is terminated at end host and proxy;
end host - edge: the NSIS protocol is terminated at end end host and edge;
edge - edge: the NSIS protocol is terminated at egdes of one/multiple
domains;


Best regards,
Georgios


-----Original Message-----
From: Schneider, Marco [mailto:schneider@tri.sbc.com]
Sent: 18 January 2002 20:10
To: 'Roy, Radhika R, ALASO'; Gary Kenward; Loughney John (NRC/Helsinki);
brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
dick.rr.knight@bt.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


Hi Roy,

Below is the original text from your reponse to Gary Kenward. Hopefully the
context is clear.

"[Roy, Radhika R, ALARC]  I would say that it is the QOS needs of the
application (e.g., SIP-based VoIP) that the user likes to express (as
opposed to "service"). Similarly, instead of network services, we would say
network layer QOS services (e.g., RSVP, DiffServ, MPLS). We would develop
the end-to-end (application layer) QOS signaling protocol (say, NSIS QOS).
Now, there needs to have some kinds of standards how NSIS QOS will be mapped
over RSVP, DiffServ, MPLS, etc."

So by End-to-End you mean between directly between two "users". This is
session level signaling and I don't believe the signaling part is within the
scope of this working group. An application level QOS specification may be. 

After a session level agreement on QOS, the host/client/customer will need
to signal an actual reservation request to the network for the necessary QOS
agreed to at the session level. This is the protocol that we need to work
on. 

This approach is discussed in the SIP draft "SIP Extensions for Media
Authorization" (draft-ietf-sip-call-auth-03.txt) and the RAP draft
"Framework for session set-up with media authorization"
(draft-ietf-rap-session-auth-02.txt).

Marco Schneider

-----Original Message-----
From: Roy, Radhika R, ALASO [mailto:rrroy@att.com]
Sent: Friday, January 18, 2002 9:18 AM
To: Schneider, Marco; Gary Kenward; Loughney John (NRC/Helsinki);
brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
dick.rr.knight@bt.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


Defined below [RRR]

-----Original Message-----
From: Schneider, Marco [mailto:schneider@tri.sbc.com]
Sent: Thursday, January 17, 2002 8:47 PM
To: Roy, Radhika R, ALASO; Gary Kenward; Loughney John (NRC/Helsinki);
brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
dick.rr.knight@bt.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


Hi Roy,

Can you please define what you mean by "End-to-End Application Layer QOS
Signaling". Thanks.

[RRR] Suppose an user is initiation a SIP call to another user with audio,
video, and data. The use needs to express the needs of QOS for audio, video,
and data to another user. 

[RRR] The signaling mechanism that allows to express the QOS parameters of
audio, video, and data is termed as the "End-to-End Application Layer QOS
Signaling."

Marco Schneider

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

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

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



From daemon@ns.ietf.org  Tue Jan 22 14:31: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 OAA06883
	for <nsis-archive@odin.ietf.org>; Tue, 22 Jan 2002 14:31:54 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id OAA07613
	for nsis-archive@odin.ietf.org; Tue, 22 Jan 2002 14:31: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 OAA06177;
	Tue, 22 Jan 2002 14:21: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 OAA06143
	for <nsis@ns.ietf.org>; Tue, 22 Jan 2002 14:21:04 -0500 (EST)
Received: from NS1.US.PRSERV.NET ([64.180.246.83])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA06087
	for <nsis@ietf.org>; Tue, 22 Jan 2002 14:20:59 -0500 (EST)
From: sydney@vkistudios.org
Message-Id: <200201221920.OAA06087@ietf.org>
Reply-To: seo@vkistudios.org
To: nsis@ietf.org
Mime-Version: 1.0
Content-Type: text/html; charset="iso-8859-1"
Date: Tue, 22 Jan 2002 11:24:33 -0800
Subject: [NSIS] ADV: Professional Internet Marketing
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

<HTML>
<HEAD>
<TITLE>Professional Internet Marketing, VKI Studios 1-866-733-8899</TITLE>
<META name="description" content="A web services company specializing dynamic Internet marketing">
<META name="keywords" content="Dynamic Internet Marketing">
<META http-equiv="CONTENT-LANGUAGE" content="English">
<META name="RATING" content="General">
<META name="distribution" content="global">
<META name="copyright" content="copyright 2002, VKI Studios">
<META name="robots" content="index,follow">
<META http-equiv=Expires content="O">
<LINK rel="stylesheet" href="http://www.vkistudios.com/css/vki.css" type="text/css">
</HEAD>

<BODY bgcolor="#FFFFFF" text="#000000" link="#990000" vlink="663333">
<TABLE width="550" border="0" cellspacing="0" cellpadding="2" align="center">
  <TR> 
    <TD class="newsletter" bgcolor="006699" width="190" align="center"> 
      <P><B><A href="http://www.vkistudios.com/form_internet_mkt.html"><BR>
        <IMG src="http://www.vkistudios.com/images/h_internet_mkt.gif" width="183" height="37" alt="VKI Studios - Internet Marketing Is Mission Critical For Your Business" border="0"></A><BR>
        <OBJECT classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000" codebase="http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=5,0,0,0" width="183" height="20">
          <PARAM name=movie value="http://www.vkistudios.com/swf/ani_email.swf">
          <PARAM name=quality value=high>
          <PARAM name="BGCOLOR" value="006699">
          <EMBED src="http://www.vkistudios.com/swf/ani_email.swf" quality=high pluginspage="http://www.macromedia.com/shockwave/download/index.cgi?P1_Prod_Version=ShockwaveFlash" type="application/x-shockwave-flash" width="183" height="20" bgcolor="006699">
          </EMBED> 
        </OBJECT><BR>
        &nbsp;</B></P>
    </TD>
    <TD class="promo_header" bgcolor="006699" valign="top" align="right" width="360"><FONT color="#FFFFFF"><B>1-866-733-8899</B></FONT>&nbsp;</TD>
  </TR>
  <TR> 
    <TD class="newsletter" colspan="2"> 
      <P><IMG src="http://www.vkistudios.com/images/shim_email0.gif" width="1" height="17"><B><FONT color="006699">&quot;VKI 
        increased our web traffic by 550%</FONT></B> which resulted in a 20% increase 
        in revenues in less than six months.&quot; John Keith-King, Curator, Granville 
        Island Museums.</P>
      <P>Would you like to see if you can achieve similar results? <BR>
        Call us at 1-866-733-8899 or fill out our <A href="http://www.vkistudios.com/form_internet_mkt.html">online 
        consultation</A> and receive a <B><FONT color="006699"><BR>
        FREE Search Engine Report<FONT size="-1"> (value $75.00)</FONT></FONT></B></P>
      <P><FONT color="#006699"><B><A href="http://www.vkistudios.com/form_internet_mkt.html"><IMG src="http://www.vkistudios.com/images/button_guarantee.gif" width="185" height="29" alt="Results Guaranteed" border="0"></A></B></FONT></P>
    </TD>
  </TR>
  <TR> 
    <TD class="newsletter" colspan="2">&nbsp;</TD>
  </TR>
  <TR> 
    <TD class="newsletter" valign="bottom" colspan="2"> 
      <P><FONT color="#006699"><B>THE BENEFITS</B></FONT></P>
    </TD>
  </TR>
  <TR> 
    <TD class="newsletter" colspan="2"> 
      <UL>
        <LI>Your website will become <FONT color="006699"><B>highly visible</B></FONT></LI>
        <LI>Your <FONT color="006699"><B>traffic will grow</B></FONT> exponentially</LI>
        <LI>Measurable and <FONT color="006699"><B>trackable results</B></FONT></LI>
        <LI>You will have an ongoing <FONT color="006699"><B>strategy that adapts 
          </B></FONT>as search engines change<BR>
        </LI>
      </UL>
    </TD>
  </TR>
  <TR> 
    <TD class="newsletter" colspan="2"><FONT color="#006699"><B> THE ELEVATION</B></FONT></TD>
  </TR>
  <TR> 
    <TD class="newsletter" colspan="2"> 
      <UL>
        <LI> Strategy development</LI>
        <LI>Keyword Formulation</LI>
        <LI>Creation of keyword &amp; description META tags</LI>
        <LI>Creation of keyword entry pages</LI>
        <LI>FTP file transfer to server</LI>
        <LI>Submission of web address (URL) to search engines</LI>
        <LI>Submission of web address (URL) to directory sites<BR>
          <A href="http://www.vkistudios.com/se_phase1.html">more info</A><BR>
        </LI>
      </UL>
    </TD>
  </TR>
  <TR> 
    <TD class="newsletter" colspan="2"><FONT color="#006699"><B>THE PUSH</B></FONT> 
      - ongoing maintenance includes:</TD>
  </TR>
  <TR> 
    <TD class="newsletter" colspan="2"> 
      <UL>
        <LI>Optimization - HTML optimization to be search engine friendly</LI>
        <LI>Submission - Proper submission protocol for each individual engine</LI>
        <LI>Registration - Verification of successful submissions</LI>
        <LI>Monitoring - Evaluation of server file logs for search engine activity</LI>
        <LI>Positioning - Fine-tuning of submitted pages</LI>
        <LI>Maintenance - Continuous attendance to all the above actions<BR>
          <A href="http://www.vkistudios.com/form_internet_mkt.html">Online consultation</A> 
        </LI>
      </UL>
    </TD>
  </TR>
  <TR> 
    <TD class="newsletter" colspan="2"> 
      <P>Many Search Engines are moving to paid listings so <B><FONT color="006699">ACT 
        NOW!</FONT></B><BR>
        <A href="http://www.vkistudios.com/form_internet_mkt.html">Contact us 
        today to take advantage of our limited time offer.</A></P>
      <P>Please call us: 1-866-733-8899 or (604) 733-1474 - <A href="http://www.vkistudios.com" target="_blank">VKI 
        Studios Inc.</A></P>
    </TD>
  </TR>
  <TR> 
    <TD class="newsletter" colspan="2"> 
      <P>&nbsp;</P>
    </TD>
  </TR>
  <TR>
    <TD class="newsletter" colspan="2">If you do not wish to receive further mailings, 
      please <A href="http://www.vkistudios.com/remove/unsubscribe.html">unsubscribe 
      here.</A></TD>
  </TR>
</TABLE>
<P>&nbsp;</P>
</BODY>
</HTML>

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



From daemon@ns.ietf.org  Tue Jan 22 15:36: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 PAA09412
	for <nsis-archive@odin.ietf.org>; Tue, 22 Jan 2002 15:36:25 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id PAA11673
	for nsis-archive@odin.ietf.org; Tue, 22 Jan 2002 15:36: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 PAA10777;
	Tue, 22 Jan 2002 15:23: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 PAA10706
	for <nsis@ns.ietf.org>; Tue, 22 Jan 2002 15:23:00 -0500 (EST)
Received: from arb-exchange1.cetaceannetworks.com ([63.127.199.216])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08969
	for <nsis@ietf.org>; Tue, 22 Jan 2002 15:22:56 -0500 (EST)
Received: by mail.cetaceannetworks.com with Internet Mail Service (5.5.2653.19)
	id <DGB67KLV>; Tue, 22 Jan 2002 15:19:55 -0500
Message-ID: <6D8664171C38D511B5AD0002B325CE6633EC79@mail.cetaceannetworks.com>
From: "Freytsis, Ilya" <ifreytsis@cetacean.com>
To: "'nsis@ietf.org'" <nsis@ietf.org>
Subject: RE: [NSIS] Two kinds of requirements
Date: Tue, 22 Jan 2002 15:19:54 -0500
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 PAA10707
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

Allen,

I think your suggestion to start with Use Cases can be very productive and
will help the group to move forward in two steps:
1. It will help to remove any terminology barriers (if any is still left) by
describing scenarios people have in their minds in very specific
(application/problem field) terms (no generalization is involved yet). This
way everybody gets on the same playing field while discussing cases. It
should clear clouds around such terms as end-to-end QoS, session level QoS,
application QoS etc.
2. When all cases are discussed and understood the generalization can be
made based on all of them with very little room left for misinterpretation.

Ilya Freytsis
Cetacean Networks Inc.
ph. (603) 766-6065
fax (603) 766-7190
ifreytsis@cetacean.com



From: "Allen, Keith" <kallen@tri.sbc.com>
To: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements
Date: Tue, 22 Jan 2002 08:34:10 -0600
charset="iso-8859-1"

Rüdiger,

I was, in fact, proposing a requirements document.  I was merely suggesting
that the requirements for the protocol be captured with a technique used in
the OO software industry (as well as elsewhere) called Use Cases.  The idea
behind Use Cases, simply put, is to describe the requirements for a system
from the user's point of view.  This is done with a set of use cases, each
one being a scenario describing how the user utilizes the system to
accomplish some task.  The descriptions of all the tasks performed by the
user represent the requirements the system must meet.  I have not seen Use
Cases applied to protocol development but I see no reason why it couldn't
be.  Simply identifying the user will help us to settle all these
edge-host-hop-proxy discussions.

Use cases are good at capturing functional requirements, but aren't so
applicable to other types of requirements.  For example, if someone out
there is insistent that one of the requirements is "Must interwork with
RSVP-TE," that's not so easily captured in a use case.  If we decide to use
Use Cases we might have to amend them with more traditional requirements.


Keith Allen
SBC Technology Resources
9505 Arboretum Blvd.
Austin, TX 78759
(512) 372-5741
kallen@tri.sbc.com

This e-mail and any files transmitted with it are the property of SBC, are
confidential, and are intended solely for the use of the individual or
entity to whom this e-mail is addressed. If you are not one of the named
recipient(s) or otherwise have reason to believe that you have received this
message in error, please notify the sender at (512) 372-5000 and delete this
message immediately from your computer. Any other use, retention,
dissemination, forwarding, printing, or copying of this e-mail is strictly
prohibited.


 -----Original Message-----
From: 	Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] 
Sent:	Tuesday, January 22, 2002 3:05 AM
To:	Allen, Keith
Cc:	nsis@ietf.org
Subject:	RE: [NSIS] Two kinds of requirements

Allen,

I'm not sure on IETF terminology, but what you suggest may be a framework
document. As framework documents are usual if new IETF activities begin,
your suggestion is a good one. I'd however favour a requirements document. I
am volunteering to co-author one (means contribution and review). 

Regards, Rüdiger

> Along the lines of my earlier reference to Use Cases, what do 
> you think about beginning to document the requirements the
> protocol should meet as a set of use cases describing how
> network users (or actually  their network devices) use the
> protocol-to-be to access the QoS capabilities of the
> network.  For example, one use case could show a voice over
> IP caller, another a network administrator setting up an
> Ethernet VPN, etc.  If the protocol has to support mobile
> handoffs, we would have a use  case showing
> that. It would give us a focal point instead of just e-mail.
 


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



From daemon@ns.ietf.org  Tue Jan 22 15:45: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 PAA09657
	for <nsis-archive@odin.ietf.org>; Tue, 22 Jan 2002 15:45:02 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id PAA11922
	for nsis-archive@odin.ietf.org; Tue, 22 Jan 2002 15:45: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 PAA11578;
	Tue, 22 Jan 2002 15:34:53 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA11547
	for <nsis@ns.ietf.org>; Tue, 22 Jan 2002 15:34:50 -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 PAA09357
	for <nsis@ietf.org>; Tue, 22 Jan 2002 15:34:45 -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 g0MKarT09565;
	Tue, 22 Jan 2002 14:36:53 -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 g0MKYCW04751;
	Tue, 22 Jan 2002 14:34:12 -0600 (CST)
Received: by TRIMAIL2.ad.tri.sbc.com with Internet Mail Service (5.5.2653.19)
	id <ZND32Z5C>; Tue, 22 Jan 2002 14:34:39 -0600
Message-ID: <905A1C4ABF353F4C8CC16FA9F53DD0D638B9A9@TRIMAIL2.ad.tri.sbc.com>
From: "Schneider, Marco" <schneider@tri.sbc.com>
To: "'Gary Kenward'" <gkenward@nortelnetworks.com>,
        "'Roy, Radhika R, ALASO'" <rrroy@att.com>,
        "Loughney John (NRC/Helsinki)"
	 <john.loughney@nokia.com>,
        brunner@ccrle.nec.de, Yaron Kahana
	 <ykahana@comgates.co.il>,
        "Geib, Ruediger" <Ruediger.Geib@t-systems.com>, dick.rr.knight@bt.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements
Date: Tue, 22 Jan 2002 14:34:34 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C1A384.340D1E10"
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_01C1A384.340D1E10
Content-Type: text/plain;
	charset="iso-8859-1"

Gary,

-----Original Message-----
From: Gary Kenward [mailto:gkenward@nortelnetworks.com]
Sent: Tuesday, January 22, 2002 9:02 AM
To: Schneider, Marco; 'Roy, Radhika R, ALASO'; Loughney John (NRC/Helsinki);
brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger; dick.rr.knight@bt.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements



Marco: 

-----Original Message----- 
> [MS]  Yes, exactly. 
>   I don't believe you are proposing a "layering" of signalling protocols, 
> one for session establishment, then one for transport, etc. 
> [MS]  This is exactly what has been proposed in RAP and SIP working groups
to the best 
> of my understanding. Because there does not exist a proxy signaling
capability that 
> allows a session to setup a connection on the users behalf, the session
forwards a 
> token to the end-system and then the end-system includes that token in the
RSVP path 
> message so that the reservation will go through. In this manner the
session layer does 
> not need to communicate directly with the transport layer. 

[gwk] I do not understand what "the session" represents in the above. It
would seem 
to me that you must have a session level entity, and that to "forward a
token to the 
end-system", it must have an interface/api to the "end-system". If this
"end-system" 
is including tokens in RSVP, then it is the entity setting up the transport
QoS (although 
it is not necessarly a transport layer entity, but rather a signalling
entity. If these 
two entites are co-located, then you do not have layered signalling
protocols. 

Have I missed something? 

[Schneider, Marco] I don't think you have missed anything. I may not have
understood what you meant by a layering of signaling protocols. Please
define this.

BTW: for many links, particularly wireless, layered signalling is not a good
idea. 
And, in general, layered signalling will always be slower then a single
signalling protocol. 
> So, the question, 
> becomes, how are the QoS transport mechanisms established? In the internet

> model there is only one end-to-end transport session (e.g. TCP, RTP, UDP),

> but underneath the transport is a series of inter-connected networks, each

> with potentially different characteristics. 
>   This is end-to-end QoS support structure has to be set up and maintained

> in order for the end to end session QoS to be realized. The solution may
be 
> a single protocol that travels from host to host, such as RSVP, or it may 
> be a collection of protocols that are optimized for each portion of the 
> end-to-end path: e.g. host to access network, access to core network, 
> core to core network, etc. 
>   It is too early to determine which approach is best, but in either case,

> do we not need to understand the end-to-end requirements for this
signalling 
> capability? 
> [MS]  So by end-to-end you are referring to both the end-systems and the
devices in 
> between. As a point of clarification, I asked Roy what he meant by
"End-to-End 
> Application Layer QOS Signaling" and his answer implied user (end-system)
to user (end- 
> system).  We have been using the term end-to-end in different ways
(contexts). The way 
> I normally use the term "end-to-end" is to include everything in between
(all the 
> hops). 

[gwk] I see the difference. I would say that I tend towards your definition,
in the 
following sense: the only QoS that matters is what the end-user sees, so as
a service 
characteristic, it must be provided between the two end systems / hosts. In
order to do 
this, however, some level of support is required at each hop along the path.

For me the term end-to-end (for example end-to-end call flow) includes the
components within the network that must come together to make it work. The
term end-to-end application level signaling seems like an oxymoron since
this signaling occurs with no involvement of the network except to transfer
the data packets but perhaps there is something I am missing. 

 So, establishing QoS between the end systems requires a peer-to-peer
agreement between 
the end systems, a host-to-cloud agreement for the transport of the packets,
and 
some mechanism within the cloud to ensure that the agreed upon QoS is
provided. 
Depending upon the complexity of the cloud, the latter could imply all sorts
of QoS 
agreements between networks and even nodes, for packet forwarding. 

  Note that I have purposely NOT stated that any of these agreements are
negotiated or 
require a signalling protocol. My opinion is that it is better in the long
term to 
support negotiated services using signalling, as it provides more
flexibility. However, 
this can be overdone, say, as a silly example, by having the end-system
negotiate with 
every node in the network. So, the compromise is that some of the QoS
agreements will 
be incorporated into the network design (e.g. Diff Serv), some will be
configured by 
the operator(s) (e.g. through traffic engineering and policy management),
and others 
will be signalled. NSIS seems to be about determining where signalling is
appropriate, 
and what are the signalling peers, and what is the best protocol solution or
solutions. 
The catch is that the first two approaches actually encompass a wide variety
of technologies 
and scenarios. 
[Schneider, Marco]  I think you have articulated this very well and I am in
general agreement. 

  Sorry for stating the obvious. There is clearly some concern over the use,
for example, 
of RSVP, and I suspect that some people are concerned that "end-to-end
signalling" also 
means "hop-by-hop" ala RSVP. It could, but it does not have to. 
[Schneider, Marco] I think this is a very important distinction. I think
that the reverse is true as well in that some people are assuming a hop by
hop linear signaling model wherein the signaling takes place in order along
the path that the data will follow. The transport signaling that is going to
occur within the core of our network will be at a different timescale than
UNI signaling and there are a variety of solutions for this including
RSVP-te and CR-LDP which were developed for the purpose of allocating
traffic trunks.

  So, my view is that NSIS needs to ensure that the end-to-end QoS is
provided for, and 
develope the protocols where they are needed (but not where they are not).
At this point, 
that would seem to be host to edge, edge to edge, and at the very least,
with enough 
end to end semantics to ensure that the complete path supports QoS. I am
concerned about 
node to node signalling, as there are so many different approaches to
supporting node-to-node 
QoS. At the very least, I would like to see a framework, and the edge
solutions defined 
before we delve into "intra-network" issues. 
[Schneider, Marco] I think it all begins with the fact that a user must be
able to request a QOS/COS connection/flow to another user. If we can't do
that then everything else would appear to be pointless. The next question is
whether we want to develop protocols that assist the network portion in
delivering this capability and in what context(s).


BTW: in writing this, it dawned upon me that it might be best to write a
series of 
requirements rather then just one - i.e. tackle the problem piece by piece.
This approach 
does have drawbacks, but working groups seem to work better when they focus
on contained 
problem domains. A strawman framework might be useful in keeping the
incremental solutions 
coherent. 
[Schneider, Marco] I agree with the idea of tackling the requirements by
breaking the problem up. There is a catch 22 in that in order to breakup it
up we must to some degree presuppose a solution. 


> [MS] I think our basic requirement is that an end-system be able to
request (and 
> receive) a QOS connection to some other end-system (NSIS UNI). The request
part entails 
> an NSIS UNI. As you say the realization of this request can be achieved in
a number of 
> different ways. Now one solution is to invent an NSIS NNI that runs
between domains. If 
> we develop requirements for such an NSIS UNI then we have already
preproposed a 
> solution ahead of requirements. 

[gwk] We have to be extremely careful not to become pre-occupied with
requirements 
definition. All productive requirements definition efforts begin with
assumptions 
concerning the solution. In my view, requirements specifications are a
balance between 
presumption and prediction, particularly when dealing with "soft"
techologies such as 
protocols. The issue really is not whether a requirement is a "MAY" or a
"SHOULD" or 
whatever, the issue is whether a requirement actually helps us define the
solution 
(there are lot's of examples of "SHOULD" requirements that do not bring
value to the 
design process). 
[Schneider, Marco] I think there is a danger in implicit assumptions that
may not lead to the best solution. With respect to network support of a QOS
request, there are many different solutions and I am afraid that some
participants have presupposed a hop by hop signaling solution. 

Given my observation above about writing a series of requirements, I would
recommend 
that we roughly map out the solution(some would call this a "framework").
This map would 
form the preliminary list of deliverables for the wg charter, and then pick
a focussed 
problem area to begin with requirements. This is not "top down" design, but
"top down" 
processes seldom work. If this seems too abstract, what I am saying is that
I have no 
problem identifying that there are N problem areas to be addressed - e.g.
host to edge, 
edge to edge, node to node, etc. - and picking anyone for the first design
attempt. Of 
course, the challenge would be to keep an eye on the "big picture" or
end-to-end 
requirements in the process. 
[Schneider, Marco] I think that the network context for supporting NSIS UNI
is a quagmire, albeit a very fun one. The problems we need to address depend
upon what end-to-end architectures we wish to support. There are a number of
capabilities already being developed for network QOS and there may be a
number of ways to "glue" these together.

Deludedly yours,

Marco

Just my deluded point of view. 
Cheers, 
Gary 

[Schneider, Marco]  
*snip* 


------_=_NextPart_001_01C1A384.340D1E10
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">
<TITLE>RE: [NSIS] Two kinds of requirements</TITLE>

<META content="MSHTML 5.50.4616.200" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=943153919-22012002><FONT face=Arial color=#0000ff 
size=2>Gary,</FONT></SPAN></DIV>
<BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Gary Kenward 
  [mailto:gkenward@nortelnetworks.com]<BR><B>Sent:</B> Tuesday, January 22, 2002 
  9:02 AM<BR><B>To:</B> Schneider, Marco; 'Roy, Radhika R, ALASO'; Loughney John 
  (NRC/Helsinki); brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger; 
  dick.rr.knight@bt.com<BR><B>Cc:</B> nsis@ietf.org<BR><B>Subject:</B> RE: 
  [NSIS] Two kinds of requirements<BR><BR></FONT></DIV>
  <P><FONT size=2>Marco:</FONT> </P>
  <P><FONT size=2>-----Original Message-----</FONT> <BR><FONT size=2>&gt; 
  [MS]&nbsp; Yes, exactly.</FONT> <BR><FONT size=2>&gt;&nbsp;&nbsp; I don't 
  believe you are proposing a "layering" of signalling protocols, 
  </FONT><BR><FONT size=2>&gt; one for session establishment, then one for 
  transport, etc. </FONT><BR><FONT size=2>&gt; [MS]&nbsp; This is exactly what 
  has been proposed in RAP and SIP working groups to the best </FONT><BR><FONT 
  size=2>&gt; of my understanding. Because there does not exist a proxy 
  signaling capability that </FONT><BR><FONT size=2>&gt; allows a session to 
  setup a connection on the users behalf, the session forwards a 
  </FONT><BR><FONT size=2>&gt; token to the end-system and then the end-system 
  includes that token in the RSVP path </FONT><BR><FONT size=2>&gt; message so 
  that the reservation will go through. In this manner the session layer does 
  </FONT><BR><FONT size=2>&gt; not need to communicate directly with the 
  transport layer.</FONT> </P>
  <P><FONT size=2>[gwk] I do not understand what "the session" represents in the 
  above. It would seem </FONT><BR><FONT size=2>to me that you must have a 
  session level entity, and that to "forward a token to the</FONT> <BR><FONT 
  size=2>end-system", it must have an interface/api to the "end-system". If this 
  "end-system"</FONT> <BR><FONT size=2>is including tokens in RSVP, then it is 
  the entity setting up the transport QoS (although</FONT> <BR><FONT size=2>it 
  is not necessarly a transport layer entity, but rather a signalling entity. If 
  these</FONT> <BR><FONT size=2>two entites are co-located, then you do not have 
  layered signalling protocols.</FONT> </P>
  <P><FONT size=2>Have I missed something?</FONT> </P>
  <P><FONT size=2><SPAN class=943153919-22012002><FONT face=Arial color=#0000ff 
  size=2>[Schneider, Marco]&nbsp;I don't think you have missed anything. I may 
  not have understood what you meant by a layering of signaling 
  protocols.</FONT></SPAN><SPAN class=943153919-22012002><FONT 
  size=3>&nbsp;</FONT><FONT face=Arial color=#0000ff size=2>Please define 
  this.</FONT></SPAN></FONT></P>
  <P><FONT size=2><SPAN class=943153919-22012002></SPAN>BTW: for many links, 
  particularly wireless, layered signalling is not a good idea.</FONT> <BR><FONT 
  size=2>And, in general, layered signalling will always be slower then a single 
  signalling protocol.</FONT> <BR><FONT size=2>&gt; So, the question, 
  </FONT><BR><FONT size=2>&gt; becomes, how are the QoS transport mechanisms 
  established? In the internet </FONT><BR><FONT size=2>&gt; model there is only 
  one end-to-end transport session (e.g. TCP, RTP, UDP), </FONT><BR><FONT 
  size=2>&gt; but underneath the transport is a series of inter-connected 
  networks, each </FONT><BR><FONT size=2>&gt; with potentially different 
  characteristics. </FONT><BR><FONT size=2>&gt;&nbsp;&nbsp; This is end-to-end 
  QoS support structure has to be set up and maintained </FONT><BR><FONT 
  size=2>&gt; in order for the end to end session QoS to be realized. The 
  solution may be </FONT><BR><FONT size=2>&gt; a single protocol that travels 
  from host to host, such as RSVP, or it may </FONT><BR><FONT size=2>&gt; be a 
  collection of protocols that are optimized for each portion of the 
  </FONT><BR><FONT size=2>&gt; end-to-end path: e.g. host to access network, 
  access to core network, </FONT><BR><FONT size=2>&gt; core to core network, 
  etc. </FONT><BR><FONT size=2>&gt;&nbsp;&nbsp; It is too early to determine 
  which approach is best, but in either case, </FONT><BR><FONT size=2>&gt; do we 
  not need to understand the end-to-end requirements for this signalling 
  </FONT><BR><FONT size=2>&gt; capability? </FONT><BR><FONT size=2>&gt; 
  [MS]&nbsp; So by end-to-end you are referring to both the end-systems and the 
  devices in </FONT><BR><FONT size=2>&gt; between. As a point of clarification, 
  I asked Roy what he meant by "End-to-End </FONT><BR><FONT size=2>&gt; 
  Application Layer QOS Signaling" and his answer implied user (end-system) to 
  user (end-</FONT> <BR><FONT size=2>&gt; system).&nbsp; We have been using the 
  term end-to-end in different ways (contexts). The way </FONT><BR><FONT 
  size=2>&gt; I normally use the term "end-to-end" is to include everything in 
  between (all the </FONT><BR><FONT size=2>&gt; hops). </FONT></P>
  <P><FONT size=2>[gwk] I see the difference. I would say that I tend towards 
  your definition, in the </FONT><BR><FONT size=2>following sense: the only QoS 
  that matters is what the end-user sees, so as a service</FONT> <BR><FONT 
  size=2>characteristic, it must be provided between the two end systems / 
  hosts. In order to do </FONT><BR><FONT size=2>this, however, some level of 
  support is required at each hop along the path. <BR><FONT face=Arial><FONT 
  color=#0000ff><SPAN class=943153919-22012002><SPAN 
  class=943153919-22012002>For me the term end-to-end (for example end-to-end 
  call flow) includes </SPAN>the components within the network that must come 
  together to make it work. The term end-to-end application level signaling 
  seems like an oxymoron since this signaling occurs with no involvement of the 
  network except to transfer the data packets but perhaps there is something I 
  am missing. </SPAN></FONT></FONT></FONT></P>
  <P><FONT size=2><SPAN class=943153919-22012002>&nbsp;</SPAN>So, establishing 
  QoS between the end systems requires a peer-to-peer agreement between</FONT> 
  <BR><FONT size=2>the end systems, a host-to-cloud agreement for the transport 
  of the packets, and </FONT><BR><FONT size=2>some mechanism within the cloud to 
  ensure that the agreed upon QoS is provided.</FONT> <BR><FONT size=2>Depending 
  upon the complexity of the cloud, the latter could imply all sorts of 
  QoS</FONT> <BR><FONT size=2>agreements between networks and even nodes, for 
  packet forwarding.</FONT> </P>
  <P><FONT size=2>&nbsp; Note that I have purposely NOT stated that any of these 
  agreements are negotiated or</FONT> <BR><FONT size=2>require a signalling 
  protocol. My opinion is that it is better in the long term to</FONT> <BR><FONT 
  size=2>support negotiated services using signalling, as it provides more 
  flexibility. However,</FONT> <BR><FONT size=2>this can be overdone, say, as a 
  silly example, by having the end-system negotiate with</FONT> <BR><FONT 
  size=2>every node in the network. So, the compromise is that some of the QoS 
  agreements will</FONT> <BR><FONT size=2>be incorporated into the network 
  design (e.g. Diff Serv), some will be configured by</FONT> <BR><FONT 
  size=2>the operator(s) (e.g. through traffic engineering and policy 
  management), and others</FONT> <BR><FONT size=2>will be signalled. NSIS seems 
  to be about determining where signalling is appropriate,</FONT> <BR><FONT 
  size=2>and what are the signalling peers, and what is the best protocol 
  solution or solutions.</FONT> <BR><FONT size=2>The catch is that the first two 
  approaches actually encompass a wide variety of technologies</FONT> <BR><FONT 
  size=2>and scenarios.</FONT> <BR><FONT face=Arial><FONT color=#0000ff><FONT 
  size=2><SPAN class=943153919-22012002>[</SPAN>Schneider, Marco]&nbsp;&nbsp;I 
  think you have articulated this very well and I am in general 
  agreement.&nbsp;</FONT></FONT></FONT></P>
  <P><FONT size=2>&nbsp; Sorry for stating the obvious. There is clearly some 
  concern over the use, for example,</FONT> <BR><FONT size=2>of RSVP, and I 
  suspect that some people are concerned that "end-to-end signalling" 
  also</FONT> <BR><FONT size=2>means "hop-by-hop" ala RSVP. It could, but it 
  does not have to.</FONT> <BR><SPAN class=943153919-22012002><FONT face=Arial 
  color=#0000ff size=2>[Schneider, Marco]&nbsp;I think this is a very important 
  distinction. I think that the reverse is true as well in that some people are 
  assuming a hop by hop linear signaling model wherein the signaling takes place 
  in order along the path that the data will follow. The transport signaling 
  that is going to occur within the core&nbsp;of our&nbsp;network will be at a 
  different timescale than UNI signaling and there are a variety of solutions 
  for this including RSVP-te and CR-LDP which were developed for the purpose of 
  allocating traffic trunks.</FONT></SPAN></P>
  <P><SPAN class=943153919-22012002></SPAN><FONT size=2>&nbsp; So, my view is 
  that NSIS needs to ensure that the end-to-end QoS is provided for, and</FONT> 
  <BR><FONT size=2>develope the protocols where they are needed (but not where 
  they are not). At this point,</FONT> <BR><FONT size=2>that would seem to be 
  host to edge, edge to edge, and at the very least, with enough</FONT> 
  <BR><FONT size=2>end to end semantics to ensure that the complete path 
  supports QoS. I am concerned about</FONT> <BR><FONT size=2>node to node 
  signalling, as there are so many different approaches to supporting 
  node-to-node</FONT> <BR><FONT size=2>QoS. At the very least, I would like to 
  see a framework, and the edge solutions defined</FONT> <BR><FONT size=2>before 
  we delve into "intra-network" issues.</FONT> <BR><SPAN 
  class=943153919-22012002><FONT face=Arial color=#0000ff size=2>[Schneider, 
  Marco]&nbsp;I think it all begins with the fact that a user must be able to 
  request a QOS/COS connection/flow to another user. If we can't do that then 
  everything else would appear to be pointless. The next question is whether we 
  want to develop protocols that assist the network portion&nbsp;in delivering 
  this capability and in what context(s).</FONT></SPAN><BR></P><SPAN 
  class=943153919-22012002><FONT face=Arial color=#0000ff size=2></FONT></SPAN>
  <P><FONT size=2>BTW: in writing this, it dawned upon me that it might be best 
  to write a series of</FONT> <BR><FONT size=2>requirements rather then just one 
  - i.e. tackle the problem piece by piece. This approach</FONT> <BR><FONT 
  size=2>does have drawbacks, but working groups seem to work better when they 
  focus on contained</FONT> <BR><FONT size=2>problem domains. A strawman 
  framework might be useful in keeping the incremental solutions</FONT> 
  <BR><FONT size=2>coherent.</FONT> <BR><SPAN class=943153919-22012002><FONT 
  face=Arial color=#0000ff size=2>[Schneider, Marco]&nbsp;I agree with the idea 
  of tackling the requirements by breaking the problem up. There is a catch 22 
  in that in order to breakup it up we must to some degree presuppose a 
  solution.&nbsp;</FONT></SPAN></P><BR>
  <P><FONT size=2>&gt; [MS] I think our basic requirement is that an end-system 
  be able to request (and </FONT><BR><FONT size=2>&gt; receive) a QOS connection 
  to some other end-system (NSIS UNI). The request part entails </FONT><BR><FONT 
  size=2>&gt; an NSIS UNI. As you say the realization of this request can be 
  achieved in a number of </FONT><BR><FONT size=2>&gt; different ways. Now one 
  solution is to invent an NSIS NNI that runs between domains. If 
  </FONT><BR><FONT size=2>&gt; we develop requirements for such an NSIS UNI then 
  we have already preproposed a </FONT><BR><FONT size=2>&gt; solution ahead of 
  requirements. </FONT></P>
  <P><FONT size=2>[gwk] We have to be extremely careful not to become 
  pre-occupied with requirements</FONT> <BR><FONT size=2>definition. All 
  productive requirements definition efforts begin with assumptions 
  </FONT><BR><FONT size=2>concerning the solution. In my view, requirements 
  specifications are a balance between</FONT> <BR><FONT size=2>presumption and 
  prediction, particularly when dealing with "soft" techologies such as</FONT> 
  <BR><FONT size=2>protocols. The issue really is not whether a requirement is a 
  "MAY" or a "SHOULD" or</FONT> <BR><FONT size=2>whatever, the issue is whether 
  a requirement actually helps us define the solution</FONT> <BR><FONT 
  size=2>(there are lot's of examples of "SHOULD" requirements that do not bring 
  value to the</FONT> <BR><FONT size=2>design process).</FONT> <BR><SPAN 
  class=943153919-22012002><FONT face=Arial color=#0000ff size=2>[Schneider, 
  Marco]&nbsp;I think there is a danger in implicit assumptions that may not 
  lead to the best solution. With&nbsp;respect to network support of a&nbsp;QOS 
  request, there are many different solutions and I am afraid that some 
  participants have presupposed a hop by hop signaling 
  solution.&nbsp;</FONT></SPAN></P>
  <P><FONT size=2>Given my observation above about writing a series of 
  requirements, I would recommend </FONT><BR><FONT size=2>that we roughly map 
  out the solution(some would call this a "framework"). This map would 
  </FONT><BR><FONT size=2>form the preliminary list of deliverables for the wg 
  charter, and then pick a focussed </FONT><BR><FONT size=2>problem area to 
  begin with requirements. This is not "top down" design, but "top down" 
  </FONT><BR><FONT size=2>processes seldom work. If this seems too abstract, 
  what I am saying is that I have no </FONT><BR><FONT size=2>problem identifying 
  that there are N problem areas to be addressed - e.g. host to edge, 
  </FONT><BR><FONT size=2>edge to edge, node to node, etc. - and picking anyone 
  for the first design attempt. Of </FONT><BR><FONT size=2>course, the challenge 
  would be to keep an eye on the "big picture" or end-to-end </FONT><BR><FONT 
  size=2>requirements in the process.</FONT> <BR><SPAN 
  class=943153919-22012002><FONT face=Arial color=#0000ff size=2>[Schneider, 
  Marco]&nbsp;I think that the network context for supporting NSIS UNI is a 
  quagmire, albeit a very fun one. The problems we need to address depend upon 
  what end-to-end architectures we wish to support. There are a number of 
  capabilities already being developed for network QOS and there may be a number 
  of ways to "glue" these together.</FONT></SPAN></P>
  <P><SPAN class=943153919-22012002><FONT face=Arial color=#0000ff 
  size=2>Deludedly yours,</FONT></SPAN></P>
  <P><SPAN class=943153919-22012002><FONT face=Arial color=#0000ff 
  size=2>Marco</FONT></SPAN></P>
  <P><SPAN class=943153919-22012002></SPAN><FONT size=2>Just my deluded point of 
  view.</FONT> <BR><FONT size=2>Cheers,</FONT> <BR><FONT size=2>Gary</FONT> </P>
  <P><FONT size=2>[Schneider, Marco]&nbsp; </FONT><BR><FONT size=2>*snip*</FONT> 
  </P></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C1A384.340D1E10--

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



From daemon@ns.ietf.org  Tue Jan 22 15:58: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 PAA10049
	for <nsis-archive@odin.ietf.org>; Tue, 22 Jan 2002 15:58:21 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id PAA12241
	for nsis-archive@odin.ietf.org; Tue, 22 Jan 2002 15:58: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 PAA11895;
	Tue, 22 Jan 2002 15:44: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 PAA11822
	for <nsis@ns.ietf.org>; Tue, 22 Jan 2002 15:44:08 -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 PAA09646
	for <nsis@ietf.org>; Tue, 22 Jan 2002 15:44:04 -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 g0MKkCT09649;
	Tue, 22 Jan 2002 14:46:12 -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 g0MKhXu05114;
	Tue, 22 Jan 2002 14:43:33 -0600 (CST)
Received: by TRIMAIL2.ad.tri.sbc.com with Internet Mail Service (5.5.2653.19)
	id <ZND32Z7G>; Tue, 22 Jan 2002 14:44:00 -0600
Message-ID: <905A1C4ABF353F4C8CC16FA9F53DD0D638B9AA@TRIMAIL2.ad.tri.sbc.com>
From: "Schneider, Marco" <schneider@tri.sbc.com>
To: "'Freytsis, Ilya'" <ifreytsis@cetacean.com>,
        "'nsis@ietf.org'"
	 <nsis@ietf.org>
Subject: RE: [NSIS] Two kinds of requirements
Date: Tue, 22 Jan 2002 14:43:55 -0600
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 PAA11823
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

Ilya,

I agree wholeheartedly with what you say below.

Marco

-----Original Message-----
From: Freytsis, Ilya [mailto:ifreytsis@Cetacean.com]
Sent: Tuesday, January 22, 2002 2:20 PM
To: 'nsis@ietf.org'
Subject: RE: [NSIS] Two kinds of requirements


Allen,

I think your suggestion to start with Use Cases can be very productive and
will help the group to move forward in two steps:
1. It will help to remove any terminology barriers (if any is still left) by
describing scenarios people have in their minds in very specific
(application/problem field) terms (no generalization is involved yet). This
way everybody gets on the same playing field while discussing cases. It
should clear clouds around such terms as end-to-end QoS, session level QoS,
application QoS etc.
2. When all cases are discussed and understood the generalization can be
made based on all of them with very little room left for misinterpretation.

Ilya Freytsis
Cetacean Networks Inc.
ph. (603) 766-6065
fax (603) 766-7190
ifreytsis@cetacean.com



From: "Allen, Keith" <kallen@tri.sbc.com>
To: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements
Date: Tue, 22 Jan 2002 08:34:10 -0600
charset="iso-8859-1"

Rüdiger,

I was, in fact, proposing a requirements document.  I was merely suggesting
that the requirements for the protocol be captured with a technique used in
the OO software industry (as well as elsewhere) called Use Cases.  The idea
behind Use Cases, simply put, is to describe the requirements for a system
from the user's point of view.  This is done with a set of use cases, each
one being a scenario describing how the user utilizes the system to
accomplish some task.  The descriptions of all the tasks performed by the
user represent the requirements the system must meet.  I have not seen Use
Cases applied to protocol development but I see no reason why it couldn't
be.  Simply identifying the user will help us to settle all these
edge-host-hop-proxy discussions.

Use cases are good at capturing functional requirements, but aren't so
applicable to other types of requirements.  For example, if someone out
there is insistent that one of the requirements is "Must interwork with
RSVP-TE," that's not so easily captured in a use case.  If we decide to use
Use Cases we might have to amend them with more traditional requirements.


Keith Allen
SBC Technology Resources
9505 Arboretum Blvd.
Austin, TX 78759
(512) 372-5741
kallen@tri.sbc.com

This e-mail and any files transmitted with it are the property of SBC, are
confidential, and are intended solely for the use of the individual or
entity to whom this e-mail is addressed. If you are not one of the named
recipient(s) or otherwise have reason to believe that you have received this
message in error, please notify the sender at (512) 372-5000 and delete this
message immediately from your computer. Any other use, retention,
dissemination, forwarding, printing, or copying of this e-mail is strictly
prohibited.


 -----Original Message-----
From: 	Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] 
Sent:	Tuesday, January 22, 2002 3:05 AM
To:	Allen, Keith
Cc:	nsis@ietf.org
Subject:	RE: [NSIS] Two kinds of requirements

Allen,

I'm not sure on IETF terminology, but what you suggest may be a framework
document. As framework documents are usual if new IETF activities begin,
your suggestion is a good one. I'd however favour a requirements document. I
am volunteering to co-author one (means contribution and review). 

Regards, Rüdiger

> Along the lines of my earlier reference to Use Cases, what do 
> you think about beginning to document the requirements the
> protocol should meet as a set of use cases describing how
> network users (or actually  their network devices) use the
> protocol-to-be to access the QoS capabilities of the
> network.  For example, one use case could show a voice over
> IP caller, another a network administrator setting up an
> Ethernet VPN, etc.  If the protocol has to support mobile
> handoffs, we would have a use  case showing
> that. It would give us a focal point instead of just e-mail.
 


_______________________________________________
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  Tue Jan 22 16:47: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 QAA11862
	for <nsis-archive@odin.ietf.org>; Tue, 22 Jan 2002 16:46:46 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id QAA13975
	for nsis-archive@odin.ietf.org; Tue, 22 Jan 2002 16:46: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 QAA13660;
	Tue, 22 Jan 2002 16:34: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 QAA13584
	for <nsis@ns.ietf.org>; Tue, 22 Jan 2002 16:34: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 QAA11498
	for <nsis@ietf.org>; Tue, 22 Jan 2002 16:34:24 -0500 (EST)
Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56])
	by zcars0m9.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g0MLXsS28774;
	Tue, 22 Jan 2002 16:33:55 -0500 (EST)
Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7])
	by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g0MLXpT08927;
	Tue, 22 Jan 2002 16:33:51 -0500 (EST)
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19)
	id <C8PZYVY1>; Tue, 22 Jan 2002 16:33:51 -0500
Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4795@zcard031.ca.nortel.com>
From: "Gary Kenward"<gkenward@nortelnetworks.com>
To: "'Schneider, Marco'" <schneider@tri.sbc.com>,
        "'Roy, Radhika R, ALASO'" <rrroy@att.com>,
        "Loughney John (NRC/Helsinki)"
	 <john.loughney@nokia.com>,
        brunner@ccrle.nec.de, Yaron Kahana
	 <ykahana@comgates.co.il>,
        "Geib, Ruediger" <Ruediger.Geib@t-systems.com>, dick.rr.knight@bt.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements
Date: Tue, 22 Jan 2002 16:33:48 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C1A38C.7A0B3BB0"
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_01C1A38C.7A0B3BB0
Content-Type: text/plain;
	charset="ISO-8859-1"

Marco:
 
   Good question: what do I mean by layering. I assume you are familiar with
protocol layers and their
properties. My major concern would be in the replication of information
exchanges at each layer, resulting
in greater overhead/delay. The end systems must to be involved in
establishing the necessary QoS, including
negotiation if viable, but the number of bits that are transported through
the network to set up this QoS
end to end must be kept to a minimum. Thus, I cringe at the possibility of
an end-to-end application exchange
triggering an RSVP request, triggering . . . in telephony terms, the analogy
is the call setup delay, which has
to be acceptable to the user, and, for wireless, has to be bandwidth
efficient.
 
  I hope I have explained my concern.
 
Cheers,
Gary
 
 

-----Original Message-----
From: Schneider, Marco [mailto:schneider@tri.sbc.com]
Sent: January 22, 2002 15:35
To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Roy, Radhika R, ALASO'; Loughney John
(NRC/Helsinki); brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
dick.rr.knight@bt.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


Gary,

-----Original Message-----
From: Gary Kenward [mailto:gkenward@nortelnetworks.com]
Sent: Tuesday, January 22, 2002 9:02 AM
To: Schneider, Marco; 'Roy, Radhika R, ALASO'; Loughney John (NRC/Helsinki);
brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger; dick.rr.knight@bt.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements



Marco: 

-----Original Message----- 
> [MS]  Yes, exactly. 
>   I don't believe you are proposing a "layering" of signalling protocols, 
> one for session establishment, then one for transport, etc. 
> [MS]  This is exactly what has been proposed in RAP and SIP working groups
to the best 
> of my understanding. Because there does not exist a proxy signaling
capability that 
> allows a session to setup a connection on the users behalf, the session
forwards a 
> token to the end-system and then the end-system includes that token in the
RSVP path 
> message so that the reservation will go through. In this manner the
session layer does 
> not need to communicate directly with the transport layer. 

[gwk] I do not understand what "the session" represents in the above. It
would seem 
to me that you must have a session level entity, and that to "forward a
token to the 
end-system", it must have an interface/api to the "end-system". If this
"end-system" 
is including tokens in RSVP, then it is the entity setting up the transport
QoS (although 
it is not necessarly a transport layer entity, but rather a signalling
entity. If these 
two entites are co-located, then you do not have layered signalling
protocols. 

Have I missed something? 

[Schneider, Marco] I don't think you have missed anything. I may not have
understood what you meant by a layering of signaling protocols. Please
define this.

BTW: for many links, particularly wireless, layered signalling is not a good
idea. 
And, in general, layered signalling will always be slower then a single
signalling protocol. 
> So, the question, 
> becomes, how are the QoS transport mechanisms established? In the internet

> model there is only one end-to-end transport session (e.g. TCP, RTP, UDP),

> but underneath the transport is a series of inter-connected networks, each

> with potentially different characteristics. 
>   This is end-to-end QoS support structure has to be set up and maintained

> in order for the end to end session QoS to be realized. The solution may
be 
> a single protocol that travels from host to host, such as RSVP, or it may 
> be a collection of protocols that are optimized for each portion of the 
> end-to-end path: e.g. host to access network, access to core network, 
> core to core network, etc. 
>   It is too early to determine which approach is best, but in either case,

> do we not need to understand the end-to-end requirements for this
signalling 
> capability? 
> [MS]  So by end-to-end you are referring to both the end-systems and the
devices in 
> between. As a point of clarification, I asked Roy what he meant by
"End-to-End 
> Application Layer QOS Signaling" and his answer implied user (end-system)
to user (end- 
> system).  We have been using the term end-to-end in different ways
(contexts). The way 
> I normally use the term "end-to-end" is to include everything in between
(all the 
> hops). 

[gwk] I see the difference. I would say that I tend towards your definition,
in the 
following sense: the only QoS that matters is what the end-user sees, so as
a service 
characteristic, it must be provided between the two end systems / hosts. In
order to do 
this, however, some level of support is required at each hop along the path.

For me the term end-to-end (for example end-to-end call flow) includes the
components within the network that must come together to make it work. The
term end-to-end application level signaling seems like an oxymoron since
this signaling occurs with no involvement of the network except to transfer
the data packets but perhaps there is something I am missing. 

 So, establishing QoS between the end systems requires a peer-to-peer
agreement between 
the end systems, a host-to-cloud agreement for the transport of the packets,
and 
some mechanism within the cloud to ensure that the agreed upon QoS is
provided. 
Depending upon the complexity of the cloud, the latter could imply all sorts
of QoS 
agreements between networks and even nodes, for packet forwarding. 

  Note that I have purposely NOT stated that any of these agreements are
negotiated or 
require a signalling protocol. My opinion is that it is better in the long
term to 
support negotiated services using signalling, as it provides more
flexibility. However, 
this can be overdone, say, as a silly example, by having the end-system
negotiate with 
every node in the network. So, the compromise is that some of the QoS
agreements will 
be incorporated into the network design (e.g. Diff Serv), some will be
configured by 
the operator(s) (e.g. through traffic engineering and policy management),
and others 
will be signalled. NSIS seems to be about determining where signalling is
appropriate, 
and what are the signalling peers, and what is the best protocol solution or
solutions. 
The catch is that the first two approaches actually encompass a wide variety
of technologies 
and scenarios. 
[Schneider, Marco]  I think you have articulated this very well and I am in
general agreement. 

  Sorry for stating the obvious. There is clearly some concern over the use,
for example, 
of RSVP, and I suspect that some people are concerned that "end-to-end
signalling" also 
means "hop-by-hop" ala RSVP. It could, but it does not have to. 
[Schneider, Marco] I think this is a very important distinction. I think
that the reverse is true as well in that some people are assuming a hop by
hop linear signaling model wherein the signaling takes place in order along
the path that the data will follow. The transport signaling that is going to
occur within the core of our network will be at a different timescale than
UNI signaling and there are a variety of solutions for this including
RSVP-te and CR-LDP which were developed for the purpose of allocating
traffic trunks.

  So, my view is that NSIS needs to ensure that the end-to-end QoS is
provided for, and 
develope the protocols where they are needed (but not where they are not).
At this point, 
that would seem to be host to edge, edge to edge, and at the very least,
with enough 
end to end semantics to ensure that the complete path supports QoS. I am
concerned about 
node to node signalling, as there are so many different approaches to
supporting node-to-node 
QoS. At the very least, I would like to see a framework, and the edge
solutions defined 
before we delve into "intra-network" issues. 
[Schneider, Marco] I think it all begins with the fact that a user must be
able to request a QOS/COS connection/flow to another user. If we can't do
that then everything else would appear to be pointless. The next question is
whether we want to develop protocols that assist the network portion in
delivering this capability and in what context(s).


BTW: in writing this, it dawned upon me that it might be best to write a
series of 
requirements rather then just one - i.e. tackle the problem piece by piece.
This approach 
does have drawbacks, but working groups seem to work better when they focus
on contained 
problem domains. A strawman framework might be useful in keeping the
incremental solutions 
coherent. 
[Schneider, Marco] I agree with the idea of tackling the requirements by
breaking the problem up. There is a catch 22 in that in order to breakup it
up we must to some degree presuppose a solution. 


> [MS] I think our basic requirement is that an end-system be able to
request (and 
> receive) a QOS connection to some other end-system (NSIS UNI). The request
part entails 
> an NSIS UNI. As you say the realization of this request can be achieved in
a number of 
> different ways. Now one solution is to invent an NSIS NNI that runs
between domains. If 
> we develop requirements for such an NSIS UNI then we have already
preproposed a 
> solution ahead of requirements. 

[gwk] We have to be extremely careful not to become pre-occupied with
requirements 
definition. All productive requirements definition efforts begin with
assumptions 
concerning the solution. In my view, requirements specifications are a
balance between 
presumption and prediction, particularly when dealing with "soft"
techologies such as 
protocols. The issue really is not whether a requirement is a "MAY" or a
"SHOULD" or 
whatever, the issue is whether a requirement actually helps us define the
solution 
(there are lot's of examples of "SHOULD" requirements that do not bring
value to the 
design process). 
[Schneider, Marco] I think there is a danger in implicit assumptions that
may not lead to the best solution. With respect to network support of a QOS
request, there are many different solutions and I am afraid that some
participants have presupposed a hop by hop signaling solution. 

Given my observation above about writing a series of requirements, I would
recommend 
that we roughly map out the solution(some would call this a "framework").
This map would 
form the preliminary list of deliverables for the wg charter, and then pick
a focussed 
problem area to begin with requirements. This is not "top down" design, but
"top down" 
processes seldom work. If this seems too abstract, what I am saying is that
I have no 
problem identifying that there are N problem areas to be addressed - e.g.
host to edge, 
edge to edge, node to node, etc. - and picking anyone for the first design
attempt. Of 
course, the challenge would be to keep an eye on the "big picture" or
end-to-end 
requirements in the process. 
[Schneider, Marco] I think that the network context for supporting NSIS UNI
is a quagmire, albeit a very fun one. The problems we need to address depend
upon what end-to-end architectures we wish to support. There are a number of
capabilities already being developed for network QOS and there may be a
number of ways to "glue" these together.

Deludedly yours,

Marco

Just my deluded point of view. 
Cheers, 
Gary 

[Schneider, Marco]  
*snip* 


------_=_NextPart_001_01C1A38C.7A0B3BB0
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">
<TITLE>RE: [NSIS] Two kinds of requirements</TITLE>

<META content="MSHTML 5.00.3315.2869" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT color=#0000ff face="Comic Sans MS"><SPAN 
class=278125920-22012002>Marco:</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face="Comic Sans MS"><SPAN 
class=278125920-22012002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face="Comic Sans MS"><SPAN 
class=278125920-22012002>&nbsp;&nbsp; Good question: what do I mean by layering. 
I assume you are familiar with protocol layers and their</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face="Comic Sans MS"><SPAN 
class=278125920-22012002>properties. My major concern would be in the 
replication of information exchanges at each layer, 
resulting</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face="Comic Sans MS"><SPAN class=278125920-22012002>in 
greater overhead/delay. The end systems must to be involved in establishing the 
necessary QoS, including</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face="Comic Sans MS"><SPAN 
class=278125920-22012002>negotiation if viable, but the number of bits that are 
transported through the network to set up this QoS</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face="Comic Sans MS"><SPAN class=278125920-22012002>end 
to end must be kept to a minimum. Thus, I cringe at the possibility of an 
end-to-end application exchange</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face="Comic Sans MS"><SPAN 
class=278125920-22012002>triggering an RSVP request, triggering . . . in 
telephony terms, the analogy is the call setup delay, which 
has</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face="Comic Sans MS"><SPAN class=278125920-22012002>to 
be acceptable to the user, and, for wireless, has to be bandwidth 
efficient.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face="Comic Sans MS"><SPAN 
class=278125920-22012002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face="Comic Sans MS"><SPAN 
class=278125920-22012002>&nbsp; I hope I have explained my 
concern.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face="Comic Sans MS"><SPAN 
class=278125920-22012002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face="Comic Sans MS"><SPAN 
class=278125920-22012002>Cheers,</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face="Comic Sans MS"><SPAN 
class=278125920-22012002>Gary</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face="Comic Sans MS"><SPAN 
class=278125920-22012002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face="Comic Sans MS"><SPAN 
class=278125920-22012002></SPAN></FONT>&nbsp;</DIV>
<BLOCKQUOTE dir=ltr 
style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">
  <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Schneider, Marco 
  [mailto:schneider@tri.sbc.com]<BR><B>Sent:</B> January 22, 2002 
  15:35<BR><B>To:</B> Kenward, Gary [WDLN2:AN10:EXCH]; 'Roy, Radhika R, ALASO'; 
  Loughney John (NRC/Helsinki); brunner@ccrle.nec.de; Yaron Kahana; Geib, 
  Ruediger; dick.rr.knight@bt.com<BR><B>Cc:</B> nsis@ietf.org<BR><B>Subject:</B> 
  RE: [NSIS] Two kinds of requirements<BR><BR></DIV></FONT>
  <DIV><SPAN class=943153919-22012002><FONT color=#0000ff face=Arial 
  size=2>Gary,</FONT></SPAN></DIV>
  <BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
    <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
    size=2>-----Original Message-----<BR><B>From:</B> Gary Kenward 
    [mailto:gkenward@nortelnetworks.com]<BR><B>Sent:</B> Tuesday, January 22, 
    2002 9:02 AM<BR><B>To:</B> Schneider, Marco; 'Roy, Radhika R, ALASO'; 
    Loughney John (NRC/Helsinki); brunner@ccrle.nec.de; Yaron Kahana; Geib, 
    Ruediger; dick.rr.knight@bt.com<BR><B>Cc:</B> 
    nsis@ietf.org<BR><B>Subject:</B> RE: [NSIS] Two kinds of 
    requirements<BR><BR></FONT></DIV>
    <P><FONT size=2>Marco:</FONT> </P>
    <P><FONT size=2>-----Original Message-----</FONT> <BR><FONT size=2>&gt; 
    [MS]&nbsp; Yes, exactly.</FONT> <BR><FONT size=2>&gt;&nbsp;&nbsp; I don't 
    believe you are proposing a "layering" of signalling protocols, 
    </FONT><BR><FONT size=2>&gt; one for session establishment, then one for 
    transport, etc. </FONT><BR><FONT size=2>&gt; [MS]&nbsp; This is exactly what 
    has been proposed in RAP and SIP working groups to the best </FONT><BR><FONT 
    size=2>&gt; of my understanding. Because there does not exist a proxy 
    signaling capability that </FONT><BR><FONT size=2>&gt; allows a session to 
    setup a connection on the users behalf, the session forwards a 
    </FONT><BR><FONT size=2>&gt; token to the end-system and then the end-system 
    includes that token in the RSVP path </FONT><BR><FONT size=2>&gt; message so 
    that the reservation will go through. In this manner the session layer does 
    </FONT><BR><FONT size=2>&gt; not need to communicate directly with the 
    transport layer.</FONT> </P>
    <P><FONT size=2>[gwk] I do not understand what "the session" represents in 
    the above. It would seem </FONT><BR><FONT size=2>to me that you must have a 
    session level entity, and that to "forward a token to the</FONT> <BR><FONT 
    size=2>end-system", it must have an interface/api to the "end-system". If 
    this "end-system"</FONT> <BR><FONT size=2>is including tokens in RSVP, then 
    it is the entity setting up the transport QoS (although</FONT> <BR><FONT 
    size=2>it is not necessarly a transport layer entity, but rather a 
    signalling entity. If these</FONT> <BR><FONT size=2>two entites are 
    co-located, then you do not have layered signalling protocols.</FONT> </P>
    <P><FONT size=2>Have I missed something?</FONT> </P>
    <P><FONT size=2><SPAN class=943153919-22012002><FONT color=#0000ff 
    face=Arial size=2>[Schneider, Marco]&nbsp;I don't think you have missed 
    anything. I may not have understood what you meant by a layering of 
    signaling protocols.</FONT></SPAN><SPAN class=943153919-22012002><FONT 
    size=3>&nbsp;</FONT><FONT color=#0000ff face=Arial size=2>Please define 
    this.</FONT></SPAN></FONT></P>
    <P><FONT size=2><SPAN class=943153919-22012002></SPAN>BTW: for many links, 
    particularly wireless, layered signalling is not a good idea.</FONT> 
    <BR><FONT size=2>And, in general, layered signalling will always be slower 
    then a single signalling protocol.</FONT> <BR><FONT size=2>&gt; So, the 
    question, </FONT><BR><FONT size=2>&gt; becomes, how are the QoS transport 
    mechanisms established? In the internet </FONT><BR><FONT size=2>&gt; model 
    there is only one end-to-end transport session (e.g. TCP, RTP, UDP), 
    </FONT><BR><FONT size=2>&gt; but underneath the transport is a series of 
    inter-connected networks, each </FONT><BR><FONT size=2>&gt; with potentially 
    different characteristics. </FONT><BR><FONT size=2>&gt;&nbsp;&nbsp; This is 
    end-to-end QoS support structure has to be set up and maintained 
    </FONT><BR><FONT size=2>&gt; in order for the end to end session QoS to be 
    realized. The solution may be </FONT><BR><FONT size=2>&gt; a single protocol 
    that travels from host to host, such as RSVP, or it may </FONT><BR><FONT 
    size=2>&gt; be a collection of protocols that are optimized for each portion 
    of the </FONT><BR><FONT size=2>&gt; end-to-end path: e.g. host to access 
    network, access to core network, </FONT><BR><FONT size=2>&gt; core to core 
    network, etc. </FONT><BR><FONT size=2>&gt;&nbsp;&nbsp; It is too early to 
    determine which approach is best, but in either case, </FONT><BR><FONT 
    size=2>&gt; do we not need to understand the end-to-end requirements for 
    this signalling </FONT><BR><FONT size=2>&gt; capability? </FONT><BR><FONT 
    size=2>&gt; [MS]&nbsp; So by end-to-end you are referring to both the 
    end-systems and the devices in </FONT><BR><FONT size=2>&gt; between. As a 
    point of clarification, I asked Roy what he meant by "End-to-End 
    </FONT><BR><FONT size=2>&gt; Application Layer QOS Signaling" and his answer 
    implied user (end-system) to user (end-</FONT> <BR><FONT size=2>&gt; 
    system).&nbsp; We have been using the term end-to-end in different ways 
    (contexts). The way </FONT><BR><FONT size=2>&gt; I normally use the term 
    "end-to-end" is to include everything in between (all the </FONT><BR><FONT 
    size=2>&gt; hops). </FONT></P>
    <P><FONT size=2>[gwk] I see the difference. I would say that I tend towards 
    your definition, in the </FONT><BR><FONT size=2>following sense: the only 
    QoS that matters is what the end-user sees, so as a service</FONT> <BR><FONT 
    size=2>characteristic, it must be provided between the two end systems / 
    hosts. In order to do </FONT><BR><FONT size=2>this, however, some level of 
    support is required at each hop along the path. <BR><FONT face=Arial><FONT 
    color=#0000ff><SPAN class=943153919-22012002><SPAN 
    class=943153919-22012002>For me the term end-to-end (for example end-to-end 
    call flow) includes </SPAN>the components within the network that must come 
    together to make it work. The term end-to-end application level signaling 
    seems like an oxymoron since this signaling occurs with no involvement of 
    the network except to transfer the data packets but perhaps there is 
    something I am missing. </SPAN></FONT></FONT></FONT></P>
    <P><FONT size=2><SPAN class=943153919-22012002>&nbsp;</SPAN>So, establishing 
    QoS between the end systems requires a peer-to-peer agreement between</FONT> 
    <BR><FONT size=2>the end systems, a host-to-cloud agreement for the 
    transport of the packets, and </FONT><BR><FONT size=2>some mechanism within 
    the cloud to ensure that the agreed upon QoS is provided.</FONT> <BR><FONT 
    size=2>Depending upon the complexity of the cloud, the latter could imply 
    all sorts of QoS</FONT> <BR><FONT size=2>agreements between networks and 
    even nodes, for packet forwarding.</FONT> </P>
    <P><FONT size=2>&nbsp; Note that I have purposely NOT stated that any of 
    these agreements are negotiated or</FONT> <BR><FONT size=2>require a 
    signalling protocol. My opinion is that it is better in the long term 
    to</FONT> <BR><FONT size=2>support negotiated services using signalling, as 
    it provides more flexibility. However,</FONT> <BR><FONT size=2>this can be 
    overdone, say, as a silly example, by having the end-system negotiate 
    with</FONT> <BR><FONT size=2>every node in the network. So, the compromise 
    is that some of the QoS agreements will</FONT> <BR><FONT size=2>be 
    incorporated into the network design (e.g. Diff Serv), some will be 
    configured by</FONT> <BR><FONT size=2>the operator(s) (e.g. through traffic 
    engineering and policy management), and others</FONT> <BR><FONT size=2>will 
    be signalled. NSIS seems to be about determining where signalling is 
    appropriate,</FONT> <BR><FONT size=2>and what are the signalling peers, and 
    what is the best protocol solution or solutions.</FONT> <BR><FONT size=2>The 
    catch is that the first two approaches actually encompass a wide variety of 
    technologies</FONT> <BR><FONT size=2>and scenarios.</FONT> <BR><FONT 
    face=Arial><FONT color=#0000ff><FONT size=2><SPAN 
    class=943153919-22012002>[</SPAN>Schneider, Marco]&nbsp;&nbsp;I think you 
    have articulated this very well and I am in general 
    agreement.&nbsp;</FONT></FONT></FONT></P>
    <P><FONT size=2>&nbsp; Sorry for stating the obvious. There is clearly some 
    concern over the use, for example,</FONT> <BR><FONT size=2>of RSVP, and I 
    suspect that some people are concerned that "end-to-end signalling" 
    also</FONT> <BR><FONT size=2>means "hop-by-hop" ala RSVP. It could, but it 
    does not have to.</FONT> <BR><SPAN class=943153919-22012002><FONT 
    color=#0000ff face=Arial size=2>[Schneider, Marco]&nbsp;I think this is a 
    very important distinction. I think that the reverse is true as well in that 
    some people are assuming a hop by hop linear signaling model wherein the 
    signaling takes place in order along the path that the data will follow. The 
    transport signaling that is going to occur within the core&nbsp;of 
    our&nbsp;network will be at a different timescale than UNI signaling and 
    there are a variety of solutions for this including RSVP-te and CR-LDP which 
    were developed for the purpose of allocating traffic 
    trunks.</FONT></SPAN></P>
    <P><SPAN class=943153919-22012002></SPAN><FONT size=2>&nbsp; So, my view is 
    that NSIS needs to ensure that the end-to-end QoS is provided for, 
    and</FONT> <BR><FONT size=2>develope the protocols where they are needed 
    (but not where they are not). At this point,</FONT> <BR><FONT size=2>that 
    would seem to be host to edge, edge to edge, and at the very least, with 
    enough</FONT> <BR><FONT size=2>end to end semantics to ensure that the 
    complete path supports QoS. I am concerned about</FONT> <BR><FONT 
    size=2>node to node signalling, as there are so many different approaches to 
    supporting node-to-node</FONT> <BR><FONT size=2>QoS. At the very least, I 
    would like to see a framework, and the edge solutions defined</FONT> 
    <BR><FONT size=2>before we delve into "intra-network" issues.</FONT> 
    <BR><SPAN class=943153919-22012002><FONT color=#0000ff face=Arial 
    size=2>[Schneider, Marco]&nbsp;I think it all begins with the fact that a 
    user must be able to request a QOS/COS connection/flow to another user. If 
    we can't do that then everything else would appear to be pointless. The next 
    question is whether we want to develop protocols that assist the network 
    portion&nbsp;in delivering this capability and in what 
    context(s).</FONT></SPAN><BR></P><SPAN class=943153919-22012002><FONT 
    color=#0000ff face=Arial size=2></FONT></SPAN>
    <P><FONT size=2>BTW: in writing this, it dawned upon me that it might be 
    best to write a series of</FONT> <BR><FONT size=2>requirements rather then 
    just one - i.e. tackle the problem piece by piece. This approach</FONT> 
    <BR><FONT size=2>does have drawbacks, but working groups seem to work better 
    when they focus on contained</FONT> <BR><FONT size=2>problem domains. A 
    strawman framework might be useful in keeping the incremental 
    solutions</FONT> <BR><FONT size=2>coherent.</FONT> <BR><SPAN 
    class=943153919-22012002><FONT color=#0000ff face=Arial size=2>[Schneider, 
    Marco]&nbsp;I agree with the idea of tackling the requirements by breaking 
    the problem up. There is a catch 22 in that in order to breakup it up we 
    must to some degree presuppose a solution.&nbsp;</FONT></SPAN></P><BR>
    <P><FONT size=2>&gt; [MS] I think our basic requirement is that an 
    end-system be able to request (and </FONT><BR><FONT size=2>&gt; receive) a 
    QOS connection to some other end-system (NSIS UNI). The request part entails 
    </FONT><BR><FONT size=2>&gt; an NSIS UNI. As you say the realization of this 
    request can be achieved in a number of </FONT><BR><FONT size=2>&gt; 
    different ways. Now one solution is to invent an NSIS NNI that runs between 
    domains. If </FONT><BR><FONT size=2>&gt; we develop requirements for such an 
    NSIS UNI then we have already preproposed a </FONT><BR><FONT size=2>&gt; 
    solution ahead of requirements. </FONT></P>
    <P><FONT size=2>[gwk] We have to be extremely careful not to become 
    pre-occupied with requirements</FONT> <BR><FONT size=2>definition. All 
    productive requirements definition efforts begin with assumptions 
    </FONT><BR><FONT size=2>concerning the solution. In my view, requirements 
    specifications are a balance between</FONT> <BR><FONT size=2>presumption and 
    prediction, particularly when dealing with "soft" techologies such as</FONT> 
    <BR><FONT size=2>protocols. The issue really is not whether a requirement is 
    a "MAY" or a "SHOULD" or</FONT> <BR><FONT size=2>whatever, the issue is 
    whether a requirement actually helps us define the solution</FONT> <BR><FONT 
    size=2>(there are lot's of examples of "SHOULD" requirements that do not 
    bring value to the</FONT> <BR><FONT size=2>design process).</FONT> <BR><SPAN 
    class=943153919-22012002><FONT color=#0000ff face=Arial size=2>[Schneider, 
    Marco]&nbsp;I think there is a danger in implicit assumptions that may not 
    lead to the best solution. With&nbsp;respect to network support of 
    a&nbsp;QOS request, there are many different solutions and I am afraid that 
    some participants have presupposed a hop by hop signaling 
    solution.&nbsp;</FONT></SPAN></P>
    <P><FONT size=2>Given my observation above about writing a series of 
    requirements, I would recommend </FONT><BR><FONT size=2>that we roughly map 
    out the solution(some would call this a "framework"). This map would 
    </FONT><BR><FONT size=2>form the preliminary list of deliverables for the wg 
    charter, and then pick a focussed </FONT><BR><FONT size=2>problem area to 
    begin with requirements. This is not "top down" design, but "top down" 
    </FONT><BR><FONT size=2>processes seldom work. If this seems too abstract, 
    what I am saying is that I have no </FONT><BR><FONT size=2>problem 
    identifying that there are N problem areas to be addressed - e.g. host to 
    edge, </FONT><BR><FONT size=2>edge to edge, node to node, etc. - and picking 
    anyone for the first design attempt. Of </FONT><BR><FONT size=2>course, the 
    challenge would be to keep an eye on the "big picture" or end-to-end 
    </FONT><BR><FONT size=2>requirements in the process.</FONT> <BR><SPAN 
    class=943153919-22012002><FONT color=#0000ff face=Arial size=2>[Schneider, 
    Marco]&nbsp;I think that the network context for supporting NSIS UNI is a 
    quagmire, albeit a very fun one. The problems we need to address depend upon 
    what end-to-end architectures we wish to support. There are a number of 
    capabilities already being developed for network QOS and there may be a 
    number of ways to "glue" these together.</FONT></SPAN></P>
    <P><SPAN class=943153919-22012002><FONT color=#0000ff face=Arial 
    size=2>Deludedly yours,</FONT></SPAN></P>
    <P><SPAN class=943153919-22012002><FONT color=#0000ff face=Arial 
    size=2>Marco</FONT></SPAN></P>
    <P><SPAN class=943153919-22012002></SPAN><FONT size=2>Just my deluded point 
    of view.</FONT> <BR><FONT size=2>Cheers,</FONT> <BR><FONT size=2>Gary</FONT> 
    </P>
    <P><FONT size=2>[Schneider, Marco]&nbsp; </FONT><BR><FONT 
    size=2>*snip*</FONT> </P></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C1A38C.7A0B3BB0--

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



From daemon@ns.ietf.org  Tue Jan 22 18:01:06 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13997
	for <nsis-archive@odin.ietf.org>; Tue, 22 Jan 2002 18:01:06 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id SAA17228
	for nsis-archive@odin.ietf.org; Tue, 22 Jan 2002 18:01: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 RAA16529;
	Tue, 22 Jan 2002 17:50: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 RAA16458
	for <nsis@ns.ietf.org>; Tue, 22 Jan 2002 17:50:12 -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 RAA13684
	for <nsis@ietf.org>; Tue, 22 Jan 2002 17:50:08 -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 g0MMolT10502;
	Tue, 22 Jan 2002 16:50:47 -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 g0MMm7i10044;
	Tue, 22 Jan 2002 16:48:07 -0600 (CST)
Received: by TRIMAIL2.ad.tri.sbc.com with Internet Mail Service (5.5.2653.19)
	id <ZND325Y5>; Tue, 22 Jan 2002 16:48:34 -0600
Message-ID: <905A1C4ABF353F4C8CC16FA9F53DD0D638B9AB@TRIMAIL2.ad.tri.sbc.com>
From: "Schneider, Marco" <schneider@tri.sbc.com>
To: "'Gary Kenward'" <gkenward@nortelnetworks.com>,
        "'Roy, Radhika R, ALASO'" <rrroy@att.com>,
        "Loughney John (NRC/Helsinki)"
	 <john.loughney@nokia.com>,
        brunner@ccrle.nec.de, Yaron Kahana
	 <ykahana@comgates.co.il>,
        "Geib, Ruediger" <Ruediger.Geib@t-systems.com>, dick.rr.knight@bt.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements
Date: Tue, 22 Jan 2002 16:48:32 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C1A396.EADD7B50"
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_01C1A396.EADD7B50
Content-Type: text/plain;
	charset="iso-8859-1"

Garry,
 
From an architectural/software perspective there is a session layer that is
logically built on top of the transport capability. From a protocol stack
perspective the session signaling is not layered on top of the transport
signaling in the framework I described. 
 
Aside: The following scenario is conceivable but not desireable. Consider an
ADSL customer that is logically connected to an edge router via a DSLAM and
an edge switch. Thus the layer 3 hop is realized by multiple hops at layer
2. Existing deployments that I am aware of use a preprovisioned PVC for
this. Now imagine that the customer does session signaling resulting in NSIS
signaling at layer 3. This could result in the need for a new layer 2
connection because the existing PVC will not do the job. Thus ATM UNI
signaling might be initiated from the ADSL Customer to allocate the
resources for the layer 3 logical link. Yuck! Obviously it is better to
avoid this by pre-provisioning the access network appropriately.
Nevertheless, there may be other circumstances where this type of situation
will occur and one could imagine promoting the layer 2 devices to be aware
of NSIS so as to avoid multiple levels of signaling. 
 
Marco
 
-----Original Message-----
From: Gary Kenward [mailto:gkenward@nortelnetworks.com]
Sent: Tuesday, January 22, 2002 3:34 PM
To: Schneider, Marco; 'Roy, Radhika R, ALASO'; Loughney John (NRC/Helsinki);
brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger; dick.rr.knight@bt.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements



Marco:
 
   Good question: what do I mean by layering. I assume you are familiar with
protocol layers and their
properties. My major concern would be in the replication of information
exchanges at each layer, resulting
in greater overhead/delay. The end systems must to be involved in
establishing the necessary QoS, including
negotiation if viable, but the number of bits that are transported through
the network to set up this QoS
end to end must be kept to a minimum. Thus, I cringe at the possibility of
an end-to-end application exchange
triggering an RSVP request, triggering . . . in telephony terms, the analogy
is the call setup delay, which has
to be acceptable to the user, and, for wireless, has to be bandwidth
efficient.
 
  I hope I have explained my concern.
 
Cheers,
Gary
 
 

-----Original Message-----
From: Schneider, Marco [mailto:schneider@tri.sbc.com]
Sent: January 22, 2002 15:35
To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Roy, Radhika R, ALASO'; Loughney John
(NRC/Helsinki); brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
dick.rr.knight@bt.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


Gary,

-----Original Message-----
From: Gary Kenward [mailto:gkenward@nortelnetworks.com]
Sent: Tuesday, January 22, 2002 9:02 AM
To: Schneider, Marco; 'Roy, Radhika R, ALASO'; Loughney John (NRC/Helsinki);
brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger; dick.rr.knight@bt.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements



Marco: 

-----Original Message----- 
> [MS]  Yes, exactly. 
>   I don't believe you are proposing a "layering" of signalling protocols, 
> one for session establishment, then one for transport, etc. 
> [MS]  This is exactly what has been proposed in RAP and SIP working groups
to the best 
> of my understanding. Because there does not exist a proxy signaling
capability that 
> allows a session to setup a connection on the users behalf, the session
forwards a 
> token to the end-system and then the end-system includes that token in the
RSVP path 
> message so that the reservation will go through. In this manner the
session layer does 
> not need to communicate directly with the transport layer. 

[gwk] I do not understand what "the session" represents in the above. It
would seem 
to me that you must have a session level entity, and that to "forward a
token to the 
end-system", it must have an interface/api to the "end-system". If this
"end-system" 
is including tokens in RSVP, then it is the entity setting up the transport
QoS (although 
it is not necessarly a transport layer entity, but rather a signalling
entity. If these 
two entites are co-located, then you do not have layered signalling
protocols. 

Have I missed something? 

[Schneider, Marco] I don't think you have missed anything. I may not have
understood what you meant by a layering of signaling protocols. Please
define this.

BTW: for many links, particularly wireless, layered signalling is not a good
idea. 
And, in general, layered signalling will always be slower then a single
signalling protocol. 
> So, the question, 
> becomes, how are the QoS transport mechanisms established? In the internet

> model there is only one end-to-end transport session (e.g. TCP, RTP, UDP),

> but underneath the transport is a series of inter-connected networks, each

> with potentially different characteristics. 
>   This is end-to-end QoS support structure has to be set up and maintained

> in order for the end to end session QoS to be realized. The solution may
be 
> a single protocol that travels from host to host, such as RSVP, or it may 
> be a collection of protocols that are optimized for each portion of the 
> end-to-end path: e.g. host to access network, access to core network, 
> core to core network, etc. 
>   It is too early to determine which approach is best, but in either case,

> do we not need to understand the end-to-end requirements for this
signalling 
> capability? 
> [MS]  So by end-to-end you are referring to both the end-systems and the
devices in 
> between. As a point of clarification, I asked Roy what he meant by
"End-to-End 
> Application Layer QOS Signaling" and his answer implied user (end-system)
to user (end- 
> system).  We have been using the term end-to-end in different ways
(contexts). The way 
> I normally use the term "end-to-end" is to include everything in between
(all the 
> hops). 

[gwk] I see the difference. I would say that I tend towards your definition,
in the 
following sense: the only QoS that matters is what the end-user sees, so as
a service 
characteristic, it must be provided between the two end systems / hosts. In
order to do 
this, however, some level of support is required at each hop along the path.

For me the term end-to-end (for example end-to-end call flow) includes the
components within the network that must come together to make it work. The
term end-to-end application level signaling seems like an oxymoron since
this signaling occurs with no involvement of the network except to transfer
the data packets but perhaps there is something I am missing. 

 So, establishing QoS between the end systems requires a peer-to-peer
agreement between 
the end systems, a host-to-cloud agreement for the transport of the packets,
and 
some mechanism within the cloud to ensure that the agreed upon QoS is
provided. 
Depending upon the complexity of the cloud, the latter could imply all sorts
of QoS 
agreements between networks and even nodes, for packet forwarding. 

  Note that I have purposely NOT stated that any of these agreements are
negotiated or 
require a signalling protocol. My opinion is that it is better in the long
term to 
support negotiated services using signalling, as it provides more
flexibility. However, 
this can be overdone, say, as a silly example, by having the end-system
negotiate with 
every node in the network. So, the compromise is that some of the QoS
agreements will 
be incorporated into the network design (e.g. Diff Serv), some will be
configured by 
the operator(s) (e.g. through traffic engineering and policy management),
and others 
will be signalled. NSIS seems to be about determining where signalling is
appropriate, 
and what are the signalling peers, and what is the best protocol solution or
solutions. 
The catch is that the first two approaches actually encompass a wide variety
of technologies 
and scenarios. 
[Schneider, Marco]  I think you have articulated this very well and I am in
general agreement. 

  Sorry for stating the obvious. There is clearly some concern over the use,
for example, 
of RSVP, and I suspect that some people are concerned that "end-to-end
signalling" also 
means "hop-by-hop" ala RSVP. It could, but it does not have to. 
[Schneider, Marco] I think this is a very important distinction. I think
that the reverse is true as well in that some people are assuming a hop by
hop linear signaling model wherein the signaling takes place in order along
the path that the data will follow. The transport signaling that is going to
occur within the core of our network will be at a different timescale than
UNI signaling and there are a variety of solutions for this including
RSVP-te and CR-LDP which were developed for the purpose of allocating
traffic trunks.

  So, my view is that NSIS needs to ensure that the end-to-end QoS is
provided for, and 
develope the protocols where they are needed (but not where they are not).
At this point, 
that would seem to be host to edge, edge to edge, and at the very least,
with enough 
end to end semantics to ensure that the complete path supports QoS. I am
concerned about 
node to node signalling, as there are so many different approaches to
supporting node-to-node 
QoS. At the very least, I would like to see a framework, and the edge
solutions defined 
before we delve into "intra-network" issues. 
[Schneider, Marco] I think it all begins with the fact that a user must be
able to request a QOS/COS connection/flow to another user. If we can't do
that then everything else would appear to be pointless. The next question is
whether we want to develop protocols that assist the network portion in
delivering this capability and in what context(s).


BTW: in writing this, it dawned upon me that it might be best to write a
series of 
requirements rather then just one - i.e. tackle the problem piece by piece.
This approach 
does have drawbacks, but working groups seem to work better when they focus
on contained 
problem domains. A strawman framework might be useful in keeping the
incremental solutions 
coherent. 
[Schneider, Marco] I agree with the idea of tackling the requirements by
breaking the problem up. There is a catch 22 in that in order to breakup it
up we must to some degree presuppose a solution. 


> [MS] I think our basic requirement is that an end-system be able to
request (and 
> receive) a QOS connection to some other end-system (NSIS UNI). The request
part entails 
> an NSIS UNI. As you say the realization of this request can be achieved in
a number of 
> different ways. Now one solution is to invent an NSIS NNI that runs
between domains. If 
> we develop requirements for such an NSIS UNI then we have already
preproposed a 
> solution ahead of requirements. 

[gwk] We have to be extremely careful not to become pre-occupied with
requirements 
definition. All productive requirements definition efforts begin with
assumptions 
concerning the solution. In my view, requirements specifications are a
balance between 
presumption and prediction, particularly when dealing with "soft"
techologies such as 
protocols. The issue really is not whether a requirement is a "MAY" or a
"SHOULD" or 
whatever, the issue is whether a requirement actually helps us define the
solution 
(there are lot's of examples of "SHOULD" requirements that do not bring
value to the 
design process). 
[Schneider, Marco] I think there is a danger in implicit assumptions that
may not lead to the best solution. With respect to network support of a QOS
request, there are many different solutions and I am afraid that some
participants have presupposed a hop by hop signaling solution. 

Given my observation above about writing a series of requirements, I would
recommend 
that we roughly map out the solution(some would call this a "framework").
This map would 
form the preliminary list of deliverables for the wg charter, and then pick
a focussed 
problem area to begin with requirements. This is not "top down" design, but
"top down" 
processes seldom work. If this seems too abstract, what I am saying is that
I have no 
problem identifying that there are N problem areas to be addressed - e.g.
host to edge, 
edge to edge, node to node, etc. - and picking anyone for the first design
attempt. Of 
course, the challenge would be to keep an eye on the "big picture" or
end-to-end 
requirements in the process. 
[Schneider, Marco] I think that the network context for supporting NSIS UNI
is a quagmire, albeit a very fun one. The problems we need to address depend
upon what end-to-end architectures we wish to support. There are a number of
capabilities already being developed for network QOS and there may be a
number of ways to "glue" these together.

Deludedly yours,

Marco

Just my deluded point of view. 
Cheers, 
Gary 

[Schneider, Marco]  
*snip* 


------_=_NextPart_001_01C1A396.EADD7B50
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">
<TITLE>RE: [NSIS] Two kinds of requirements</TITLE>

<META content="MSHTML 5.50.4616.200" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=717534121-22012002><FONT face=Arial color=#0000ff 
size=2>Garry,</FONT></SPAN></DIV>
<DIV><SPAN class=717534121-22012002><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=717534121-22012002><FONT face=Arial color=#0000ff size=2>From 
an architectural/software perspective there is a session layer&nbsp;that is 
logically&nbsp;built on top of the transport capability. From a protocol stack 
perspective the session signaling is not layered on top of the transport 
signaling in the framework I described. </FONT></SPAN></DIV>
<DIV><SPAN class=717534121-22012002><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=717534121-22012002><FONT face=Arial color=#0000ff size=2>Aside: 
The following scenario is conceivable but not desireable.&nbsp;Consider an ADSL 
customer that </FONT></SPAN><SPAN class=717534121-22012002><FONT face=Arial 
color=#0000ff size=2>is&nbsp;logically connected to an edge router via a DSLAM 
and an edge switch. Thus the layer 3 hop is realized by multiple hops at layer 
2. Existing deployments that I am aware of use a preprovisioned PVC for this. 
</FONT></SPAN><SPAN class=717534121-22012002><FONT face=Arial color=#0000ff 
size=2>Now imagine that the customer does session signaling resulting in NSIS 
signaling at layer 3. This could result in the need for a new layer 2 connection 
because the existing PVC will not do the job. Thus ATM UNI signaling might 
be&nbsp;initiated from the ADSL Customer&nbsp;to allocate the resources for the 
layer 3 logical link. Yuck! Obviously it is better to avoid this by 
pre-provisioning the access network appropriately. Nevertheless, there may be 
other circumstances where this type of situation will occur and one could 
imagine promoting the layer 2 devices to be aware of NSIS so as to avoid 
multiple levels of signaling. </FONT></SPAN></DIV>
<DIV><SPAN class=717534121-22012002><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=717534121-22012002><FONT face=Arial color=#0000ff 
size=2>Marco</FONT></SPAN></DIV>
<DIV><SPAN class=717534121-22012002><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=717534121-22012002></SPAN><FONT face=Tahoma 
size=2>-----Original Message-----<BR><B>From:</B> Gary Kenward 
[mailto:gkenward@nortelnetworks.com]<BR><B>Sent:</B> Tuesday, January 22, 2002 
3:34 PM<BR><B>To:</B> Schneider, Marco; 'Roy, Radhika R, ALASO'; Loughney John 
(NRC/Helsinki); brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger; 
dick.rr.knight@bt.com<BR><B>Cc:</B> nsis@ietf.org<BR><B>Subject:</B> RE: [NSIS] 
Two kinds of requirements<BR><BR></DIV></FONT>
<BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
  <DIV><FONT face="Comic Sans MS" color=#0000ff><SPAN 
  class=278125920-22012002>Marco:</SPAN></FONT></DIV>
  <DIV><FONT face="Comic Sans MS" color=#0000ff><SPAN 
  class=278125920-22012002></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face="Comic Sans MS" color=#0000ff><SPAN 
  class=278125920-22012002>&nbsp;&nbsp; Good question: what do I mean by 
  layering. I assume you are familiar with protocol layers and 
  their</SPAN></FONT></DIV>
  <DIV><FONT face="Comic Sans MS" color=#0000ff><SPAN 
  class=278125920-22012002>properties. My major concern would be in the 
  replication of information exchanges at each layer, 
  resulting</SPAN></FONT></DIV>
  <DIV><FONT face="Comic Sans MS" color=#0000ff><SPAN 
  class=278125920-22012002>in greater overhead/delay. The end systems must to be 
  involved in establishing the necessary QoS, including</SPAN></FONT></DIV>
  <DIV><FONT face="Comic Sans MS" color=#0000ff><SPAN 
  class=278125920-22012002>negotiation if viable, but the number of bits that 
  are transported through the network to set up this QoS</SPAN></FONT></DIV>
  <DIV><FONT face="Comic Sans MS" color=#0000ff><SPAN 
  class=278125920-22012002>end to end must be kept to a minimum. Thus, I cringe 
  at the possibility of an end-to-end application exchange</SPAN></FONT></DIV>
  <DIV><FONT face="Comic Sans MS" color=#0000ff><SPAN 
  class=278125920-22012002>triggering an RSVP request, triggering . . . in 
  telephony terms, the analogy is the call setup delay, which 
  has</SPAN></FONT></DIV>
  <DIV><FONT face="Comic Sans MS" color=#0000ff><SPAN 
  class=278125920-22012002>to be acceptable to the user, and, for wireless, has 
  to be bandwidth efficient.</SPAN></FONT></DIV>
  <DIV><FONT face="Comic Sans MS" color=#0000ff><SPAN 
  class=278125920-22012002></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face="Comic Sans MS" color=#0000ff><SPAN 
  class=278125920-22012002>&nbsp; I hope I have explained my 
  concern.</SPAN></FONT></DIV>
  <DIV><FONT face="Comic Sans MS" color=#0000ff><SPAN 
  class=278125920-22012002></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face="Comic Sans MS" color=#0000ff><SPAN 
  class=278125920-22012002>Cheers,</SPAN></FONT></DIV>
  <DIV><FONT face="Comic Sans MS" color=#0000ff><SPAN 
  class=278125920-22012002>Gary</SPAN></FONT></DIV>
  <DIV><FONT face="Comic Sans MS" color=#0000ff><SPAN 
  class=278125920-22012002></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face="Comic Sans MS" color=#0000ff><SPAN 
  class=278125920-22012002></SPAN></FONT>&nbsp;</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> Schneider, Marco 
    [mailto:schneider@tri.sbc.com]<BR><B>Sent:</B> January 22, 2002 
    15:35<BR><B>To:</B> Kenward, Gary [WDLN2:AN10:EXCH]; 'Roy, Radhika R, 
    ALASO'; Loughney John (NRC/Helsinki); brunner@ccrle.nec.de; Yaron Kahana; 
    Geib, Ruediger; dick.rr.knight@bt.com<BR><B>Cc:</B> 
    nsis@ietf.org<BR><B>Subject:</B> RE: [NSIS] Two kinds of 
    requirements<BR><BR></DIV></FONT>
    <DIV><SPAN class=943153919-22012002><FONT face=Arial color=#0000ff 
    size=2>Gary,</FONT></SPAN></DIV>
    <BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
      <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
      size=2>-----Original Message-----<BR><B>From:</B> Gary Kenward 
      [mailto:gkenward@nortelnetworks.com]<BR><B>Sent:</B> Tuesday, January 22, 
      2002 9:02 AM<BR><B>To:</B> Schneider, Marco; 'Roy, Radhika R, ALASO'; 
      Loughney John (NRC/Helsinki); brunner@ccrle.nec.de; Yaron Kahana; Geib, 
      Ruediger; dick.rr.knight@bt.com<BR><B>Cc:</B> 
      nsis@ietf.org<BR><B>Subject:</B> RE: [NSIS] Two kinds of 
      requirements<BR><BR></FONT></DIV>
      <P><FONT size=2>Marco:</FONT> </P>
      <P><FONT size=2>-----Original Message-----</FONT> <BR><FONT size=2>&gt; 
      [MS]&nbsp; Yes, exactly.</FONT> <BR><FONT size=2>&gt;&nbsp;&nbsp; I don't 
      believe you are proposing a "layering" of signalling protocols, 
      </FONT><BR><FONT size=2>&gt; one for session establishment, then one for 
      transport, etc. </FONT><BR><FONT size=2>&gt; [MS]&nbsp; This is exactly 
      what has been proposed in RAP and SIP working groups to the best 
      </FONT><BR><FONT size=2>&gt; of my understanding. Because there does not 
      exist a proxy signaling capability that </FONT><BR><FONT size=2>&gt; 
      allows a session to setup a connection on the users behalf, the session 
      forwards a </FONT><BR><FONT size=2>&gt; token to the end-system and then 
      the end-system includes that token in the RSVP path </FONT><BR><FONT 
      size=2>&gt; message so that the reservation will go through. In this 
      manner the session layer does </FONT><BR><FONT size=2>&gt; not need to 
      communicate directly with the transport layer.</FONT> </P>
      <P><FONT size=2>[gwk] I do not understand what "the session" represents in 
      the above. It would seem </FONT><BR><FONT size=2>to me that you must have 
      a session level entity, and that to "forward a token to the</FONT> 
      <BR><FONT size=2>end-system", it must have an interface/api to the 
      "end-system". If this "end-system"</FONT> <BR><FONT size=2>is including 
      tokens in RSVP, then it is the entity setting up the transport QoS 
      (although</FONT> <BR><FONT size=2>it is not necessarly a transport layer 
      entity, but rather a signalling entity. If these</FONT> <BR><FONT 
      size=2>two entites are co-located, then you do not have layered signalling 
      protocols.</FONT> </P>
      <P><FONT size=2>Have I missed something?</FONT> </P>
      <P><FONT size=2><SPAN class=943153919-22012002><FONT face=Arial 
      color=#0000ff size=2>[Schneider, Marco]&nbsp;I don't think you have missed 
      anything. I may not have understood what you meant by a layering of 
      signaling protocols.</FONT></SPAN><SPAN class=943153919-22012002><FONT 
      size=3>&nbsp;</FONT><FONT face=Arial color=#0000ff size=2>Please define 
      this.</FONT></SPAN></FONT></P>
      <P><FONT size=2><SPAN class=943153919-22012002></SPAN>BTW: for many links, 
      particularly wireless, layered signalling is not a good idea.</FONT> 
      <BR><FONT size=2>And, in general, layered signalling will always be slower 
      then a single signalling protocol.</FONT> <BR><FONT size=2>&gt; So, the 
      question, </FONT><BR><FONT size=2>&gt; becomes, how are the QoS transport 
      mechanisms established? In the internet </FONT><BR><FONT size=2>&gt; model 
      there is only one end-to-end transport session (e.g. TCP, RTP, UDP), 
      </FONT><BR><FONT size=2>&gt; but underneath the transport is a series of 
      inter-connected networks, each </FONT><BR><FONT size=2>&gt; with 
      potentially different characteristics. </FONT><BR><FONT 
      size=2>&gt;&nbsp;&nbsp; This is end-to-end QoS support structure has to be 
      set up and maintained </FONT><BR><FONT size=2>&gt; in order for the end to 
      end session QoS to be realized. The solution may be </FONT><BR><FONT 
      size=2>&gt; a single protocol that travels from host to host, such as 
      RSVP, or it may </FONT><BR><FONT size=2>&gt; be a collection of protocols 
      that are optimized for each portion of the </FONT><BR><FONT size=2>&gt; 
      end-to-end path: e.g. host to access network, access to core network, 
      </FONT><BR><FONT size=2>&gt; core to core network, etc. </FONT><BR><FONT 
      size=2>&gt;&nbsp;&nbsp; It is too early to determine which approach is 
      best, but in either case, </FONT><BR><FONT size=2>&gt; do we not need to 
      understand the end-to-end requirements for this signalling 
      </FONT><BR><FONT size=2>&gt; capability? </FONT><BR><FONT size=2>&gt; 
      [MS]&nbsp; So by end-to-end you are referring to both the end-systems and 
      the devices in </FONT><BR><FONT size=2>&gt; between. As a point of 
      clarification, I asked Roy what he meant by "End-to-End </FONT><BR><FONT 
      size=2>&gt; Application Layer QOS Signaling" and his answer implied user 
      (end-system) to user (end-</FONT> <BR><FONT size=2>&gt; system).&nbsp; We 
      have been using the term end-to-end in different ways (contexts). The way 
      </FONT><BR><FONT size=2>&gt; I normally use the term "end-to-end" is to 
      include everything in between (all the </FONT><BR><FONT size=2>&gt; hops). 
      </FONT></P>
      <P><FONT size=2>[gwk] I see the difference. I would say that I tend 
      towards your definition, in the </FONT><BR><FONT size=2>following sense: 
      the only QoS that matters is what the end-user sees, so as a 
      service</FONT> <BR><FONT size=2>characteristic, it must be provided 
      between the two end systems / hosts. In order to do </FONT><BR><FONT 
      size=2>this, however, some level of support is required at each hop along 
      the path. <BR><FONT face=Arial><FONT color=#0000ff><SPAN 
      class=943153919-22012002><SPAN class=943153919-22012002>For me the term 
      end-to-end (for example end-to-end call flow) includes </SPAN>the 
      components within the network that must come together to make it work. The 
      term end-to-end application level signaling seems like an oxymoron since 
      this signaling occurs with no involvement of the network except to 
      transfer the data packets but perhaps there is something I am missing. 
      </SPAN></FONT></FONT></FONT></P>
      <P><FONT size=2><SPAN class=943153919-22012002>&nbsp;</SPAN>So, 
      establishing QoS between the end systems requires a peer-to-peer agreement 
      between</FONT> <BR><FONT size=2>the end systems, a host-to-cloud agreement 
      for the transport of the packets, and </FONT><BR><FONT size=2>some 
      mechanism within the cloud to ensure that the agreed upon QoS is 
      provided.</FONT> <BR><FONT size=2>Depending upon the complexity of the 
      cloud, the latter could imply all sorts of QoS</FONT> <BR><FONT 
      size=2>agreements between networks and even nodes, for packet 
      forwarding.</FONT> </P>
      <P><FONT size=2>&nbsp; Note that I have purposely NOT stated that any of 
      these agreements are negotiated or</FONT> <BR><FONT size=2>require a 
      signalling protocol. My opinion is that it is better in the long term 
      to</FONT> <BR><FONT size=2>support negotiated services using signalling, 
      as it provides more flexibility. However,</FONT> <BR><FONT size=2>this can 
      be overdone, say, as a silly example, by having the end-system negotiate 
      with</FONT> <BR><FONT size=2>every node in the network. So, the compromise 
      is that some of the QoS agreements will</FONT> <BR><FONT size=2>be 
      incorporated into the network design (e.g. Diff Serv), some will be 
      configured by</FONT> <BR><FONT size=2>the operator(s) (e.g. through 
      traffic engineering and policy management), and others</FONT> <BR><FONT 
      size=2>will be signalled. NSIS seems to be about determining where 
      signalling is appropriate,</FONT> <BR><FONT size=2>and what are the 
      signalling peers, and what is the best protocol solution or 
      solutions.</FONT> <BR><FONT size=2>The catch is that the first two 
      approaches actually encompass a wide variety of technologies</FONT> 
      <BR><FONT size=2>and scenarios.</FONT> <BR><FONT face=Arial><FONT 
      color=#0000ff><FONT size=2><SPAN 
      class=943153919-22012002>[</SPAN>Schneider, Marco]&nbsp;&nbsp;I think you 
      have articulated this very well and I am in general 
      agreement.&nbsp;</FONT></FONT></FONT></P>
      <P><FONT size=2>&nbsp; Sorry for stating the obvious. There is clearly 
      some concern over the use, for example,</FONT> <BR><FONT size=2>of RSVP, 
      and I suspect that some people are concerned that "end-to-end signalling" 
      also</FONT> <BR><FONT size=2>means "hop-by-hop" ala RSVP. It could, but it 
      does not have to.</FONT> <BR><SPAN class=943153919-22012002><FONT 
      face=Arial color=#0000ff size=2>[Schneider, Marco]&nbsp;I think this is a 
      very important distinction. I think that the reverse is true as well in 
      that some people are assuming a hop by hop linear signaling model wherein 
      the signaling takes place in order along the path that the data will 
      follow. The transport signaling that is going to occur within the 
      core&nbsp;of our&nbsp;network will be at a different timescale than UNI 
      signaling and there are a variety of solutions for this including RSVP-te 
      and CR-LDP which were developed for the purpose of allocating traffic 
      trunks.</FONT></SPAN></P>
      <P><SPAN class=943153919-22012002></SPAN><FONT size=2>&nbsp; So, my view 
      is that NSIS needs to ensure that the end-to-end QoS is provided for, 
      and</FONT> <BR><FONT size=2>develope the protocols where they are needed 
      (but not where they are not). At this point,</FONT> <BR><FONT size=2>that 
      would seem to be host to edge, edge to edge, and at the very least, with 
      enough</FONT> <BR><FONT size=2>end to end semantics to ensure that the 
      complete path supports QoS. I am concerned about</FONT> <BR><FONT 
      size=2>node to node signalling, as there are so many different approaches 
      to supporting node-to-node</FONT> <BR><FONT size=2>QoS. At the very least, 
      I would like to see a framework, and the edge solutions defined</FONT> 
      <BR><FONT size=2>before we delve into "intra-network" issues.</FONT> 
      <BR><SPAN class=943153919-22012002><FONT face=Arial color=#0000ff 
      size=2>[Schneider, Marco]&nbsp;I think it all begins with the fact that a 
      user must be able to request a QOS/COS connection/flow to another user. If 
      we can't do that then everything else would appear to be pointless. The 
      next question is whether we want to develop protocols that assist the 
      network portion&nbsp;in delivering this capability and in what 
      context(s).</FONT></SPAN><BR></P><SPAN class=943153919-22012002><FONT 
      face=Arial color=#0000ff size=2></FONT></SPAN>
      <P><FONT size=2>BTW: in writing this, it dawned upon me that it might be 
      best to write a series of</FONT> <BR><FONT size=2>requirements rather then 
      just one - i.e. tackle the problem piece by piece. This approach</FONT> 
      <BR><FONT size=2>does have drawbacks, but working groups seem to work 
      better when they focus on contained</FONT> <BR><FONT size=2>problem 
      domains. A strawman framework might be useful in keeping the incremental 
      solutions</FONT> <BR><FONT size=2>coherent.</FONT> <BR><SPAN 
      class=943153919-22012002><FONT face=Arial color=#0000ff size=2>[Schneider, 
      Marco]&nbsp;I agree with the idea of tackling the requirements by breaking 
      the problem up. There is a catch 22 in that in order to breakup it up we 
      must to some degree presuppose a solution.&nbsp;</FONT></SPAN></P><BR>
      <P><FONT size=2>&gt; [MS] I think our basic requirement is that an 
      end-system be able to request (and </FONT><BR><FONT size=2>&gt; receive) a 
      QOS connection to some other end-system (NSIS UNI). The request part 
      entails </FONT><BR><FONT size=2>&gt; an NSIS UNI. As you say the 
      realization of this request can be achieved in a number of 
      </FONT><BR><FONT size=2>&gt; different ways. Now one solution is to invent 
      an NSIS NNI that runs between domains. If </FONT><BR><FONT size=2>&gt; we 
      develop requirements for such an NSIS UNI then we have already preproposed 
      a </FONT><BR><FONT size=2>&gt; solution ahead of requirements. </FONT></P>
      <P><FONT size=2>[gwk] We have to be extremely careful not to become 
      pre-occupied with requirements</FONT> <BR><FONT size=2>definition. All 
      productive requirements definition efforts begin with assumptions 
      </FONT><BR><FONT size=2>concerning the solution. In my view, requirements 
      specifications are a balance between</FONT> <BR><FONT size=2>presumption 
      and prediction, particularly when dealing with "soft" techologies such 
      as</FONT> <BR><FONT size=2>protocols. The issue really is not whether a 
      requirement is a "MAY" or a "SHOULD" or</FONT> <BR><FONT size=2>whatever, 
      the issue is whether a requirement actually helps us define the 
      solution</FONT> <BR><FONT size=2>(there are lot's of examples of "SHOULD" 
      requirements that do not bring value to the</FONT> <BR><FONT size=2>design 
      process).</FONT> <BR><SPAN class=943153919-22012002><FONT face=Arial 
      color=#0000ff size=2>[Schneider, Marco]&nbsp;I think there is a danger in 
      implicit assumptions that may not lead to the best solution. 
      With&nbsp;respect to network support of a&nbsp;QOS request, there are many 
      different solutions and I am afraid that some participants have 
      presupposed a hop by hop signaling solution.&nbsp;</FONT></SPAN></P>
      <P><FONT size=2>Given my observation above about writing a series of 
      requirements, I would recommend </FONT><BR><FONT size=2>that we roughly 
      map out the solution(some would call this a "framework"). This map would 
      </FONT><BR><FONT size=2>form the preliminary list of deliverables for the 
      wg charter, and then pick a focussed </FONT><BR><FONT size=2>problem area 
      to begin with requirements. This is not "top down" design, but "top down" 
      </FONT><BR><FONT size=2>processes seldom work. If this seems too abstract, 
      what I am saying is that I have no </FONT><BR><FONT size=2>problem 
      identifying that there are N problem areas to be addressed - e.g. host to 
      edge, </FONT><BR><FONT size=2>edge to edge, node to node, etc. - and 
      picking anyone for the first design attempt. Of </FONT><BR><FONT 
      size=2>course, the challenge would be to keep an eye on the "big picture" 
      or end-to-end </FONT><BR><FONT size=2>requirements in the process.</FONT> 
      <BR><SPAN class=943153919-22012002><FONT face=Arial color=#0000ff 
      size=2>[Schneider, Marco]&nbsp;I think that the network context for 
      supporting NSIS UNI is a quagmire, albeit a very fun one. The problems we 
      need to address depend upon what end-to-end architectures we wish to 
      support. There are a number of capabilities already being developed for 
      network QOS and there may be a number of ways to "glue" these 
      together.</FONT></SPAN></P>
      <P><SPAN class=943153919-22012002><FONT face=Arial color=#0000ff 
      size=2>Deludedly yours,</FONT></SPAN></P>
      <P><SPAN class=943153919-22012002><FONT face=Arial color=#0000ff 
      size=2>Marco</FONT></SPAN></P>
      <P><SPAN class=943153919-22012002></SPAN><FONT size=2>Just my deluded 
      point of view.</FONT> <BR><FONT size=2>Cheers,</FONT> <BR><FONT 
      size=2>Gary</FONT> </P>
      <P><FONT size=2>[Schneider, Marco]&nbsp; </FONT><BR><FONT 
      size=2>*snip*</FONT> </P></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C1A396.EADD7B50--

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



From daemon@ns.ietf.org  Tue Jan 22 19:59: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 TAA15949
	for <nsis-archive@odin.ietf.org>; Tue, 22 Jan 2002 19:59:41 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id TAA20512
	for nsis-archive@odin.ietf.org; Tue, 22 Jan 2002 19:59: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 TAA19325;
	Tue, 22 Jan 2002 19:20: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 TAA19296
	for <nsis@ns.ietf.org>; Tue, 22 Jan 2002 19:20:45 -0500 (EST)
Received: from sierra.seas.upenn.edu (root@sierra.seas.upenn.edu [158.130.64.180])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15260
	for <nsis@ietf.org>; Tue, 22 Jan 2002 19:20:43 -0500 (EST)
Received: from cs.columbia.edu (DHCP64-23.SEAS.UPENN.EDU [158.130.64.102])
	by sierra.seas.upenn.edu (8.9.3/8.9.3) with ESMTP id TAA23051;
	Tue, 22 Jan 2002 19:20:38 -0500 (EST)
Message-ID: <3C4E01D8.6060205@cs.columbia.edu>
Date: Tue, 22 Jan 2002 19:20:40 -0500
From: Paulo Mendes <mendes@cs.columbia.edu>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1
X-Accept-Language: en-us
MIME-Version: 1.0
To: "Geib, Ruediger" <Ruediger.Geib@t-systems.com>
CC: john.loughney@nokia.com, nsis@ietf.org
Subject: Re: [NSIS] Support needed for Throughput Adaptive QoS in wireless
References: <DFD875E85664D3118FA6080006277DE70362C836@U8PN2>
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



Geib, Ruediger wrote:

> 
>>>I'd favour adaptive applications also in the QoS case. 
>>>Network to user re-negotiation means more complexity and it 
>>>requires extra signalling. Leave it to the apps. A network 
>>>may overbook, if it is aware that most apps are adaptive. 
>>>This requires no extra procedures.
>>>
>>NSIS cannot insist on adaptive applications, that is out of
>>scope.  Perhaps we could think that an NSIS protocol
>>could support re-negotiation (and allow a user to insist
>>on no re-negotiaion - but this starts to get into policy).
>>
> 
> I don't demand adaptive applications. All I say is that negotiation is not a basic QoS signalling requirement. 

I agree with John when he says that NSIS should provide support for 
re-negotiation/adaptation.
So, what is the NSIS requirement in this case? I think it's related with 
the type of information NSIS should provide to allow adaptation or 
re-negotiation.

Considering all the references to RSVP in this thread, the amount of 
resources reserved in the network can be the information to supply 
applications with. However this information is only useful if the 
network has per-flow reservation end-to-end, which isn't always true. If 
some kind of data aggregation in used in (part of) the network, e.g. 
DiffServ, the information that applications require from NSIS if not the 
amount of resources reserved to the DiffServ class/service they are 
using, but the amount of those resources that are allocated to their 
session.

Therefore, IMHO what applications need from a QoS signalling protocol is 
a dynamic notification about the rate they are entitle to receive during 
their session.
How is NSIS functionality affected by this requirement? IMHO, NSIS 
should consider the distribution of resources inside a DiffServ class 
and not only the resources reserved to each class in each domain by RSVP 
or other protocol. Probably this last sentence should be used when 
discussing NSIS functionality and not its requirements.:)

Best regards,
Paulo Mendes

-- 
| Paulo Mendes
| www.cs.columbia.edu/~mendes


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



From daemon@ns.ietf.org  Tue Jan 22 20:52: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 UAA17045
	for <nsis-archive@odin.ietf.org>; Tue, 22 Jan 2002 20:52:28 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id UAA22502
	for nsis-archive@odin.ietf.org; Tue, 22 Jan 2002 20:52:30 -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 UAA21507;
	Tue, 22 Jan 2002 20:28: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 UAA21476
	for <nsis@ns.ietf.org>; Tue, 22 Jan 2002 20:28:29 -0500 (EST)
Received: from sierra.seas.upenn.edu (root@sierra.seas.upenn.edu [158.130.64.180])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16666
	for <nsis@ietf.org>; Tue, 22 Jan 2002 20:28:25 -0500 (EST)
Received: from cs.columbia.edu (DHCP64-23.SEAS.UPENN.EDU [158.130.64.102])
	by sierra.seas.upenn.edu (8.9.3/8.9.3) with ESMTP id UAA27532;
	Tue, 22 Jan 2002 20:20:53 -0500 (EST)
Message-ID: <3C4E0FF7.5040606@cs.columbia.edu>
Date: Tue, 22 Jan 2002 20:20:55 -0500
From: Paulo Mendes <mendes@cs.columbia.edu>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1
X-Accept-Language: en-us
MIME-Version: 1.0
To: "Roy, Radhika R, ALASO" <rrroy@att.com>
CC: "Schneider, Marco" <schneider@tri.sbc.com>,
        Gary Kenward <gkenward@nortelnetworks.com>,
        "Loughney John (NRC/Helsinki)" <john.loughney@nokia.com>,
        brunner@ccrle.nec.de, Yaron Kahana <ykahana@comgates.co.il>,
        "Geib, Ruediger" <Ruediger.Geib@t-systems.com>, dick.rr.knight@bt.com,
        nsis@ietf.org
Subject: Re: [NSIS] Two kinds of requirements
References: <62DA45D4963FA747BA1B253E266760F9011E7BA0@OCCLUST04EVS1.ugd.att.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

If I understood correctly NSIS should be a QoS signalling protocol 
useful to all applications, right?

However it seems that this division between Application Layer QoS 
signalling (NSIS QoS) and posterior reservation request to the network 
for the necessary QoS agreed to at the session level only works for 
one-to-one applications, like IP telephony.

What happens with one-to-many applications like video-on-demand or 
InternetTV? In this case you can't establish a session level QoS 
agreement between provider and clients before the session starts (and so 
before the reservation of resources) because you would not know all your 
clients at that time.

Paulo Mendes




Roy, Radhika R, ALASO wrote:

> Hi, Marco:
> 
> Let me try to clarify from your point of view.
> 
> It seems to agree that there needs to be a session level QOS agreement. Let us analyze what is this. To make an agreement, we need to send some messages between the end points. This may be termed as "signaling."
> 
> A session expresses its QOS for its "application" that may consist of media: audio, video, and/or data.
> 
> In general, the above two items can be expressed as "Application Layer QOS signaling."
> 
> I think that we are agreeing on technical points.
> 
> Best regards,
> Radhika R. Roy
> 
> -----Original Message-----
> From: Schneider, Marco [mailto:schneider@tri.sbc.com]
> Sent: Friday, January 18, 2002 3:10 PM
> To: Roy, Radhika R, ALASO; Gary Kenward; Loughney John (NRC/Helsinki);
> brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
> dick.rr.knight@bt.com
> Cc: nsis@ietf.org
> Subject: RE: [NSIS] Two kinds of requirements
> 
> 
> Hi Roy,
> 
> Below is the original text from your reponse to Gary Kenward. Hopefully the
> context is clear.
> 
> "[Roy, Radhika R, ALARC]  I would say that it is the QOS needs of the
> application (e.g., SIP-based VoIP) that the user likes to express (as
> opposed to "service"). Similarly, instead of network services, we would say
> network layer QOS services (e.g., RSVP, DiffServ, MPLS). We would develop
> the end-to-end (application layer) QOS signaling protocol (say, NSIS QOS).
> Now, there needs to have some kinds of standards how NSIS QOS will be mapped
> over RSVP, DiffServ, MPLS, etc."
> 
> So by End-to-End you mean between directly between two "users". This is
> session level signaling and I don't believe the signaling part is within the
> scope of this working group. An application level QOS specification may be. 
> 
> After a session level agreement on QOS, the host/client/customer will need
> to signal an actual reservation request to the network for the necessary QOS
> agreed to at the session level. This is the protocol that we need to work
> on. 
> 
> This approach is discussed in the SIP draft "SIP Extensions for Media
> Authorization" (draft-ietf-sip-call-auth-03.txt) and the RAP draft
> "Framework for session set-up with media authorization"
> (draft-ietf-rap-session-auth-02.txt).
> 
> Marco Schneider
> 
> -----Original Message-----
> From: Roy, Radhika R, ALASO [mailto:rrroy@att.com]
> Sent: Friday, January 18, 2002 9:18 AM
> To: Schneider, Marco; Gary Kenward; Loughney John (NRC/Helsinki);
> brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
> dick.rr.knight@bt.com
> Cc: nsis@ietf.org
> Subject: RE: [NSIS] Two kinds of requirements
> 
> 
> Defined below [RRR]
> 
> -----Original Message-----
> From: Schneider, Marco [mailto:schneider@tri.sbc.com]
> Sent: Thursday, January 17, 2002 8:47 PM
> To: Roy, Radhika R, ALASO; Gary Kenward; Loughney John (NRC/Helsinki);
> brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
> dick.rr.knight@bt.com
> Cc: nsis@ietf.org
> Subject: RE: [NSIS] Two kinds of requirements
> 
> 
> Hi Roy,
> 
> Can you please define what you mean by "End-to-End Application Layer QOS
> Signaling". Thanks.
> 
> [RRR] Suppose an user is initiation a SIP call to another user with audio,
> video, and data. The use needs to express the needs of QOS for audio, video,
> and data to another user. 
> 
> [RRR] The signaling mechanism that allows to express the QOS parameters of
> audio, video, and data is termed as the "End-to-End Application Layer QOS
> Signaling."
> 
> Marco Schneider
> 
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis
> 


-- 
| Paulo Mendes
| www.cs.columbia.edu/~mendes


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



From daemon@ns.ietf.org  Tue Jan 22 21:27:27 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17486
	for <nsis-archive@odin.ietf.org>; Tue, 22 Jan 2002 21:27:27 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id VAA23568
	for nsis-archive@odin.ietf.org; Tue, 22 Jan 2002 21:27: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 VAA23356;
	Tue, 22 Jan 2002 21:17: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 VAA23321
	for <nsis@ns.ietf.org>; Tue, 22 Jan 2002 21:17:11 -0500 (EST)
Received: from sierra.seas.upenn.edu (root@sierra.seas.upenn.edu [158.130.64.180])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17352
	for <nsis@ietf.org>; Tue, 22 Jan 2002 21:17:07 -0500 (EST)
Received: from cs.columbia.edu (DHCP64-23.SEAS.UPENN.EDU [158.130.64.102])
	by sierra.seas.upenn.edu (8.9.3/8.9.3) with ESMTP id VAA01542;
	Tue, 22 Jan 2002 21:17:03 -0500 (EST)
Message-ID: <3C4E1D22.4070906@cs.columbia.edu>
Date: Tue, 22 Jan 2002 21:17:06 -0500
From: Paulo Mendes <mendes@cs.columbia.edu>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1
X-Accept-Language: en-us
MIME-Version: 1.0
To: "Roy, Radhika R, ALASO" <rrroy@att.com>
CC: john.loughney@nokia.com, Ruediger.Geib@t-systems.com, nsis@ietf.org
Subject: Re: [NSIS] Support needed for Throughput Adaptive QoS in wireless
References: <62DA45D4963FA747BA1B253E266760F90126C690@OCCLUST04EVS1.ugd.att.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

There are references in this thread to adaptive applications and 
applications that require re-negotiation of QoS parameters. However 
these are two different type of applications.
I agree with you that re-negotiation require extra signalling from NSIS. 
However this extra burden don't exist with adaptive applications, which 
I think only require to be notified by NSIS about the available network 
quality... So the requirements imposed to NSIS by these two types of 
applications are different.

Best Regards,
Paulo Mendes

Roy, Radhika R, ALASO wrote:

> Hi, John:
> 
> I agree with you and like to add a little more [RRR].
> 
> Best regards,
> Radhika
> 
> -----Original Message-----
> From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]
> Sent: Monday, January 21, 2002 8:25 AM
> To: Ruediger.Geib@t-systems.com
> Cc: nsis@ietf.org
> Subject: RE: [NSIS] Support needed for Throughput Adaptive QoS in
> wireless
> 
> 
> Hi all,
> 
> 
>>> I also think that the solution of over loading 
>>> should be managed by a local "higher hierarchy" 
>>> and not by the End-to-End reservation. This 
>>> local service controller should be aware of the 
>>> sessions, users, resources and commitments. 
>>> Hence could decide a "re-negotiation" or a drop.   
>>>
>>I'd favour adaptive applications also in the QoS case. 
>>Network to user re-negotiation means more complexity and it 
>>requires extra signalling. Leave it to the apps. A network 
>>may overbook, if it is aware that most apps are adaptive. 
>>This requires no extra procedures.
>>
> 
> NSIS cannot insist on adaptive applications, that is out of
> scope.  Perhaps we could think that an NSIS protocol
> could support re-negotiation (and allow a user to insist
> on no re-negotiaion - but this starts to get into policy).
> 
> [RRR] Negotiations and re-negotiations will also depend on wishes of the end users/points as well as the OQS availability in the lower layer (transport/network/physical) layers including the intermediate networks. NSIS will depend on the lower layers before the final acceptance is made. However, NSIS will not address the lower layer problems.
> 
> 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
> 


-- 
| Paulo Mendes
| www.cs.columbia.edu/~mendes


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



From daemon@ns.ietf.org  Tue Jan 22 21:52: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 VAA18881
	for <nsis-archive@odin.ietf.org>; Tue, 22 Jan 2002 21:52:19 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id VAA25207
	for nsis-archive@odin.ietf.org; Tue, 22 Jan 2002 21:52: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 VAA24408;
	Tue, 22 Jan 2002 21:40: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 VAA24372
	for <nsis@ns.ietf.org>; Tue, 22 Jan 2002 21:40:45 -0500 (EST)
Received: from sierra.seas.upenn.edu (root@sierra.seas.upenn.edu [158.130.64.180])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18699
	for <nsis@ietf.org>; Tue, 22 Jan 2002 21:40:41 -0500 (EST)
Received: from cs.columbia.edu (DHCP64-23.SEAS.UPENN.EDU [158.130.64.102])
	by sierra.seas.upenn.edu (8.9.3/8.9.3) with ESMTP id VAA03389;
	Tue, 22 Jan 2002 21:39:52 -0500 (EST)
Message-ID: <3C4E227A.7020802@cs.columbia.edu>
Date: Tue, 22 Jan 2002 21:39:54 -0500
From: Paulo Mendes <mendes@cs.columbia.edu>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1
X-Accept-Language: en-us
MIME-Version: 1.0
To: Hermann De Meer <h.demeer@ee.ucl.ac.uk>
CC: "Geib, Ruediger" <Ruediger.Geib@t-systems.com>, ykahana@comgates.co.il,
        gkenward@nortelnetworks.com, dick.rr.knight@bt.com,
        gilbert@rsch.comm.mot.com, nsis@ietf.org
Subject: Re: [NSIS] Support needed for Throughput Adaptive QoS in  wireless
References: <5.1.0.14.0.20020121200343.06a67b60@pop1.ee.ucl.ac.uk>
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

Comments below [PM]

Hermann De Meer wrote:

> Ruediger,
> Georgios,
> 
> At 10:15 21/01/2002 +0100, Geib, Ruediger wrote:
> 
>> >  I also think that the solution of over loading
>> >  should be managed by a local "higher hierarchy"
>> >  and not by the End-to-End reservation. This
>> >  local service controller should be aware of the
>> >  sessions, users, resources and commitments.
>> >  Hence could decide a "re-negotiation" or a drop.
>>
>> I'd favour adaptive applications also in the QoS case. Network to user 
>> re-negotiation means more complexity and it requires extra signalling. 
>> Leave it to the apps. A network may overbook, if it is aware that most 
>> apps are adaptive. This requires no extra procedures.
> 
> 
> I tend to agree ...


[PM] It makes two of us ...

> 
> 
>> Two further arguments:
>> - Plain old telephony used a compression scheme
>>   to save transatlantic capacity during high
>>   congestion (called DCME). No user was
>>   aware of that. The only extra signalling
>>   occured  between DCME units.
> 
> 
> this is a good observation!
> what it needs, however, from the signalling side is congestion 
> indication/notification.
> Now this is something that has traditionally been ignored within QoS 
> architectures
> and would be very useful  to be incorporated within NSIS, therefore.


[PM] It should be interesting to complement this congestion notification 
with some information to help applications to converge quickly to the 
optimal rate. Let say for example inform applications about the 
bandwidth the network allocs to their session. NSIS could get this 
information from network level protocols.

 
> more generally, as pointed out by Georgios, this can be referred to as 
> QoS violation signalling:
> network to network or network to edge/host etc.
> 
> extending Georgios' view:
> - it may as well be required in wired network segments (not only in 
> wireless segments)


[PM] I seems a good idea...


> - does not only apply to individual flows but also to whole aggregates 
> in the DiffServ sense,


[PM] I also agree with this.. However in the presence of aggregation the 
kind of notification NSIS provide adaptive application with, should have 
a higher fine-granularity. This is, notifications about the amount of 
resources reserved for the aggregate traffic isn't useful to applications.

Paulo Mendes


>   for example.
> 
> Please note, this does not necessarily mean re-negotiation.
> 
> Regards,
> Hermann
> 
> 
> 
>> - Say you support re-negotiation. Your cell
>>   supports 10 QoS reservations and the ten
>>   of them are used. Number 11 wants to enter
>>   and triggers a re-negotiation. Do you
>>   re-negotiate all of the ten existing
>>   reservations? Only one? If so, how do you
>>   decide on the candidate in a fair way?
>>
>> 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


-- 
| Paulo Mendes
| www.cs.columbia.edu/~mendes


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



From daemon@optimus.ietf.org  Wed Jan 23 02:17: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 CAA02424
	for <nsis-archive@odin.ietf.org>; Wed, 23 Jan 2002 02:17:16 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id CAA12081
	for nsis-archive@odin.ietf.org; Wed, 23 Jan 2002 02:17: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 CAA11688;
	Wed, 23 Jan 2002 02:07: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 CAA11657
	for <nsis@optimus.ietf.org>; Wed, 23 Jan 2002 02:07:34 -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 CAA02247
	for <nsis@ietf.org>; Wed, 23 Jan 2002 02:07:33 -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 g0N79fT11964;
	Wed, 23 Jan 2002 01:09:41 -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 g0N770o21612;
	Wed, 23 Jan 2002 01:07:00 -0600 (CST)
Received: by TRIMAIL2.ad.tri.sbc.com with Internet Mail Service (5.5.2653.19)
	id <ZND3269C>; Wed, 23 Jan 2002 01:07:27 -0600
Message-ID: <905A1C4ABF353F4C8CC16FA9F53DD0D632243B@TRIMAIL2.ad.tri.sbc.com>
From: "Chen, Weijing" <wchen@tri.sbc.com>
To: "'Freytsis, Ilya'" <ifreytsis@cetacean.com>
Cc: "'nsis@ietf.org'" <nsis@ietf.org>
Subject: RE: [NSIS] Two kinds of requirements
Date: Wed, 23 Jan 2002 01:07:19 -0600
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 CAA11658
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

Then I think that we as service operator background would be more than happy
to take this task with help from all the interested parties. The shooting
target would be sometime very before next IETF meeting (March?) Make sense?


--
Weijing Chen
SBC Technology Resources
9505 Arboretum Blvd.
Austin, TX 78759
512 372 5710
wchen@tri.sbc.com



-----Original Message-----
From: Freytsis, Ilya [mailto:ifreytsis@Cetacean.com] 
Sent: Tuesday, January 22, 2002 2:20 PM
To: 'nsis@ietf.org'
Subject: RE: [NSIS] Two kinds of requirements

Allen,

I think your suggestion to start with Use Cases can be very productive and
will help the group to move forward in two steps:
1. It will help to remove any terminology barriers (if any is still left) by
describing scenarios people have in their minds in very specific
(application/problem field) terms (no generalization is involved yet). This
way everybody gets on the same playing field while discussing cases. It
should clear clouds around such terms as end-to-end QoS, session level QoS,
application QoS etc.
2. When all cases are discussed and understood the generalization can be
made based on all of them with very little room left for misinterpretation.

Ilya Freytsis
Cetacean Networks Inc.
ph. (603) 766-6065
fax (603) 766-7190
ifreytsis@cetacean.com



From: "Allen, Keith" <kallen@tri.sbc.com>
To: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements
Date: Tue, 22 Jan 2002 08:34:10 -0600
charset="iso-8859-1"

Rüdiger,

I was, in fact, proposing a requirements document.  I was merely suggesting
that the requirements for the protocol be captured with a technique used in
the OO software industry (as well as elsewhere) called Use Cases.  The idea
behind Use Cases, simply put, is to describe the requirements for a system
from the user's point of view.  This is done with a set of use cases, each
one being a scenario describing how the user utilizes the system to
accomplish some task.  The descriptions of all the tasks performed by the
user represent the requirements the system must meet.  I have not seen Use
Cases applied to protocol development but I see no reason why it couldn't
be.  Simply identifying the user will help us to settle all these
edge-host-hop-proxy discussions.

Use cases are good at capturing functional requirements, but aren't so
applicable to other types of requirements.  For example, if someone out
there is insistent that one of the requirements is "Must interwork with
RSVP-TE," that's not so easily captured in a use case.  If we decide to use
Use Cases we might have to amend them with more traditional requirements.


Keith Allen
SBC Technology Resources
9505 Arboretum Blvd.
Austin, TX 78759
(512) 372-5741
kallen@tri.sbc.com

This e-mail and any files transmitted with it are the property of SBC, are
confidential, and are intended solely for the use of the individual or
entity to whom this e-mail is addressed. If you are not one of the named
recipient(s) or otherwise have reason to believe that you have received this
message in error, please notify the sender at (512) 372-5000 and delete this
message immediately from your computer. Any other use, retention,
dissemination, forwarding, printing, or copying of this e-mail is strictly
prohibited.


 -----Original Message-----
From: 	Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] 
Sent:	Tuesday, January 22, 2002 3:05 AM
To:	Allen, Keith
Cc:	nsis@ietf.org
Subject:	RE: [NSIS] Two kinds of requirements

Allen,

I'm not sure on IETF terminology, but what you suggest may be a framework
document. As framework documents are usual if new IETF activities begin,
your suggestion is a good one. I'd however favour a requirements document. I
am volunteering to co-author one (means contribution and review). 

Regards, Rüdiger

> Along the lines of my earlier reference to Use Cases, what do 
> you think about beginning to document the requirements the
> protocol should meet as a set of use cases describing how
> network users (or actually  their network devices) use the
> protocol-to-be to access the QoS capabilities of the
> network.  For example, one use case could show a voice over
> IP caller, another a network administrator setting up an
> Ethernet VPN, etc.  If the protocol has to support mobile
> handoffs, we would have a use  case showing
> that. It would give us a focal point instead of just e-mail.
 


_______________________________________________
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 Jan 23 02:44: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 CAA03089
	for <nsis-archive@odin.ietf.org>; Wed, 23 Jan 2002 02:44:44 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id CAA13373
	for nsis-archive@odin.ietf.org; Wed, 23 Jan 2002 02:44: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 CAA13015;
	Wed, 23 Jan 2002 02:34: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 CAA12986
	for <nsis@optimus.ietf.org>; Wed, 23 Jan 2002 02:34:19 -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 CAA02860
	for <nsis@ietf.org>; Wed, 23 Jan 2002 02:34:17 -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 g0N7YOn21582
	for <nsis@ietf.org>; Wed, 23 Jan 2002 09:34:24 +0200 (EET)
Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T589f1ac13eac158f21082@esvir01nok.ntc.nokia.com>;
 Wed, 23 Jan 2002 09:34:12 +0200
Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779);
	 Wed, 23 Jan 2002 09:33:50 +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] Two kinds of requirements
Date: Wed, 23 Jan 2002 09:33:50 +0200
Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF5D940D@esebe004.NOE.Nokia.com>
Thread-Topic: [NSIS] Two kinds of requirements
Thread-Index: AcGj3LF0TKhOKC5ZTp+1KfQkB+maegAA4Tlg
To: <wchen@tri.sbc.com>
Cc: <nsis@ietf.org>
X-OriginalArrivalTime: 23 Jan 2002 07:33:50.0934 (UTC) FILETIME=[4D61C760:01C1A3E0]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id CAA12987
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 Weijing,

> Then I think that we as service operator background would be 
> more than happy to take this task with help from all the interested 
> parties. The shooting target would be sometime very before next IETF 
> meeting (March?) Make sense?

I think a personal draft on this would be a great idea.  I imagine
that Dick would have a few things to add.

best regards,
John


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



From daemon@optimus.ietf.org  Wed Jan 23 04:38:30 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04413
	for <nsis-archive@odin.ietf.org>; Wed, 23 Jan 2002 04:38:30 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id EAA17676
	for nsis-archive@odin.ietf.org; Wed, 23 Jan 2002 04:38: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 EAA16969;
	Wed, 23 Jan 2002 04:28:42 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA16938
	for <nsis@optimus.ietf.org>; Wed, 23 Jan 2002 04:28:40 -0500 (EST)
Received: from cbibipnt03.HC.BT.COM (saturn.bt.com [193.113.57.20])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04314
	for <nsis@ietf.org>; Wed, 23 Jan 2002 04:28:37 -0500 (EST)
From: dick.rr.knight@bt.com
Received: by cbibipnt03.hc.bt.com with Internet Mail Service (5.5.2652.35)
	id <D39KH0T3>; Wed, 23 Jan 2002 09:28:18 -0000
Message-ID: <451D45016C2CD2119DA50000F8FE7F07080E5A60@mlngcbnt01.hc.bt.com>
To: mendes@cs.columbia.edu, rrroy@att.com
Cc: schneider@tri.sbc.com, gkenward@nortelnetworks.com,
        john.loughney@nokia.com, brunner@ccrle.nec.de, ykahana@comgates.co.il,
        Ruediger.Geib@t-systems.com, dick.rr.knight@bt.com, nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements
Date: Wed, 23 Jan 2002 09:27:56 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
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

Nice one. I was waiting for this.

So .. another new requirement. To support one-to-many applications.

There are two aspects to this:
1. The easy case. In internet TV, a provider (source of the TV) is
available. The first client uses NSIS to negotiate QoS with the network and
the source. Assuming the negotiation is successful a "connection" is
established. The second client then attepts to receive the TV. On initiating
the NSIS negotiation of QoS, they get a "take it or leave it" result of the
first client's negotiation. Anything else is not scalable.
2. A business conference will be established, with a known (limited) number
of clients. The provider can initiate the negotiation with the clients to
achieve the best possible QoS using the least resources.

The first case is no extra requirements above an IP telephony call. The
second requires multiparty negotiation at establishment.

Dick

-----Original Message-----
From: Paulo Mendes [mailto:mendes@cs.columbia.edu]
Sent: 23 January 2002 01:21
To: Roy, Radhika R, ALASO
Cc: Schneider, Marco; Gary Kenward; Loughney John (NRC/Helsinki);
brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
dick.rr.knight@bt.com; nsis@ietf.org
Subject: Re: [NSIS] Two kinds of requirements


If I understood correctly NSIS should be a QoS signalling protocol 
useful to all applications, right?

However it seems that this division between Application Layer QoS 
signalling (NSIS QoS) and posterior reservation request to the network 
for the necessary QoS agreed to at the session level only works for 
one-to-one applications, like IP telephony.

What happens with one-to-many applications like video-on-demand or 
InternetTV? In this case you can't establish a session level QoS 
agreement between provider and clients before the session starts (and so 
before the reservation of resources) because you would not know all your 
clients at that time.

Paulo Mendes




Roy, Radhika R, ALASO wrote:

> Hi, Marco:
> 
> Let me try to clarify from your point of view.
> 
> It seems to agree that there needs to be a session level QOS agreement.
Let us analyze what is this. To make an agreement, we need to send some
messages between the end points. This may be termed as "signaling."
> 
> A session expresses its QOS for its "application" that may consist of
media: audio, video, and/or data.
> 
> In general, the above two items can be expressed as "Application Layer QOS
signaling."
> 
> I think that we are agreeing on technical points.
> 
> Best regards,
> Radhika R. Roy
> 
> -----Original Message-----
> From: Schneider, Marco [mailto:schneider@tri.sbc.com]
> Sent: Friday, January 18, 2002 3:10 PM
> To: Roy, Radhika R, ALASO; Gary Kenward; Loughney John (NRC/Helsinki);
> brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
> dick.rr.knight@bt.com
> Cc: nsis@ietf.org
> Subject: RE: [NSIS] Two kinds of requirements
> 
> 
> Hi Roy,
> 
> Below is the original text from your reponse to Gary Kenward. Hopefully
the
> context is clear.
> 
> "[Roy, Radhika R, ALARC]  I would say that it is the QOS needs of the
> application (e.g., SIP-based VoIP) that the user likes to express (as
> opposed to "service"). Similarly, instead of network services, we would
say
> network layer QOS services (e.g., RSVP, DiffServ, MPLS). We would develop
> the end-to-end (application layer) QOS signaling protocol (say, NSIS QOS).
> Now, there needs to have some kinds of standards how NSIS QOS will be
mapped
> over RSVP, DiffServ, MPLS, etc."
> 
> So by End-to-End you mean between directly between two "users". This is
> session level signaling and I don't believe the signaling part is within
the
> scope of this working group. An application level QOS specification may
be. 
> 
> After a session level agreement on QOS, the host/client/customer will need
> to signal an actual reservation request to the network for the necessary
QOS
> agreed to at the session level. This is the protocol that we need to work
> on. 
> 
> This approach is discussed in the SIP draft "SIP Extensions for Media
> Authorization" (draft-ietf-sip-call-auth-03.txt) and the RAP draft
> "Framework for session set-up with media authorization"
> (draft-ietf-rap-session-auth-02.txt).
> 
> Marco Schneider
> 
> -----Original Message-----
> From: Roy, Radhika R, ALASO [mailto:rrroy@att.com]
> Sent: Friday, January 18, 2002 9:18 AM
> To: Schneider, Marco; Gary Kenward; Loughney John (NRC/Helsinki);
> brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
> dick.rr.knight@bt.com
> Cc: nsis@ietf.org
> Subject: RE: [NSIS] Two kinds of requirements
> 
> 
> Defined below [RRR]
> 
> -----Original Message-----
> From: Schneider, Marco [mailto:schneider@tri.sbc.com]
> Sent: Thursday, January 17, 2002 8:47 PM
> To: Roy, Radhika R, ALASO; Gary Kenward; Loughney John (NRC/Helsinki);
> brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
> dick.rr.knight@bt.com
> Cc: nsis@ietf.org
> Subject: RE: [NSIS] Two kinds of requirements
> 
> 
> Hi Roy,
> 
> Can you please define what you mean by "End-to-End Application Layer QOS
> Signaling". Thanks.
> 
> [RRR] Suppose an user is initiation a SIP call to another user with audio,
> video, and data. The use needs to express the needs of QOS for audio,
video,
> and data to another user. 
> 
> [RRR] The signaling mechanism that allows to express the QOS parameters of
> audio, video, and data is termed as the "End-to-End Application Layer QOS
> Signaling."
> 
> Marco Schneider
> 
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis
> 


-- 
| Paulo Mendes
| www.cs.columbia.edu/~mendes

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



From daemon@optimus.ietf.org  Wed Jan 23 05:05: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 FAA04772
	for <nsis-archive@odin.ietf.org>; Wed, 23 Jan 2002 05:05:56 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id FAA18879
	for nsis-archive@odin.ietf.org; Wed, 23 Jan 2002 05:05: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 EAA18203;
	Wed, 23 Jan 2002 04: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 EAA18170
	for <nsis@optimus.ietf.org>; Wed, 23 Jan 2002 04: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 EAA04667
	for <nsis@ietf.org>; Wed, 23 Jan 2002 04:56:29 -0500 (EST)
Received: from g8pbq.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Wed, 23 Jan 2002 10:54:09 +0100
Received: by G8PBQ.blf01.telekom.de with Internet Mail Service (5.5.2653.19)
	id <DQB694RX>; Wed, 23 Jan 2002 10:55:41 +0100
Message-Id: <DFD875E85664D3118FA6080006277DE70362C83E@U8PN2>
From: "Geib, Ruediger" <Ruediger.Geib@t-systems.com>
To: mendes@cs.columbia.edu, h.demeer@ee.ucl.ac.uk
Cc: nsis@ietf.org
Subject: RE: [NSIS] Support needed for Throughput Adaptive QoS in  wireles
	s
Date: Wed, 23 Jan 2002 09:56:48 +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 EAA18171
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

Paulo,

> [PM] It should be interesting to complement this congestion 
> notification with some information to help applications to
> converge quickly to the optimal rate. Let say for example
> inform applications about the bandwidth the network allocs
> to their session. NSIS could get this information from
> network level protocols.

Adding resource reduction information per application may be a good idea. But it means we'd have to find a simple way of letting the resource reducing node learn which applications currently are active and which amounts of rates may be reduced per application. It further may have to learn the addresses of these applications.
As you say, deriving rate reduction targets for aggregates may not be useful. Looking at a core network node, a congestion notification sent upstream certainly is reasonable. The rate/duration of congestion notifications or a signalled weight may indicate how severe the congestion is. "Per flow signalling nodes" closer to the application or the application itself could interpret the congestion notification and decide on target rates for applications. The absence of congestion notifications may then result in a return to standard rate.

Regards, Rüdiger  

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



From daemon@optimus.ietf.org  Wed Jan 23 05:06:26 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04791
	for <nsis-archive@odin.ietf.org>; Wed, 23 Jan 2002 05:06:25 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id FAA18911
	for nsis-archive@odin.ietf.org; Wed, 23 Jan 2002 05:06: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 EAA18283;
	Wed, 23 Jan 2002 04:57: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 EAA18212
	for <nsis@optimus.ietf.org>; Wed, 23 Jan 2002 04:57:17 -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 EAA04671
	for <nsis@ietf.org>; Wed, 23 Jan 2002 04:57:14 -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 g0N9vFIB026423
	for <nsis@ietf.org>; Wed, 23 Jan 2002 10:57:15 +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 <0GQD001M5YBDYP@mbb1.ericsson.se> for nsis@ietf.org; Wed,
 23 Jan 2002 10:57:15 +0100 (MET)
Date: Wed, 23 Jan 2002 10:57:38 +0100
From: David Partain <David.Partain@ericsson.com>
To: NSIS Mailing List <nsis@ietf.org>
Reply-to: David.Partain@ericsson.com
Message-id: <0GQD001M6YBEYP@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] Framework & requirements part of the "Two kinds of requirements" thread
Sender: nsis-admin@ietf.org
Errors-To: nsis-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Next Steps in Signaling <nsis.ietf.org>
X-BeenThere: nsis@ietf.org
Content-Transfer-Encoding: 8bit

Greetings all,

I'd like to offer my take on part of the thread "Two kinds
of requirements" to see if we can collectively reach any sort
of conclusion based on what's been written.  I doubt I'll say
anything new, but perhaps it'll help summarize a bit.

To cut to the chase, the conclusion of this mail is that
I think:

 - we should use the "framework" below as the starting point of
   framework discussions
 - the requirements should grow from use cases of particular
   applications that will use the network

The original mail postulated that people are wanting to work
on two kinds of requirements here:

 - end-host to end-host, or application to application
   signalling

 - transport level signalling

From that point, there has been a hearty debate about whether
this indeed is true, as well as a host of other issues.

I think the following points have been made, amongst others:

 - It should support the use of throughput adaptive applications
   and the ability for a traffic flow to express its QoS
   preferences with regard to the throughput values which it
   may be allocated.

 - One part of the thread was about whether RSVP and related
   work (e.g., RFC 2998), or perhaps SDPng, are suitable
   solutions.  While it's obvious that we need to learn from
   and perhaps start from one of these efforts in working on
   NSIS, it also seems clear that we shouldn't start working
   on that until the requirements are done.

 - There's no chance we'll create a single one-size-fits-all
   application-related signalling protocol that will be used
   by everyone.  That seems very clear.

 - There's a need for something transport independent that can
   help signal QoS needs across multiple domains in order
   to help the application-related signalling protocols do
   their thing.

The big issue there is what part of this we should solve here.
Should we concentrate specifically on the application/host
to network signalling?  I think not and others have agreed.
Should we try to design something that goes end to end?  If we
do that, do we have a "chicken and egg" problem of needing to
have the technology everywhere for things to work?

A case has been made that the goal should be to create a
signalling protocol that has different kinds of components
appropriate to different parts of the problem.  Georgios K.
proposed the following figure, which I like quite a lot and
which others have said is good, as a way of looking at it:

|-----|                                                  |-----|
|ehost|<------------------------------------------------>|ehost|
|-----|                                                  |-----|
|     |                                                  |     |
|-----|            |-----|            |-----|            |-----|
|eedge|<---------->|eedge|<---------->|eedge|<---------->|eedge|
|-----|            |-----|            |-----|            |-----|
|     |            |     |            |     |            |     |
|-----|   |----|   |-----|   |----|   |-----|   |----|   |-----|
|ehop |<->|ehop|<->|ehop |<->|ehop|<->|ehop |<->|ehop|<->|ehop |
|-----|   |----|   |-----|   |----|   |-----|   |----|   |-----|
 host    interior   edge    interior   edge     interior  host
         w/in domain       w/in domain        w/in domain

   ehost = everyhost
   eedge = everyedge
   ehop  = everyhop

NSIS protocol decomposition:

 * A "host" could be an end host or a proxy.  It can process
   and use the "everyhost", "everyedge", and "everyhop"
   protocol components.

 * An "edge" can be a Diffserv edge, MPLS edge, etc.  It can
   process and use the "everyedge", and "everyhop" protocol
   components. The "everyhost" protocol component is not
   processed (used or checked) but is carried onward.

 * An "interior within domain" can be any router within
   a domain.  It can process and use only the "everyhop"
   protocol component.  The "everyhost" and "everyedge"
   protocol components are not processed (used or checked)
   but are carried onward.

The everyhop bit within a domain provides signalling facilities
for that particular domain and is very likely to differ from
the everyhop bit used in the next boarding domain.

The point of all of this is to get a concatenation of results.
Each domain is responsible for taking its own decisions in its
own domain-specific ways.  The concatenation of the everyhop
decisions within a domain provides the domain's answer.
The concatenation of the domains' results gives and end to
end answer that can be used by the everyhost bit.

I think that having this overall framework -- for lack of a
better term -- in mind is very helpful.

If we can agree that this is a reasonable framework to use as
the basis of discussion, I think that what we need to do is
to produce a set of requirements for different "applications"
that will use these networks/this framework.  Indeed, I believe
this matches Keith Allen's request that requirements be based on
use cases.  If we know we're going to use the NSIS protocol on
a cellular wireless network (just to pull an example out of the
air :-)), then that "use case" implies a set of requirements.
A different scenario (e.g., the core of the network) implies
another set of requirements.

I personally think this is the right way forward and would
like to see this group move in this direction.

Georgios added some more thoughts on this topic
which addressed the applicability and prioritization
of work.  That can be found in the archive at
http://www1.ietf.org/mail-archive/working-groups/nsis/current/msg00418.html

I realize that I haven't covered everyone's particular topic
in this thread, but perhaps it'll help focus on one part of
the discussion.  If someone wants to summarize some other
sub-thread, that would be great...

Cheers,

dlp

ps. I think it would be very useful if Subject lines could more
accurately reflect the topic covered in the mail.  Long threads
with the same subject and covering a multitude of topics is
difficult to follow...

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



From daemon@optimus.ietf.org  Wed Jan 23 05:41: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 FAA05135
	for <nsis-archive@odin.ietf.org>; Wed, 23 Jan 2002 05:41:07 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id FAA20076
	for nsis-archive@odin.ietf.org; Wed, 23 Jan 2002 05:41: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 FAA19371;
	Wed, 23 Jan 2002 05:29: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 FAA19340
	for <nsis@optimus.ietf.org>; Wed, 23 Jan 2002 05:29:52 -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 FAA04963
	for <nsis@ietf.org>; Wed, 23 Jan 2002 05:29:48 -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 g0NATnIB027357
	for <nsis@ietf.org>; Wed, 23 Jan 2002 11:29:50 +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 <0GQD00ODUZTO8D@mbb1.ericsson.se> for nsis@ietf.org; Wed,
 23 Jan 2002 11:29:50 +0100 (MET)
Date: Wed, 23 Jan 2002 11:30:13 +0100
From: David Partain <David.Partain@ericsson.com>
In-reply-to: <905A1C4ABF353F4C8CC16FA9F53DD0D638B9A8@TRIMAIL2.ad.tri.sbc.com>
To: NSIS Mailing List <nsis@ietf.org>
Reply-to: David.Partain@ericsson.com
Message-id: <0GQD00ODVZTP8D@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: <905A1C4ABF353F4C8CC16FA9F53DD0D638B9A8@TRIMAIL2.ad.tri.sbc.com>
Content-Transfer-Encoding: 8bit
Subject: [NSIS] Georgios' framework decomposition (was Two kinds of 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 Karagiannis wrote:

> The possible NSIS protocol components that can be
> used on the different NSIS protocol types are the following:
>
>  * used components in "end host to end host" NSIS scenario:
>       [everyhost], [everyedge], [everyhop]
>
>  * used components in "end host to proxy" NSIS scenario:
>       [everyhost], [everyedge], [everyhop]
>
>  * used components in "end host to edge" NSIS scenario:
>       [everyedge], [everyhop]
>
>  * used components in "edge to edge" NSIS scenario:
>       [everyedge], [everyhop]
>
> Regarding the priority, we should decide it after the requirements,
> architecture and framework drafts are done!

Marco Schneider responded:

> Are you suggesting that we organize our requirements according to the
> implementation solution you have proposed below? If that is the case then I
> strongly disagree.

I don't see Georgios' framework figure or the text above as an
"implementation solution".  It's simply a way of taking a _big_
problem and breaking it down into smaller problem areas that
need attention.

The requirements, in my view, must be based upon the
applications that will use the network ("use case based
requirements").  There seem to be several voices pushing
for this.

If you could, please help me understand exactly what you
disagree with.

Cheers,

dlp

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



From daemon@optimus.ietf.org  Wed Jan 23 05:46: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 FAA05185
	for <nsis-archive@odin.ietf.org>; Wed, 23 Jan 2002 05:46:03 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id FAA20175
	for nsis-archive@odin.ietf.org; Wed, 23 Jan 2002 05:46: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 FAA19900;
	Wed, 23 Jan 2002 05:36: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 FAA19869
	for <nsis@optimus.ietf.org>; Wed, 23 Jan 2002 05:36:19 -0500 (EST)
Received: from newish7.ericsson.com.au (newish7.ericsson.com.au [203.61.155.116])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05034
	for <nsis@ietf.org>; Wed, 23 Jan 2002 05:36:14 -0500 (EST)
Received: from brsf10.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10])
	by newish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id VAA28495;
	Wed, 23 Jan 2002 21:34:52 +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 VAA00192;
	Wed, 23 Jan 2002 21:36:12 +1100 (EST)
Received: from localhost.localdomain (MINDY [147.214.68.87]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id XRFZ3Q9M; Wed, 23 Jan 2002 21:36:09 +1100
Subject: RE: [NSIS] Two kinds of requirements
From: Brian Williams <brian.williams@ericsson.com.au>
To: "Schneider, Marco" <schneider@tri.sbc.com>
Cc: "'Gary Kenward'" <gkenward@nortelnetworks.com>,
        "'Roy, Radhika R, ALASO'"
	 <rrroy@att.com>,
        Loughney  "John (NRC/Helsinki)" <john.loughney@nokia.com>,
        brunner@ccrle.nec.de, Yaron Kahana <ykahana@comgates.co.il>,
        "Geib, Ruediger"
	 <Ruediger.Geib@t-systems.com>,
        dick.rr.knight@bt.com, nsis@ietf.org
In-Reply-To: 
	<905A1C4ABF353F4C8CC16FA9F53DD0D638B9AB@TRIMAIL2.ad.tri.sbc.com>
References: <905A1C4ABF353F4C8CC16FA9F53DD0D638B9AB@TRIMAIL2.ad.tri.sbc.com>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Mailer: Evolution/1.0.1 
Date: 23 Jan 2002 21:32:08 +1100
Message-Id: <1011781936.2360.58.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 Marco.
On Wed, 2002-01-23 at 09:48, Schneider, Marco wrote:
> Garry,
>  
> >From an architectural/software perspective there is a session layer that
> is logically built on top of the transport capability. From a protocol
> stack perspective the session signaling is not layered on top of the
> transport signaling in the framework I described. 
>  
> Aside: The following scenario is conceivable but not desireable.
> Consider an ADSL customer that is logically connected to an edge router
> via a DSLAM and an edge switch. Thus the layer 3 hop is realized by
> multiple hops at layer 2. 
A similar but slightly different situation exists also with cellular
wireless networks. The layer 3 hop runs over one layer 2 hop, but this
layer 2 hop is actually overlayed on top of multiple underlying layer 2
hops. 

> Existing deployments that I am aware of use a
> preprovisioned PVC for this. Now imagine that the customer does session
> signaling resulting in NSIS signaling at layer 3. This could result in
> the need for a new layer 2 connection because the existing PVC will not
> do the job. 
Certanly the case for cellular that a new lasyer 2 connection coule be
required.

> Thus ATM UNI signaling might be initiated from the ADSL
> Customer to allocate the resources for the layer 3 logical link. Yuck!
> Obviously it is better to avoid this by pre-provisioning the access
> network appropriately. Nevertheless, there may be other circumstances
> where this type of situation will occur and one could imagine promoting
> the layer 2 devices to be aware of NSIS so as to avoid multiple levels
> of signaling. 
For the cellular case, the end host is the device that sets up the layer
2 connection. This connection must use separate signalling to allow
separate development of the layer 2 capabilities (ie dependent on
cellular technology). The host though must be able to relate the QoS
requirements signalled by NSIS to the layer 2 signalling. We are in the
process of producing a draft to clarify these requirements based on
typical layer 2 characteristics of cellular networks.
/brian
  
> Marco
>  
> -----Original Message-----
> From: Gary Kenward [mailto:gkenward@nortelnetworks.com]
> Sent: Tuesday, January 22, 2002 3:34 PM
> To: Schneider, Marco; 'Roy, Radhika R, ALASO'; Loughney John
> (NRC/Helsinki); brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
> dick.rr.knight@bt.com
> Cc: nsis@ietf.org
> Subject: RE: [NSIS] Two kinds of requirements
> 
> 
> 
> Marco:
>  
>    Good question: what do I mean by layering. I assume you are familiar
> with protocol layers and their
> properties. My major concern would be in the replication of information
> exchanges at each layer, resulting
> in greater overhead/delay. The end systems must to be involved in
> establishing the necessary QoS, including
> negotiation if viable, but the number of bits that are transported
> through the network to set up this QoS
> end to end must be kept to a minimum. Thus, I cringe at the possibility
> of an end-to-end application exchange
> triggering an RSVP request, triggering . . . in telephony terms, the
> analogy is the call setup delay, which has
> to be acceptable to the user, and, for wireless, has to be bandwidth
> efficient.
>  
>   I hope I have explained my concern.
>  
> Cheers,
> Gary
>  
>  
> 
> -----Original Message-----
> From: Schneider, Marco [mailto:schneider@tri.sbc.com]
> Sent: January 22, 2002 15:35
> To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Roy, Radhika R, ALASO'; Loughney
> John (NRC/Helsinki); brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
> dick.rr.knight@bt.com
> Cc: nsis@ietf.org
> Subject: RE: [NSIS] Two kinds of requirements
> 
> 
> Gary,
> 
> -----Original Message-----
> From: Gary Kenward [mailto:gkenward@nortelnetworks.com]
> Sent: Tuesday, January 22, 2002 9:02 AM
> To: Schneider, Marco; 'Roy, Radhika R, ALASO'; Loughney John
> (NRC/Helsinki); brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
> dick.rr.knight@bt.com
> Cc: nsis@ietf.org
> Subject: RE: [NSIS] Two kinds of requirements
> 
> 
> 
> Marco: 
> 
> -----Original Message----- 
> > [MS]  Yes, exactly. 
> >   I don't believe you are proposing a "layering" of signalling
> protocols, 
> > one for session establishment, then one for transport, etc. 
> > [MS]  This is exactly what has been proposed in RAP and SIP working
> groups to the best 
> > of my understanding. Because there does not exist a proxy signaling
> capability that 
> > allows a session to setup a connection on the users behalf, the
> session forwards a 
> > token to the end-system and then the end-system includes that token in
> the RSVP path 
> > message so that the reservation will go through. In this manner the
> session layer does 
> > not need to communicate directly with the transport layer. 
> 
> [gwk] I do not understand what "the session" represents in the above. It
> would seem 
> to me that you must have a session level entity, and that to "forward a
> token to the 
> end-system", it must have an interface/api to the "end-system". If this
> "end-system" 
> is including tokens in RSVP, then it is the entity setting up the
> transport QoS (although 
> it is not necessarly a transport layer entity, but rather a signalling
> entity. If these 
> two entites are co-located, then you do not have layered signalling
> protocols. 
> 
> Have I missed something? 
> 
> [Schneider, Marco] I don't think you have missed anything. I may not
> have understood what you meant by a layering of signaling protocols.
> Please define this.
> 
> BTW: for many links, particularly wireless, layered signalling is not a
> good idea. 
> And, in general, layered signalling will always be slower then a single
> signalling protocol. 
> > So, the question, 
> > becomes, how are the QoS transport mechanisms established? In the
> internet 
> > model there is only one end-to-end transport session (e.g. TCP, RTP,
> UDP), 
> > but underneath the transport is a series of inter-connected networks,
> each 
> > with potentially different characteristics. 
> >   This is end-to-end QoS support structure has to be set up and
> maintained 
> > in order for the end to end session QoS to be realized. The solution
> may be 
> > a single protocol that travels from host to host, such as RSVP, or it
> may 
> > be a collection of protocols that are optimized for each portion of
> the 
> > end-to-end path: e.g. host to access network, access to core network, 
> > core to core network, etc. 
> >   It is too early to determine which approach is best, but in either
> case, 
> > do we not need to understand the end-to-end requirements for this
> signalling 
> > capability? 
> > [MS]  So by end-to-end you are referring to both the end-systems and
> the devices in 
> > between. As a point of clarification, I asked Roy what he meant by
> "End-to-End 
> > Application Layer QOS Signaling" and his answer implied user
> (end-system) to user (end- 
> > system).  We have been using the term end-to-end in different ways
> (contexts). The way 
> > I normally use the term "end-to-end" is to include everything in
> between (all the 
> > hops). 
> 
> [gwk] I see the difference. I would say that I tend towards your
> definition, in the 
> following sense: the only QoS that matters is what the end-user sees, so
> as a service 
> characteristic, it must be provided between the two end systems / hosts.
> In order to do 
> this, however, some level of support is required at each hop along the
> path. 
> For me the term end-to-end (for example end-to-end call flow) includes
> the components within the network that must come together to make it
> work. The term end-to-end application level signaling seems like an
> oxymoron since this signaling occurs with no involvement of the network
> except to transfer the data packets but perhaps there is something I am
> missing. 
> 
>  So, establishing QoS between the end systems requires a peer-to-peer
> agreement between 
> the end systems, a host-to-cloud agreement for the transport of the
> packets, and 
> some mechanism within the cloud to ensure that the agreed upon QoS is
> provided. 
> Depending upon the complexity of the cloud, the latter could imply all
> sorts of QoS 
> agreements between networks and even nodes, for packet forwarding. 
> 
>   Note that I have purposely NOT stated that any of these agreements are
> negotiated or 
> require a signalling protocol. My opinion is that it is better in the
> long term to 
> support negotiated services using signalling, as it provides more
> flexibility. However, 
> this can be overdone, say, as a silly example, by having the end-system
> negotiate with 
> every node in the network. So, the compromise is that some of the QoS
> agreements will 
> be incorporated into the network design (e.g. Diff Serv), some will be
> configured by 
> the operator(s) (e.g. through traffic engineering and policy
> management), and others 
> will be signalled. NSIS seems to be about determining where signalling
> is appropriate, 
> and what are the signalling peers, and what is the best protocol
> solution or solutions. 
> The catch is that the first two approaches actually encompass a wide
> variety of technologies 
> and scenarios. 
> [Schneider, Marco]  I think you have articulated this very well and I am
> in general agreement. 
> 
>   Sorry for stating the obvious. There is clearly some concern over the
> use, for example, 
> of RSVP, and I suspect that some people are concerned that "end-to-end
> signalling" also 
> means "hop-by-hop" ala RSVP. It could, but it does not have to. 
> [Schneider, Marco] I think this is a very important distinction. I think
> that the reverse is true as well in that some people are assuming a hop
> by hop linear signaling model wherein the signaling takes place in order
> along the path that the data will follow. The transport signaling that
> is going to occur within the core of our network will be at a different
> timescale than UNI signaling and there are a variety of solutions for
> this including RSVP-te and CR-LDP which were developed for the purpose
> of allocating traffic trunks.
> 
>   So, my view is that NSIS needs to ensure that the end-to-end QoS is
> provided for, and 
> develope the protocols where they are needed (but not where they are
> not). At this point, 
> that would seem to be host to edge, edge to edge, and at the very least,
> with enough 
> end to end semantics to ensure that the complete path supports QoS. I am
> concerned about 
> node to node signalling, as there are so many different approaches to
> supporting node-to-node 
> QoS. At the very least, I would like to see a framework, and the edge
> solutions defined 
> before we delve into "intra-network" issues. 
> [Schneider, Marco] I think it all begins with the fact that a user must
> be able to request a QOS/COS connection/flow to another user. If we
> can't do that then everything else would appear to be pointless. The
> next question is whether we want to develop protocols that assist the
> network portion in delivering this capability and in what context(s).
> 
> 
> BTW: in writing this, it dawned upon me that it might be best to write a
> series of 
> requirements rather then just one - i.e. tackle the problem piece by
> piece. This approach 
> does have drawbacks, but working groups seem to work better when they
> focus on contained 
> problem domains. A strawman framework might be useful in keeping the
> incremental solutions 
> coherent. 
> [Schneider, Marco] I agree with the idea of tackling the requirements by
> breaking the problem up. There is a catch 22 in that in order to breakup
> it up we must to some degree presuppose a solution. 
> 
> 
> > [MS] I think our basic requirement is that an end-system be able to
> request (and 
> > receive) a QOS connection to some other end-system (NSIS UNI). The
> request part entails 
> > an NSIS UNI. As you say the realization of this request can be
> achieved in a number of 
> > different ways. Now one solution is to invent an NSIS NNI that runs
> between domains. If 
> > we develop requirements for such an NSIS UNI then we have already
> preproposed a 
> > solution ahead of requirements. 
> 
> [gwk] We have to be extremely careful not to become pre-occupied with
> requirements 
> definition. All productive requirements definition efforts begin with
> assumptions 
> concerning the solution. In my view, requirements specifications are a
> balance between 
> presumption and prediction, particularly when dealing with "soft"
> techologies such as 
> protocols. The issue really is not whether a requirement is a "MAY" or a
> "SHOULD" or 
> whatever, the issue is whether a requirement actually helps us define
> the solution 
> (there are lot's of examples of "SHOULD" requirements that do not bring
> value to the 
> design process). 
> [Schneider, Marco] I think there is a danger in implicit assumptions
> that may not lead to the best solution. With respect to network support
> of a QOS request, there are many different solutions and I am afraid
> that some participants have presupposed a hop by hop signaling solution.
> 
> 
> Given my observation above about writing a series of requirements, I
> would recommend 
> that we roughly map out the solution(some would call this a
> "framework"). This map would 
> form the preliminary list of deliverables for the wg charter, and then
> pick a focussed 
> problem area to begin with requirements. This is not "top down" design,
> but "top down" 
> processes seldom work. If this seems too abstract, what I am saying is
> that I have no 
> problem identifying that there are N problem areas to be addressed -
> e.g. host to edge, 
> edge to edge, node to node, etc. - and picking anyone for the first
> design attempt. Of 
> course, the challenge would be to keep an eye on the "big picture" or
> end-to-end 
> requirements in the process. 
> [Schneider, Marco] I think that the network context for supporting NSIS
> UNI is a quagmire, albeit a very fun one. The problems we need to
> address depend upon what end-to-end architectures we wish to support.
> There are a number of capabilities already being developed for network
> QOS and there may be a number of ways to "glue" these together.
> 
> Deludedly yours,
> 
> Marco
> 
> Just my deluded point of view. 
> Cheers, 
> Gary 
> 
> [Schneider, Marco]  
> *snip* 
> 



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



From daemon@optimus.ietf.org  Wed Jan 23 05:54:30 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05295
	for <nsis-archive@odin.ietf.org>; Wed, 23 Jan 2002 05:54:29 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id FAA20422
	for nsis-archive@odin.ietf.org; Wed, 23 Jan 2002 05:54: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 FAA20159;
	Wed, 23 Jan 2002 05:44: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 FAA20124
	for <nsis@optimus.ietf.org>; Wed, 23 Jan 2002 05:44:49 -0500 (EST)
Received: from newish7.ericsson.com.au (newish7.ericsson.com.au [203.61.155.116])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05166
	for <nsis@ietf.org>; Wed, 23 Jan 2002 05:44:44 -0500 (EST)
Received: from brsf10.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10])
	by newish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id VAA29287;
	Wed, 23 Jan 2002 21:43:25 +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 VAA01812;
	Wed, 23 Jan 2002 21:44:44 +1100 (EST)
Received: from localhost.localdomain (MINDY [147.214.68.87]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id XRFZ3RAS; Wed, 23 Jan 2002 21:44:41 +1100
Subject: RE: [NSIS] Two kinds of requirements
From: Brian Williams <brian.williams@ericsson.com.au>
To: Gary Kenward <gkenward@nortelnetworks.com>
Cc: "'Schneider, Marco'" <schneider@tri.sbc.com>,
        "'Roy, Radhika R, ALASO'"
	 <rrroy@att.com>,
        Loughney  "John (NRC/Helsinki)" <john.loughney@nokia.com>,
        brunner@ccrle.nec.de, Yaron Kahana <ykahana@comgates.co.il>,
        "Geib, Ruediger"
	 <Ruediger.Geib@t-systems.com>,
        dick.rr.knight@bt.com, nsis@ietf.org
In-Reply-To: 
	<9FBD322B7824D511B36900508BF93C9C01AA4795@zcard031.ca.nortel.com>
References: 
	<9FBD322B7824D511B36900508BF93C9C01AA4795@zcard031.ca.nortel.com>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Mailer: Evolution/1.0.1 
Date: 23 Jan 2002 21:40:41 +1100
Message-Id: <1011782448.1702.67.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

On Wed, 2002-01-23 at 08:33, Gary Kenward wrote:
> Marco:
>  
>    Good question: what do I mean by layering. I assume you are familiar
> with protocol layers and their
> properties. My major concern would be in the replication of information
> exchanges at each layer, resulting
> in greater overhead/delay. The end systems must to be involved in
> establishing the necessary QoS, including
> negotiation if viable, but the number of bits that are transported
> through the network to set up this QoS
> end to end must be kept to a minimum. Thus, I cringe at the possibility
> of an end-to-end application exchange
> triggering an RSVP request, triggering . . . in telephony terms, the
> analogy is the call setup delay, which has
> to be acceptable to the user, and, for wireless, has to be bandwidth
> efficient.
For cellular wireless networks, reducing the number of signalling layers
can reduce the amount of signalling, and possibly the setup delays.
However, wireless spectrum is critical in cellular wireless networks,
and optimising spectrum for a long session could have benefits over a
bit less signalling. Thus, it is better to have an additional signalling
layer to allow better use of the spectrum.  
/brian

>   I hope I have explained my concern.
>  
> Cheers,
> Gary
>  
>  
> 
> -----Original Message-----
> From: Schneider, Marco [mailto:schneider@tri.sbc.com]
> Sent: January 22, 2002 15:35
> To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Roy, Radhika R, ALASO'; Loughney
> John (NRC/Helsinki); brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
> dick.rr.knight@bt.com
> Cc: nsis@ietf.org
> Subject: RE: [NSIS] Two kinds of requirements
> 
> 
> Gary,
> 
> -----Original Message-----
> From: Gary Kenward [mailto:gkenward@nortelnetworks.com]
> Sent: Tuesday, January 22, 2002 9:02 AM
> To: Schneider, Marco; 'Roy, Radhika R, ALASO'; Loughney John
> (NRC/Helsinki); brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
> dick.rr.knight@bt.com
> Cc: nsis@ietf.org
> Subject: RE: [NSIS] Two kinds of requirements
> 
> 
> 
> Marco: 
> 
> -----Original Message----- 
> > [MS]  Yes, exactly. 
> >   I don't believe you are proposing a "layering" of signalling
> protocols, 
> > one for session establishment, then one for transport, etc. 
> > [MS]  This is exactly what has been proposed in RAP and SIP working
> groups to the best 
> > of my understanding. Because there does not exist a proxy signaling
> capability that 
> > allows a session to setup a connection on the users behalf, the
> session forwards a 
> > token to the end-system and then the end-system includes that token in
> the RSVP path 
> > message so that the reservation will go through. In this manner the
> session layer does 
> > not need to communicate directly with the transport layer. 
> 
> [gwk] I do not understand what "the session" represents in the above. It
> would seem 
> to me that you must have a session level entity, and that to "forward a
> token to the 
> end-system", it must have an interface/api to the "end-system". If this
> "end-system" 
> is including tokens in RSVP, then it is the entity setting up the
> transport QoS (although 
> it is not necessarly a transport layer entity, but rather a signalling
> entity. If these 
> two entites are co-located, then you do not have layered signalling
> protocols. 
> 
> Have I missed something? 
> 
> [Schneider, Marco] I don't think you have missed anything. I may not
> have understood what you meant by a layering of signaling protocols.
> Please define this.
> 
> BTW: for many links, particularly wireless, layered signalling is not a
> good idea. 
> And, in general, layered signalling will always be slower then a single
> signalling protocol. 
> > So, the question, 
> > becomes, how are the QoS transport mechanisms established? In the
> internet 
> > model there is only one end-to-end transport session (e.g. TCP, RTP,
> UDP), 
> > but underneath the transport is a series of inter-connected networks,
> each 
> > with potentially different characteristics. 
> >   This is end-to-end QoS support structure has to be set up and
> maintained 
> > in order for the end to end session QoS to be realized. The solution
> may be 
> > a single protocol that travels from host to host, such as RSVP, or it
> may 
> > be a collection of protocols that are optimized for each portion of
> the 
> > end-to-end path: e.g. host to access network, access to core network, 
> > core to core network, etc. 
> >   It is too early to determine which approach is best, but in either
> case, 
> > do we not need to understand the end-to-end requirements for this
> signalling 
> > capability? 
> > [MS]  So by end-to-end you are referring to both the end-systems and
> the devices in 
> > between. As a point of clarification, I asked Roy what he meant by
> "End-to-End 
> > Application Layer QOS Signaling" and his answer implied user
> (end-system) to user (end- 
> > system).  We have been using the term end-to-end in different ways
> (contexts). The way 
> > I normally use the term "end-to-end" is to include everything in
> between (all the 
> > hops). 
> 
> [gwk] I see the difference. I would say that I tend towards your
> definition, in the 
> following sense: the only QoS that matters is what the end-user sees, so
> as a service 
> characteristic, it must be provided between the two end systems / hosts.
> In order to do 
> this, however, some level of support is required at each hop along the
> path. 
> For me the term end-to-end (for example end-to-end call flow) includes
> the components within the network that must come together to make it
> work. The term end-to-end application level signaling seems like an
> oxymoron since this signaling occurs with no involvement of the network
> except to transfer the data packets but perhaps there is something I am
> missing. 
> 
>  So, establishing QoS between the end systems requires a peer-to-peer
> agreement between 
> the end systems, a host-to-cloud agreement for the transport of the
> packets, and 
> some mechanism within the cloud to ensure that the agreed upon QoS is
> provided. 
> Depending upon the complexity of the cloud, the latter could imply all
> sorts of QoS 
> agreements between networks and even nodes, for packet forwarding. 
> 
>   Note that I have purposely NOT stated that any of these agreements are
> negotiated or 
> require a signalling protocol. My opinion is that it is better in the
> long term to 
> support negotiated services using signalling, as it provides more
> flexibility. However, 
> this can be overdone, say, as a silly example, by having the end-system
> negotiate with 
> every node in the network. So, the compromise is that some of the QoS
> agreements will 
> be incorporated into the network design (e.g. Diff Serv), some will be
> configured by 
> the operator(s) (e.g. through traffic engineering and policy
> management), and others 
> will be signalled. NSIS seems to be about determining where signalling
> is appropriate, 
> and what are the signalling peers, and what is the best protocol
> solution or solutions. 
> The catch is that the first two approaches actually encompass a wide
> variety of technologies 
> and scenarios. 
> [Schneider, Marco]  I think you have articulated this very well and I am
> in general agreement. 
> 
>   Sorry for stating the obvious. There is clearly some concern over the
> use, for example, 
> of RSVP, and I suspect that some people are concerned that "end-to-end
> signalling" also 
> means "hop-by-hop" ala RSVP. It could, but it does not have to. 
> [Schneider, Marco] I think this is a very important distinction. I think
> that the reverse is true as well in that some people are assuming a hop
> by hop linear signaling model wherein the signaling takes place in order
> along the path that the data will follow. The transport signaling that
> is going to occur within the core of our network will be at a different
> timescale than UNI signaling and there are a variety of solutions for
> this including RSVP-te and CR-LDP which were developed for the purpose
> of allocating traffic trunks.
> 
>   So, my view is that NSIS needs to ensure that the end-to-end QoS is
> provided for, and 
> develope the protocols where they are needed (but not where they are
> not). At this point, 
> that would seem to be host to edge, edge to edge, and at the very least,
> with enough 
> end to end semantics to ensure that the complete path supports QoS. I am
> concerned about 
> node to node signalling, as there are so many different approaches to
> supporting node-to-node 
> QoS. At the very least, I would like to see a framework, and the edge
> solutions defined 
> before we delve into "intra-network" issues. 
> [Schneider, Marco] I think it all begins with the fact that a user must
> be able to request a QOS/COS connection/flow to another user. If we
> can't do that then everything else would appear to be pointless. The
> next question is whether we want to develop protocols that assist the
> network portion in delivering this capability and in what context(s).
> 
> 
> BTW: in writing this, it dawned upon me that it might be best to write a
> series of 
> requirements rather then just one - i.e. tackle the problem piece by
> piece. This approach 
> does have drawbacks, but working groups seem to work better when they
> focus on contained 
> problem domains. A strawman framework might be useful in keeping the
> incremental solutions 
> coherent. 
> [Schneider, Marco] I agree with the idea of tackling the requirements by
> breaking the problem up. There is a catch 22 in that in order to breakup
> it up we must to some degree presuppose a solution. 
> 
> 
> > [MS] I think our basic requirement is that an end-system be able to
> request (and 
> > receive) a QOS connection to some other end-system (NSIS UNI). The
> request part entails 
> > an NSIS UNI. As you say the realization of this request can be
> achieved in a number of 
> > different ways. Now one solution is to invent an NSIS NNI that runs
> between domains. If 
> > we develop requirements for such an NSIS UNI then we have already
> preproposed a 
> > solution ahead of requirements. 
> 
> [gwk] We have to be extremely careful not to become pre-occupied with
> requirements 
> definition. All productive requirements definition efforts begin with
> assumptions 
> concerning the solution. In my view, requirements specifications are a
> balance between 
> presumption and prediction, particularly when dealing with "soft"
> techologies such as 
> protocols. The issue really is not whether a requirement is a "MAY" or a
> "SHOULD" or 
> whatever, the issue is whether a requirement actually helps us define
> the solution 
> (there are lot's of examples of "SHOULD" requirements that do not bring
> value to the 
> design process). 
> [Schneider, Marco] I think there is a danger in implicit assumptions
> that may not lead to the best solution. With respect to network support
> of a QOS request, there are many different solutions and I am afraid
> that some participants have presupposed a hop by hop signaling solution.
> 
> 
> Given my observation above about writing a series of requirements, I
> would recommend 
> that we roughly map out the solution(some would call this a
> "framework"). This map would 
> form the preliminary list of deliverables for the wg charter, and then
> pick a focussed 
> problem area to begin with requirements. This is not "top down" design,
> but "top down" 
> processes seldom work. If this seems too abstract, what I am saying is
> that I have no 
> problem identifying that there are N problem areas to be addressed -
> e.g. host to edge, 
> edge to edge, node to node, etc. - and picking anyone for the first
> design attempt. Of 
> course, the challenge would be to keep an eye on the "big picture" or
> end-to-end 
> requirements in the process. 
> [Schneider, Marco] I think that the network context for supporting NSIS
> UNI is a quagmire, albeit a very fun one. The problems we need to
> address depend upon what end-to-end architectures we wish to support.
> There are a number of capabilities already being developed for network
> QOS and there may be a number of ways to "glue" these together.
> 
> Deludedly yours,
> 
> Marco
> 
> Just my deluded point of view. 
> Cheers, 
> Gary 
> 
> [Schneider, Marco]  
> *snip* 
> 



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



From daemon@optimus.ietf.org  Wed Jan 23 06:05: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 GAA05429
	for <nsis-archive@odin.ietf.org>; Wed, 23 Jan 2002 06:05:48 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id GAA21166
	for nsis-archive@odin.ietf.org; Wed, 23 Jan 2002 06:05: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 FAA20479;
	Wed, 23 Jan 2002 05:55: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 FAA20452
	for <nsis@optimus.ietf.org>; Wed, 23 Jan 2002 05:55:47 -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 FAA05309
	for <nsis@ietf.org>; Wed, 23 Jan 2002 05:55:43 -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 g0NAtiIB019375
	for <nsis@ietf.org>; Wed, 23 Jan 2002 11:55:45 +0100 (MET)
Received: FROM esealnt746.al.sw.ericsson.se BY esealnt461 ; Wed Jan 23 11:55:02 2002 +0100
Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <YHLJMF67>; Wed, 23 Jan 2002 11:55:19 +0100
Message-ID: <E244E44D6AB85E40AEEF7EAABE3545FA8233AA@enleent104.nl.eu.ericsson.se>
From: "Georgios Karagiannis (ELN)" <Georgios.Karagiannis@eln.ericsson.se>
To: "'Schneider, Marco'" <schneider@tri.sbc.com>
Cc: "'nsis@ietf.org'" <nsis@ietf.org>
Subject: RE: [NSIS] Georgios' framework decomposition (was Two kinds of re
	quirements)
Date: Wed, 23 Jan 2002 11:55: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 Marco

I agree with David's explanation (see below)!

Best Regards,
georgios

-----Original Message-----
From: David Partain [mailto:David.Partain@ericsson.com]
Sent: woensdag 23 januari 2002 11:30
To: NSIS Mailing List
Subject: [NSIS] Georgios' framework decomposition (was Two kinds of
requirements)


Hi,

Georgios Karagiannis wrote:

> The possible NSIS protocol components that can be
> used on the different NSIS protocol types are the following:
>
>  * used components in "end host to end host" NSIS scenario:
>       [everyhost], [everyedge], [everyhop]
>
>  * used components in "end host to proxy" NSIS scenario:
>       [everyhost], [everyedge], [everyhop]
>
>  * used components in "end host to edge" NSIS scenario:
>       [everyedge], [everyhop]
>
>  * used components in "edge to edge" NSIS scenario:
>       [everyedge], [everyhop]
>
> Regarding the priority, we should decide it after the requirements,
> architecture and framework drafts are done!

Marco Schneider responded:

> Are you suggesting that we organize our requirements according to the
> implementation solution you have proposed below? If that is the case then I
> strongly disagree.

I don't see Georgios' framework figure or the text above as an
"implementation solution".  It's simply a way of taking a _big_
problem and breaking it down into smaller problem areas that
need attention.

The requirements, in my view, must be based upon the
applications that will use the network ("use case based
requirements").  There seem to be several voices pushing
for this.

If you could, please help me understand exactly what you
disagree with.

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  Wed Jan 23 06:07:06 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05448
	for <nsis-archive@odin.ietf.org>; Wed, 23 Jan 2002 06:07:06 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id GAA21184
	for nsis-archive@odin.ietf.org; Wed, 23 Jan 2002 06:07: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 FAA20350;
	Wed, 23 Jan 2002 05:51: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 FAA20279
	for <nsis@optimus.ietf.org>; Wed, 23 Jan 2002 05:51:11 -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 FAA05271
	for <nsis@ietf.org>; Wed, 23 Jan 2002 05:51:07 -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 g0NAp6w14867;
	Wed, 23 Jan 2002 11:51: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 LAA28228; Wed, 23 Jan 2002 11:51:06 +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 LAA09641; Wed, 23 Jan 2002 11:51:06 +0100 (MET)
Date: Wed, 23 Jan 2002 11:51:06 +0100 (MET)
Message-Id: <200201231051.LAA09641@wrtw014.wrn.ki.sw.ericsson.se>
To: mendes@cs.columbia.edu
Subject: Re: [NSIS] Support needed for Throughput Adaptive QoS in wireless
Cc: nsis@ietf.org
X-Sun-Charset: US-ASCII
Sender: nsis-admin@ietf.org
Errors-To: nsis-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Next Steps in Signaling <nsis.ietf.org>
X-BeenThere: nsis@ietf.org


Paulo,

Paulo Mendes wrote :

> Considering all the references to RSVP in this thread, the amount of 
> resources reserved in the network can be the information to supply 
> applications with. However this information is only useful if the 
> network has per-flow reservation end-to-end, which isn't always true. If 
> some kind of data aggregation in used in (part of) the network, e.g. 
> DiffServ, the information that applications require from NSIS if not the 
> amount of resources reserved to the DiffServ class/service they are 
> using, but the amount of those resources that are allocated to their 
> session.
> 

[GF]
In my view it can also be useful if the NSIS protocol allows a certain
network segment to notify the host about the available resources either
at call setup time or during the call even there is aggregation in
some part(s) of the network. 

That is, the support of re-negotiation and adaptivity can be a 
useful feature even if there is no per-flow resource reservation end-to-end. 
An example of such a situation is a wireless access link that has
its own wireless reosurce manager that can notify the application 
about the wireless link status. Since the application runs over IP,
the wireless link manager needs to communicate with the IP level 
signaling entity in order to do this notification. 
[GF]

/Gabor

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



From daemon@optimus.ietf.org  Wed Jan 23 06:12: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 GAA05521
	for <nsis-archive@odin.ietf.org>; Wed, 23 Jan 2002 06:11:58 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id GAA21261
	for nsis-archive@odin.ietf.org; Wed, 23 Jan 2002 06:12:01 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA20909;
	Wed, 23 Jan 2002 06:00: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 GAA20868
	for <nsis@optimus.ietf.org>; Wed, 23 Jan 2002 06:00:34 -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 GAA05390
	for <nsis@ietf.org>; Wed, 23 Jan 2002 06:00:29 -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 g0NB0Vw24235
	for <nsis@ietf.org>; Wed, 23 Jan 2002 12:00:31 +0100 (MET)
Received: FROM esealnt746.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Wed Jan 23 12:00:27 2002 +0100
Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <YHLJMF84>; Wed, 23 Jan 2002 12:00:27 +0100
Message-ID: <E244E44D6AB85E40AEEF7EAABE3545FA8233AB@enleent104.nl.eu.ericsson.se>
From: "Georgios Karagiannis (ELN)" <Georgios.Karagiannis@eln.ericsson.se>
To: "'Chen, Weijing'" <wchen@tri.sbc.com>
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements
Date: Wed, 23 Jan 2002 12:00:08 +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 Weijing

In my opinion the definition/specification of the
type of the information associated 
to a protocol component could be a NSIS task.

Best regards,
Georgios

-----Original Message-----
From: Chen, Weijing [mailto:wchen@tri.sbc.com]
Sent: dinsdag 22 januari 2002 17:59
To: 'Georgios Karagiannis (ELN)'; Schneider, Marco
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


Georgios,

Do you mean the "protocol component" in the same semantic of "information
element" or "information object" in traditional signaling protocol?



--
Weijing Chen
SBC Technology Resources
9505 Arboretum Blvd.
Austin, TX 78759
512 372 5710
wchen@tri.sbc.com


-----Original Message-----
From: Georgios Karagiannis (ELN)
[mailto:Georgios.Karagiannis@eln.ericsson.se] 
Sent: Tuesday, January 22, 2002 3:39 AM
To: Schneider, Marco
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements

Hi Marco

The possible NSIS protocol components that can be 
used on the different NSIS protocol types are the following:

 * used components in "end host to end host" NSIS scenario: 
      [everyhost], [everyedge], [everyhop]

 * used components in "end host to proxy" NSIS scenario: 
      [everyhost], [everyedge], [everyhop]

 * used components in "end host to edge" NSIS scenario: 
      [everyedge], [everyhop]
 
 * used components in "edge to edge" NSIS scenario: 
      [everyedge], [everyhop]

Regarding the priority, we should decide it after the requirements,
architecture and framework drafts are done!

Best regards,
Georgios

-----Original Message-----
From: Schneider, Marco [mailto:schneider@tri.sbc.com]
Sent: dinsdag 22 januari 2002 1:03
To: 'Georgios Karagiannis (ELN)'; 'dick.rr.knight@bt.com'
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


Hi Georgios, All

If by x -- y you mean a protocol that runs directly between x and y (e.g.
end host -- end host, end host -- proxy...) then strictly speaking we are
discussing four  functionally distinct interfaces and thus four functionally
distinct protocols(possibly three if we group end host -- proxy and  end
host -- edge together). In my opinion: First we need to decide which of
these interfaces are in scope. Second we need to decide which one(s) we will
address first. Third we need to define the requirements for each for each of
the interfaces independently. 

With respect to scope and priority, I think we need to address in order:
1) end host -- edge/proxy
2) domain edge -- domain edge

 
Marco


-----Original Message-----
From: Georgios Karagiannis (ELN)
[mailto:Georgios.Karagiannis@eln.ericsson.se]
Sent: Monday, January 21, 2002 4:30 AM
To: 'dick.rr.knight@bt.com'
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements



Hi Dick

Please see my comment in line:
[DK]>> I do agree that it need not be processed on a per hop basis as it can
[DK]>> transverse a domain with a single QoS mechanism. That mechanism, be
it
[DK]>> diffserv or intserv, PNNI, RSVP, or even over-provisioning, takes
care of
[DK]>> the policing and the "path" establishment within the domain.

Please note that at the moment there are scenarios that will need to 
process the [everyhop] component. Some of these scenarios are the Radio
Access
Network and Mobile IP,..
Therefore, the [everyhop] component should be supported by the NSIS
protocol.
However a "host" or a "edge" should be able to activated or not.

Furthermore, in my opinion the NSIS protocol should be:
end host - end host: the NSIS protocol is terminated at end hosts;
end host - proxy: the NSIS protocol is terminated at end host and proxy;
end host - edge: the NSIS protocol is terminated at end end host and edge;
edge - edge: the NSIS protocol is terminated at egdes of one/multiple
domains;


Best regards,
Georgios


-----Original Message-----
From: Schneider, Marco [mailto:schneider@tri.sbc.com]
Sent: 18 January 2002 20:10
To: 'Roy, Radhika R, ALASO'; Gary Kenward; Loughney John (NRC/Helsinki);
brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
dick.rr.knight@bt.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


Hi Roy,

Below is the original text from your reponse to Gary Kenward. Hopefully the
context is clear.

"[Roy, Radhika R, ALARC]  I would say that it is the QOS needs of the
application (e.g., SIP-based VoIP) that the user likes to express (as
opposed to "service"). Similarly, instead of network services, we would say
network layer QOS services (e.g., RSVP, DiffServ, MPLS). We would develop
the end-to-end (application layer) QOS signaling protocol (say, NSIS QOS).
Now, there needs to have some kinds of standards how NSIS QOS will be mapped
over RSVP, DiffServ, MPLS, etc."

So by End-to-End you mean between directly between two "users". This is
session level signaling and I don't believe the signaling part is within the
scope of this working group. An application level QOS specification may be. 

After a session level agreement on QOS, the host/client/customer will need
to signal an actual reservation request to the network for the necessary QOS
agreed to at the session level. This is the protocol that we need to work
on. 

This approach is discussed in the SIP draft "SIP Extensions for Media
Authorization" (draft-ietf-sip-call-auth-03.txt) and the RAP draft
"Framework for session set-up with media authorization"
(draft-ietf-rap-session-auth-02.txt).

Marco Schneider

-----Original Message-----
From: Roy, Radhika R, ALASO [mailto:rrroy@att.com]
Sent: Friday, January 18, 2002 9:18 AM
To: Schneider, Marco; Gary Kenward; Loughney John (NRC/Helsinki);
brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
dick.rr.knight@bt.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


Defined below [RRR]

-----Original Message-----
From: Schneider, Marco [mailto:schneider@tri.sbc.com]
Sent: Thursday, January 17, 2002 8:47 PM
To: Roy, Radhika R, ALASO; Gary Kenward; Loughney John (NRC/Helsinki);
brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
dick.rr.knight@bt.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


Hi Roy,

Can you please define what you mean by "End-to-End Application Layer QOS
Signaling". Thanks.

[RRR] Suppose an user is initiation a SIP call to another user with audio,
video, and data. The use needs to express the needs of QOS for audio, video,
and data to another user. 

[RRR] The signaling mechanism that allows to express the QOS parameters of
audio, video, and data is termed as the "End-to-End Application Layer QOS
Signaling."

Marco Schneider

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

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

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

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



From daemon@optimus.ietf.org  Wed Jan 23 09:54: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 JAA10931
	for <nsis-archive@odin.ietf.org>; Wed, 23 Jan 2002 09:54:29 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id JAA28957
	for nsis-archive@odin.ietf.org; Wed, 23 Jan 2002 09:54:30 -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 JAA28698;
	Wed, 23 Jan 2002 09:43: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 JAA28665
	for <nsis@optimus.ietf.org>; Wed, 23 Jan 2002 09:43:56 -0500 (EST)
Received: from kcmso1.proxy.att.com (kcmso1.att.com [192.128.133.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10639
	for <nsis@ietf.org>; Wed, 23 Jan 2002 09:43:49 -0500 (EST)
Received: from attrh1i.attrh.att.com ([135.71.62.10])
	by kcmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id g0NEgon02738
	for <nsis@ietf.org>; Wed, 23 Jan 2002 09:42:56 -0500 (EST)
Received: from occlust04evs1.ugd.att.com (135.71.164.12) by attrh1i.attrh.att.com (5.5.029)
        id 3C0BA3A500261BB5; Wed, 23 Jan 2002 09:41:23 -0500
content-class: urn:content-classes:message
Subject: RE: [NSIS] Support needed for Throughput Adaptive QoS in wireless
Date: Wed, 23 Jan 2002 09:41:23 -0500
Message-ID: <62DA45D4963FA747BA1B253E266760F90126D047@OCCLUST04EVS1.ugd.att.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Thread-Topic: [NSIS] Support needed for Throughput Adaptive QoS in wireless
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
Thread-Index: AcGjtA5xedJi6g+lEda1uADgKSaxKgAZrHpA
From: "Roy, Radhika R, ALASO" <rrroy@att.com>
To: "Paulo Mendes" <mendes@cs.columbia.edu>
Cc: <john.loughney@nokia.com>, <Ruediger.Geib@t-systems.com>, <nsis@ietf.org>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id JAA28666
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


Inline [RRR]

-----Original Message-----
From: Paulo Mendes [mailto:mendes@cs.columbia.edu]
Sent: Tuesday, January 22, 2002 9:17 PM
To: Roy, Radhika R, ALASO
Cc: john.loughney@nokia.com; Ruediger.Geib@t-systems.com; nsis@ietf.org
Subject: Re: [NSIS] Support needed for Throughput Adaptive QoS in
wireless


There are references in this thread to adaptive applications and 
applications that require re-negotiation of QoS parameters. However 
these are two different type of applications.
I agree with you that re-negotiation require extra signalling from NSIS. 
However this extra burden don't exist with adaptive applications, which 
I think only require to be notified by NSIS about the available network 
quality... So the requirements imposed to NSIS by these two types of 
applications are different.

[RRR] Not really. We do not know what is the definition of adaptive application (can you cite an example that is being used?). If we assume that an adaptive application is able to adapt the QOS in accordance to the needs of the lower layer QOS, even then NSIS QOS will be able to satisfy its needs. Because the adaptive application, as I understand from your term with limited knowledge, will not use all capabilities of the NSIS QOS. It will rather will use a sub-set of the NSIS QOS capability.

[RRR] It is also not clear how an adaptive application will behave when QOS needs to be agreed upon between the two parties. Can you please provide some examples to know their behavior?

Best Regards,
Paulo Mendes

Roy, Radhika R, ALASO wrote:

> Hi, John:
> 
> I agree with you and like to add a little more [RRR].
> 
> Best regards,
> Radhika
> 

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



From daemon@optimus.ietf.org  Wed Jan 23 11:11:09 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14163
	for <nsis-archive@odin.ietf.org>; Wed, 23 Jan 2002 11:11:04 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id LAA02428
	for nsis-archive@odin.ietf.org; Wed, 23 Jan 2002 11:11: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 LAA01673;
	Wed, 23 Jan 2002 11:00: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 KAA01586
	for <nsis@optimus.ietf.org>; Wed, 23 Jan 2002 10:59:59 -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 KAA13643
	for <nsis@ietf.org>; Wed, 23 Jan 2002 10:59:55 -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 g0NFwPd02733;
	Wed, 23 Jan 2002 10:58:26 -0500 (EST)
Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7])
	by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g0NFwMV22216;
	Wed, 23 Jan 2002 10:58:22 -0500 (EST)
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19)
	id <C8PZZ1GW>; Wed, 23 Jan 2002 10:58:23 -0500
Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4796@zcard031.ca.nortel.com>
From: "Gary Kenward"<gkenward@nortelnetworks.com>
To: "'Schneider, Marco'" <schneider@tri.sbc.com>,
        "'Roy, Radhika R, ALASO'" <rrroy@att.com>,
        "Loughney John (NRC/Helsinki)"
	 <john.loughney@nokia.com>,
        brunner@ccrle.nec.de, Yaron Kahana
	 <ykahana@comgates.co.il>,
        "Geib, Ruediger" <Ruediger.Geib@t-systems.com>, dick.rr.knight@bt.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements
Date: Wed, 23 Jan 2002 10:58:21 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C1A426.C7CDCB70"
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_01C1A426.C7CDCB70
Content-Type: text/plain;
	charset="ISO-8859-1"

Marco:
 
  Good points. 

-----Original Message-----
From: Schneider, Marco [mailto:schneider@tri.sbc.com]
Sent: January 22, 2002 17:49
To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Roy, Radhika R, ALASO'; Loughney John
(NRC/Helsinki); brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
dick.rr.knight@bt.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


Garry,
 
From an architectural/software perspective there is a session layer that is
logically built on top of the transport capability. From a protocol stack
perspective the session signaling is not layered on top of the transport
signaling in the framework I described. 
[gwk] Yes, if I understand what you are saying, signalling stacks are often
defined in terms of a separate stack, parallel to the bearer layers;
sometimes the signalling protocols are layered, particularly between the
data link layer 
and above the data link layer.
 
Aside: The following scenario is conceivable but not desireable. Consider an
ADSL customer that is logically connected to an edge router via a DSLAM and
an edge switch. Thus the layer 3 hop is realized by multiple hops at layer
2. Existing deployments that I am aware of use a preprovisioned PVC for
this. Now imagine that the customer does session signaling resulting in NSIS
signaling at layer 3. This could result in the need for a new layer 2
connection because the existing PVC will not do the job. Thus ATM UNI
signaling might be initiated from the ADSL Customer to allocate the
resources for the layer 3 logical link. Yuck! Obviously it is better to
avoid this by pre-provisioning the access network appropriately.
Nevertheless, there may be other circumstances where this type of situation
will occur and one could imagine promoting the layer 2 devices to be aware
of NSIS so as to avoid multiple levels of signaling. 
[gwk] Another valid point. I suspect that consideration of L2 signalling is
out of scope for NSIS. It is a big issue for
wireless, where the over-the-air signalling happens mostly at the link
layer, and is highly optimized and specific for 
wireless (as Brian Williams describes in a response to your post). It might
be possible to include a requirement for 
interworking, which might at least allow co-location of the signalling end
points, which would at least help.
 
Regards,
Gary
 
Marco
 
-----Original Message-----
From: Gary Kenward [mailto:gkenward@nortelnetworks.com]
Sent: Tuesday, January 22, 2002 3:34 PM
To: Schneider, Marco; 'Roy, Radhika R, ALASO'; Loughney John (NRC/Helsinki);
brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger; dick.rr.knight@bt.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements



Marco:
 
   Good question: what do I mean by layering. I assume you are familiar with
protocol layers and their
properties. My major concern would be in the replication of information
exchanges at each layer, resulting
in greater overhead/delay. The end systems must to be involved in
establishing the necessary QoS, including
negotiation if viable, but the number of bits that are transported through
the network to set up this QoS
end to end must be kept to a minimum. Thus, I cringe at the possibility of
an end-to-end application exchange
triggering an RSVP request, triggering . . . in telephony terms, the analogy
is the call setup delay, which has
to be acceptable to the user, and, for wireless, has to be bandwidth
efficient.
 
  I hope I have explained my concern.
 
Cheers,
Gary
 
 

-----Original Message-----
From: Schneider, Marco [mailto:schneider@tri.sbc.com]
Sent: January 22, 2002 15:35
To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Roy, Radhika R, ALASO'; Loughney John
(NRC/Helsinki); brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
dick.rr.knight@bt.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


Gary,

-----Original Message-----
From: Gary Kenward [mailto:gkenward@nortelnetworks.com]
Sent: Tuesday, January 22, 2002 9:02 AM
To: Schneider, Marco; 'Roy, Radhika R, ALASO'; Loughney John (NRC/Helsinki);
brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger; dick.rr.knight@bt.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements



Marco: 

-----Original Message----- 
> [MS]  Yes, exactly. 
>   I don't believe you are proposing a "layering" of signalling protocols, 
> one for session establishment, then one for transport, etc. 
> [MS]  This is exactly what has been proposed in RAP and SIP working groups
to the best 
> of my understanding. Because there does not exist a proxy signaling
capability that 
> allows a session to setup a connection on the users behalf, the session
forwards a 
> token to the end-system and then the end-system includes that token in the
RSVP path 
> message so that the reservation will go through. In this manner the
session layer does 
> not need to communicate directly with the transport layer. 

[gwk] I do not understand what "the session" represents in the above. It
would seem 
to me that you must have a session level entity, and that to "forward a
token to the 
end-system", it must have an interface/api to the "end-system". If this
"end-system" 
is including tokens in RSVP, then it is the entity setting up the transport
QoS (although 
it is not necessarly a transport layer entity, but rather a signalling
entity. If these 
two entites are co-located, then you do not have layered signalling
protocols. 

Have I missed something? 

[Schneider, Marco] I don't think you have missed anything. I may not have
understood what you meant by a layering of signaling protocols. Please
define this.

BTW: for many links, particularly wireless, layered signalling is not a good
idea. 
And, in general, layered signalling will always be slower then a single
signalling protocol. 
> So, the question, 
> becomes, how are the QoS transport mechanisms established? In the internet

> model there is only one end-to-end transport session (e.g. TCP, RTP, UDP),

> but underneath the transport is a series of inter-connected networks, each

> with potentially different characteristics. 
>   This is end-to-end QoS support structure has to be set up and maintained

> in order for the end to end session QoS to be realized. The solution may
be 
> a single protocol that travels from host to host, such as RSVP, or it may 
> be a collection of protocols that are optimized for each portion of the 
> end-to-end path: e.g. host to access network, access to core network, 
> core to core network, etc. 
>   It is too early to determine which approach is best, but in either case,

> do we not need to understand the end-to-end requirements for this
signalling 
> capability? 
> [MS]  So by end-to-end you are referring to both the end-systems and the
devices in 
> between. As a point of clarification, I asked Roy what he meant by
"End-to-End 
> Application Layer QOS Signaling" and his answer implied user (end-system)
to user (end- 
> system).  We have been using the term end-to-end in different ways
(contexts). The way 
> I normally use the term "end-to-end" is to include everything in between
(all the 
> hops). 

[gwk] I see the difference. I would say that I tend towards your definition,
in the 
following sense: the only QoS that matters is what the end-user sees, so as
a service 
characteristic, it must be provided between the two end systems / hosts. In
order to do 
this, however, some level of support is required at each hop along the path.

For me the term end-to-end (for example end-to-end call flow) includes the
components within the network that must come together to make it work. The
term end-to-end application level signaling seems like an oxymoron since
this signaling occurs with no involvement of the network except to transfer
the data packets but perhaps there is something I am missing. 

 So, establishing QoS between the end systems requires a peer-to-peer
agreement between 
the end systems, a host-to-cloud agreement for the transport of the packets,
and 
some mechanism within the cloud to ensure that the agreed upon QoS is
provided. 
Depending upon the complexity of the cloud, the latter could imply all sorts
of QoS 
agreements between networks and even nodes, for packet forwarding. 

  Note that I have purposely NOT stated that any of these agreements are
negotiated or 
require a signalling protocol. My opinion is that it is better in the long
term to 
support negotiated services using signalling, as it provides more
flexibility. However, 
this can be overdone, say, as a silly example, by having the end-system
negotiate with 
every node in the network. So, the compromise is that some of the QoS
agreements will 
be incorporated into the network design (e.g. Diff Serv), some will be
configured by 
the operator(s) (e.g. through traffic engineering and policy management),
and others 
will be signalled. NSIS seems to be about determining where signalling is
appropriate, 
and what are the signalling peers, and what is the best protocol solution or
solutions. 
The catch is that the first two approaches actually encompass a wide variety
of technologies 
and scenarios. 
[Schneider, Marco]  I think you have articulated this very well and I am in
general agreement. 

  Sorry for stating the obvious. There is clearly some concern over the use,
for example, 
of RSVP, and I suspect that some people are concerned that "end-to-end
signalling" also 
means "hop-by-hop" ala RSVP. It could, but it does not have to. 
[Schneider, Marco] I think this is a very important distinction. I think
that the reverse is true as well in that some people are assuming a hop by
hop linear signaling model wherein the signaling takes place in order along
the path that the data will follow. The transport signaling that is going to
occur within the core of our network will be at a different timescale than
UNI signaling and there are a variety of solutions for this including
RSVP-te and CR-LDP which were developed for the purpose of allocating
traffic trunks.

  So, my view is that NSIS needs to ensure that the end-to-end QoS is
provided for, and 
develope the protocols where they are needed (but not where they are not).
At this point, 
that would seem to be host to edge, edge to edge, and at the very least,
with enough 
end to end semantics to ensure that the complete path supports QoS. I am
concerned about 
node to node signalling, as there are so many different approaches to
supporting node-to-node 
QoS. At the very least, I would like to see a framework, and the edge
solutions defined 
before we delve into "intra-network" issues. 
[Schneider, Marco] I think it all begins with the fact that a user must be
able to request a QOS/COS connection/flow to another user. If we can't do
that then everything else would appear to be pointless. The next question is
whether we want to develop protocols that assist the network portion in
delivering this capability and in what context(s).


BTW: in writing this, it dawned upon me that it might be best to write a
series of 
requirements rather then just one - i.e. tackle the problem piece by piece.
This approach 
does have drawbacks, but working groups seem to work better when they focus
on contained 
problem domains. A strawman framework might be useful in keeping the
incremental solutions 
coherent. 
[Schneider, Marco] I agree with the idea of tackling the requirements by
breaking the problem up. There is a catch 22 in that in order to breakup it
up we must to some degree presuppose a solution. 


> [MS] I think our basic requirement is that an end-system be able to
request (and 
> receive) a QOS connection to some other end-system (NSIS UNI). The request
part entails 
> an NSIS UNI. As you say the realization of this request can be achieved in
a number of 
> different ways. Now one solution is to invent an NSIS NNI that runs
between domains. If 
> we develop requirements for such an NSIS UNI then we have already
preproposed a 
> solution ahead of requirements. 

[gwk] We have to be extremely careful not to become pre-occupied with
requirements 
definition. All productive requirements definition efforts begin with
assumptions 
concerning the solution. In my view, requirements specifications are a
balance between 
presumption and prediction, particularly when dealing with "soft"
techologies such as 
protocols. The issue really is not whether a requirement is a "MAY" or a
"SHOULD" or 
whatever, the issue is whether a requirement actually helps us define the
solution 
(there are lot's of examples of "SHOULD" requirements that do not bring
value to the 
design process). 
[Schneider, Marco] I think there is a danger in implicit assumptions that
may not lead to the best solution. With respect to network support of a QOS
request, there are many different solutions and I am afraid that some
participants have presupposed a hop by hop signaling solution. 

Given my observation above about writing a series of requirements, I would
recommend 
that we roughly map out the solution(some would call this a "framework").
This map would 
form the preliminary list of deliverables for the wg charter, and then pick
a focussed 
problem area to begin with requirements. This is not "top down" design, but
"top down" 
processes seldom work. If this seems too abstract, what I am saying is that
I have no 
problem identifying that there are N problem areas to be addressed - e.g.
host to edge, 
edge to edge, node to node, etc. - and picking anyone for the first design
attempt. Of 
course, the challenge would be to keep an eye on the "big picture" or
end-to-end 
requirements in the process. 
[Schneider, Marco] I think that the network context for supporting NSIS UNI
is a quagmire, albeit a very fun one. The problems we need to address depend
upon what end-to-end architectures we wish to support. There are a number of
capabilities already being developed for network QOS and there may be a
number of ways to "glue" these together.

Deludedly yours,

Marco

Just my deluded point of view. 
Cheers, 
Gary 

[Schneider, Marco]  
*snip* 


------_=_NextPart_001_01C1A426.C7CDCB70
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">
<TITLE>RE: [NSIS] Two kinds of requirements</TITLE>

<META content="MSHTML 5.00.3315.2869" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT color=#0000ff face="Comic Sans MS"><SPAN 
class=444565715-23012002>Marco:</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face="Comic Sans MS"><SPAN 
class=444565715-23012002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face="Comic Sans MS"><SPAN 
class=444565715-23012002>&nbsp; Good points. </SPAN></FONT></DIV>
<BLOCKQUOTE dir=ltr 
style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">
  <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Schneider, Marco 
  [mailto:schneider@tri.sbc.com]<BR><B>Sent:</B> January 22, 2002 
  17:49<BR><B>To:</B> Kenward, Gary [WDLN2:AN10:EXCH]; 'Roy, Radhika R, ALASO'; 
  Loughney John (NRC/Helsinki); brunner@ccrle.nec.de; Yaron Kahana; Geib, 
  Ruediger; dick.rr.knight@bt.com<BR><B>Cc:</B> nsis@ietf.org<BR><B>Subject:</B> 
  RE: [NSIS] Two kinds of requirements<BR><BR></DIV></FONT>
  <DIV><SPAN class=717534121-22012002><FONT color=#0000ff face=Arial 
  size=2>Garry,</FONT></SPAN></DIV>
  <DIV><SPAN class=717534121-22012002><FONT color=#0000ff face=Arial 
  size=2></FONT></SPAN>&nbsp;</DIV>
  <DIV><FONT color=#0000ff><SPAN class=717534121-22012002><FONT face=Arial 
  size=2>From an architectural/software perspective there is a session 
  layer&nbsp;that is logically&nbsp;built on top of the transport capability. 
  From a protocol stack perspective the session signaling is not layered on top 
  of the transport signaling in the framework I described. <BR><FONT 
  face="Comic Sans MS" size=3><SPAN 
  class=444565715-23012002>[gwk]&nbsp;Yes,&nbsp;if I understand what you are 
  saying, signalling stacks are often defined in terms of a separate stack, 
  parallel to the bearer layers; sometimes the signalling protocols are layered, 
  particularly between the data link layer 
  </SPAN></FONT></FONT></SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff><SPAN class=717534121-22012002><FONT face=Arial 
  size=2><FONT face="Comic Sans MS" size=3><SPAN 
  class=444565715-23012002>and</SPAN></FONT></FONT></SPAN></FONT><FONT 
  color=#0000ff><SPAN class=717534121-22012002><FONT face=Arial size=2><FONT 
  face="Comic Sans MS" size=3><SPAN class=444565715-23012002> above the data 
  link layer.</SPAN></FONT></FONT></SPAN></FONT></DIV>
  <DIV><SPAN class=717534121-22012002><FONT color=#0000ff face=Arial 
  size=2></FONT></SPAN>&nbsp;</DIV>
  <DIV><FONT color=#0000ff><SPAN class=717534121-22012002><FONT face=Arial 
  size=2>Aside: The following scenario is conceivable but not 
  desireable.&nbsp;Consider an ADSL customer that </FONT></SPAN><SPAN 
  class=717534121-22012002><FONT face=Arial size=2>is&nbsp;logically connected 
  to an edge router via a DSLAM and an edge switch. Thus the layer 3 hop is 
  realized by multiple hops at layer 2. Existing deployments that I am aware of 
  use a preprovisioned PVC for this. </FONT></SPAN><SPAN 
  class=717534121-22012002></FONT><FONT color=#0000ff><FONT face=Arial 
  size=2>Now imagine that the customer does session signaling resulting in NSIS 
  signaling at layer 3. This could result in the need for a new layer 2 
  connection because the existing PVC will not do the job. Thus ATM UNI 
  signaling might be&nbsp;initiated from the ADSL Customer&nbsp;to allocate the 
  resources for the layer 3 logical link. Yuck! Obviously it is better to avoid 
  this by pre-provisioning the access network appropriately. Nevertheless, there 
  may be other circumstances where this type of situation will occur and one 
  could imagine promoting the layer 2 devices to be aware of NSIS so as to avoid 
  multiple levels of signaling. <BR><FONT face="Comic Sans MS" size=3><SPAN 
  class=444565715-23012002>[gwk]&nbsp;</SPAN></FONT></FONT></FONT></SPAN><SPAN 
  class=717534121-22012002><FONT color=#0000ff><FONT face=Arial size=2><FONT 
  face="Comic Sans MS" size=3><SPAN class=444565715-23012002>Another valid 
  point.&nbsp;I suspect that consideration of L2 signalling is out of scope for 
  NSIS. It is a big issue for</SPAN></FONT></FONT></FONT></SPAN></DIV>
  <DIV><SPAN class=717534121-22012002><FONT color=#0000ff><FONT face=Arial 
  size=2><FONT face="Comic Sans MS" size=3><SPAN 
  class=444565715-23012002>wireless, where the over-the-air signalling happens 
  mostly at the link layer, and is highly optimized and specific for 
  </SPAN></FONT></FONT></FONT></SPAN></DIV>
  <DIV><SPAN class=717534121-22012002><FONT color=#0000ff><FONT face=Arial 
  size=2><FONT face="Comic Sans MS" size=3><SPAN 
  class=444565715-23012002>wireless (as Brian Williams describes in a response 
  to your post). It might be possible to include a requirement for 
  </SPAN></FONT></FONT></FONT></SPAN></DIV>
  <DIV><SPAN class=717534121-22012002><FONT color=#0000ff><FONT face=Arial 
  size=2><FONT face="Comic Sans MS" size=3><SPAN 
  class=444565715-23012002>interworking, which might at least allow co-location 
  of the signalling end points, which would at least 
  help.</SPAN></FONT></FONT></FONT></SPAN></DIV>
  <DIV><SPAN class=717534121-22012002><FONT color=#0000ff><FONT face=Arial 
  size=2><FONT face="Comic Sans MS" size=3><SPAN 
  class=444565715-23012002></SPAN></FONT></FONT></FONT></SPAN>&nbsp;</DIV>
  <DIV><FONT color=#0000ff face="Comic Sans MS"><SPAN 
  class=444565715-23012002>Regards,</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face="Comic Sans MS"><SPAN 
  class=444565715-23012002>Gary</SPAN></FONT></DIV>
  <DIV><SPAN class=717534121-22012002><FONT color=#0000ff face=Arial 
  size=2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=717534121-22012002><FONT color=#0000ff face=Arial 
  size=2>Marco</FONT></SPAN></DIV>
  <DIV><SPAN class=717534121-22012002><FONT color=#0000ff face=Arial 
  size=2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=717534121-22012002></SPAN><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Gary Kenward 
  [mailto:gkenward@nortelnetworks.com]<BR><B>Sent:</B> Tuesday, January 22, 2002 
  3:34 PM<BR><B>To:</B> Schneider, Marco; 'Roy, Radhika R, ALASO'; Loughney John 
  (NRC/Helsinki); brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger; 
  dick.rr.knight@bt.com<BR><B>Cc:</B> nsis@ietf.org<BR><B>Subject:</B> RE: 
  [NSIS] Two kinds of requirements<BR><BR></DIV></FONT>
  <BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
    <DIV><FONT color=#0000ff face="Comic Sans MS"><SPAN 
    class=278125920-22012002>Marco:</SPAN></FONT></DIV>
    <DIV><FONT color=#0000ff face="Comic Sans MS"><SPAN 
    class=278125920-22012002></SPAN></FONT>&nbsp;</DIV>
    <DIV><FONT color=#0000ff face="Comic Sans MS"><SPAN 
    class=278125920-22012002>&nbsp;&nbsp; Good question: what do I mean by 
    layering. I assume you are familiar with protocol layers and 
    their</SPAN></FONT></DIV>
    <DIV><FONT color=#0000ff face="Comic Sans MS"><SPAN 
    class=278125920-22012002>properties. My major concern would be in the 
    replication of information exchanges at each layer, 
    resulting</SPAN></FONT></DIV>
    <DIV><FONT color=#0000ff face="Comic Sans MS"><SPAN 
    class=278125920-22012002>in greater overhead/delay. The end systems must to 
    be involved in establishing the necessary QoS, including</SPAN></FONT></DIV>
    <DIV><FONT color=#0000ff face="Comic Sans MS"><SPAN 
    class=278125920-22012002>negotiation if viable, but the number of bits that 
    are transported through the network to set up this QoS</SPAN></FONT></DIV>
    <DIV><FONT color=#0000ff face="Comic Sans MS"><SPAN 
    class=278125920-22012002>end to end must be kept to a minimum. Thus, I 
    cringe at the possibility of an end-to-end application 
    exchange</SPAN></FONT></DIV>
    <DIV><FONT color=#0000ff face="Comic Sans MS"><SPAN 
    class=278125920-22012002>triggering an RSVP request, triggering . . . in 
    telephony terms, the analogy is the call setup delay, which 
    has</SPAN></FONT></DIV>
    <DIV><FONT color=#0000ff face="Comic Sans MS"><SPAN 
    class=278125920-22012002>to be acceptable to the user, and, for wireless, 
    has to be bandwidth efficient.</SPAN></FONT></DIV>
    <DIV><FONT color=#0000ff face="Comic Sans MS"><SPAN 
    class=278125920-22012002></SPAN></FONT>&nbsp;</DIV>
    <DIV><FONT color=#0000ff face="Comic Sans MS"><SPAN 
    class=278125920-22012002>&nbsp; I hope I have explained my 
    concern.</SPAN></FONT></DIV>
    <DIV><FONT color=#0000ff face="Comic Sans MS"><SPAN 
    class=278125920-22012002></SPAN></FONT>&nbsp;</DIV>
    <DIV><FONT color=#0000ff face="Comic Sans MS"><SPAN 
    class=278125920-22012002>Cheers,</SPAN></FONT></DIV>
    <DIV><FONT color=#0000ff face="Comic Sans MS"><SPAN 
    class=278125920-22012002>Gary</SPAN></FONT></DIV>
    <DIV><FONT color=#0000ff face="Comic Sans MS"><SPAN 
    class=278125920-22012002></SPAN></FONT>&nbsp;</DIV>
    <DIV><FONT color=#0000ff face="Comic Sans MS"><SPAN 
    class=278125920-22012002></SPAN></FONT>&nbsp;</DIV>
    <BLOCKQUOTE dir=ltr 
    style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">
      <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
      size=2>-----Original Message-----<BR><B>From:</B> Schneider, Marco 
      [mailto:schneider@tri.sbc.com]<BR><B>Sent:</B> January 22, 2002 
      15:35<BR><B>To:</B> Kenward, Gary [WDLN2:AN10:EXCH]; 'Roy, Radhika R, 
      ALASO'; Loughney John (NRC/Helsinki); brunner@ccrle.nec.de; Yaron Kahana; 
      Geib, Ruediger; dick.rr.knight@bt.com<BR><B>Cc:</B> 
      nsis@ietf.org<BR><B>Subject:</B> RE: [NSIS] Two kinds of 
      requirements<BR><BR></DIV></FONT>
      <DIV><SPAN class=943153919-22012002><FONT color=#0000ff face=Arial 
      size=2>Gary,</FONT></SPAN></DIV>
      <BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
        <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
        size=2>-----Original Message-----<BR><B>From:</B> Gary Kenward 
        [mailto:gkenward@nortelnetworks.com]<BR><B>Sent:</B> Tuesday, January 
        22, 2002 9:02 AM<BR><B>To:</B> Schneider, Marco; 'Roy, Radhika R, 
        ALASO'; Loughney John (NRC/Helsinki); brunner@ccrle.nec.de; Yaron 
        Kahana; Geib, Ruediger; dick.rr.knight@bt.com<BR><B>Cc:</B> 
        nsis@ietf.org<BR><B>Subject:</B> RE: [NSIS] Two kinds of 
        requirements<BR><BR></FONT></DIV>
        <P><FONT size=2>Marco:</FONT> </P>
        <P><FONT size=2>-----Original Message-----</FONT> <BR><FONT size=2>&gt; 
        [MS]&nbsp; Yes, exactly.</FONT> <BR><FONT size=2>&gt;&nbsp;&nbsp; I 
        don't believe you are proposing a "layering" of signalling protocols, 
        </FONT><BR><FONT size=2>&gt; one for session establishment, then one for 
        transport, etc. </FONT><BR><FONT size=2>&gt; [MS]&nbsp; This is exactly 
        what has been proposed in RAP and SIP working groups to the best 
        </FONT><BR><FONT size=2>&gt; of my understanding. Because there does not 
        exist a proxy signaling capability that </FONT><BR><FONT size=2>&gt; 
        allows a session to setup a connection on the users behalf, the session 
        forwards a </FONT><BR><FONT size=2>&gt; token to the end-system and then 
        the end-system includes that token in the RSVP path </FONT><BR><FONT 
        size=2>&gt; message so that the reservation will go through. In this 
        manner the session layer does </FONT><BR><FONT size=2>&gt; not need to 
        communicate directly with the transport layer.</FONT> </P>
        <P><FONT size=2>[gwk] I do not understand what "the session" represents 
        in the above. It would seem </FONT><BR><FONT size=2>to me that you must 
        have a session level entity, and that to "forward a token to the</FONT> 
        <BR><FONT size=2>end-system", it must have an interface/api to the 
        "end-system". If this "end-system"</FONT> <BR><FONT size=2>is including 
        tokens in RSVP, then it is the entity setting up the transport QoS 
        (although</FONT> <BR><FONT size=2>it is not necessarly a transport layer 
        entity, but rather a signalling entity. If these</FONT> <BR><FONT 
        size=2>two entites are co-located, then you do not have layered 
        signalling protocols.</FONT> </P>
        <P><FONT size=2>Have I missed something?</FONT> </P>
        <P><FONT size=2><SPAN class=943153919-22012002><FONT color=#0000ff 
        face=Arial size=2>[Schneider, Marco]&nbsp;I don't think you have missed 
        anything. I may not have understood what you meant by a layering of 
        signaling protocols.</FONT></SPAN><SPAN class=943153919-22012002><FONT 
        size=3>&nbsp;</FONT><FONT color=#0000ff face=Arial size=2>Please define 
        this.</FONT></SPAN></FONT></P>
        <P><FONT size=2><SPAN class=943153919-22012002></SPAN>BTW: for many 
        links, particularly wireless, layered signalling is not a good 
        idea.</FONT> <BR><FONT size=2>And, in general, layered signalling will 
        always be slower then a single signalling protocol.</FONT> <BR><FONT 
        size=2>&gt; So, the question, </FONT><BR><FONT size=2>&gt; becomes, how 
        are the QoS transport mechanisms established? In the internet 
        </FONT><BR><FONT size=2>&gt; model there is only one end-to-end 
        transport session (e.g. TCP, RTP, UDP), </FONT><BR><FONT size=2>&gt; but 
        underneath the transport is a series of inter-connected networks, each 
        </FONT><BR><FONT size=2>&gt; with potentially different characteristics. 
        </FONT><BR><FONT size=2>&gt;&nbsp;&nbsp; This is end-to-end QoS support 
        structure has to be set up and maintained </FONT><BR><FONT size=2>&gt; 
        in order for the end to end session QoS to be realized. The solution may 
        be </FONT><BR><FONT size=2>&gt; a single protocol that travels from host 
        to host, such as RSVP, or it may </FONT><BR><FONT size=2>&gt; be a 
        collection of protocols that are optimized for each portion of the 
        </FONT><BR><FONT size=2>&gt; end-to-end path: e.g. host to access 
        network, access to core network, </FONT><BR><FONT size=2>&gt; core to 
        core network, etc. </FONT><BR><FONT size=2>&gt;&nbsp;&nbsp; It is too 
        early to determine which approach is best, but in either case, 
        </FONT><BR><FONT size=2>&gt; do we not need to understand the end-to-end 
        requirements for this signalling </FONT><BR><FONT size=2>&gt; 
        capability? </FONT><BR><FONT size=2>&gt; [MS]&nbsp; So by end-to-end you 
        are referring to both the end-systems and the devices in 
        </FONT><BR><FONT size=2>&gt; between. As a point of clarification, I 
        asked Roy what he meant by "End-to-End </FONT><BR><FONT size=2>&gt; 
        Application Layer QOS Signaling" and his answer implied user 
        (end-system) to user (end-</FONT> <BR><FONT size=2>&gt; system).&nbsp; 
        We have been using the term end-to-end in different ways (contexts). The 
        way </FONT><BR><FONT size=2>&gt; I normally use the term "end-to-end" is 
        to include everything in between (all the </FONT><BR><FONT size=2>&gt; 
        hops). </FONT></P>
        <P><FONT size=2>[gwk] I see the difference. I would say that I tend 
        towards your definition, in the </FONT><BR><FONT size=2>following sense: 
        the only QoS that matters is what the end-user sees, so as a 
        service</FONT> <BR><FONT size=2>characteristic, it must be provided 
        between the two end systems / hosts. In order to do </FONT><BR><FONT 
        size=2>this, however, some level of support is required at each hop 
        along the path. <BR><FONT face=Arial><FONT color=#0000ff><SPAN 
        class=943153919-22012002><SPAN class=943153919-22012002>For me the term 
        end-to-end (for example end-to-end call flow) includes </SPAN>the 
        components within the network that must come together to make it work. 
        The term end-to-end application level signaling seems like an oxymoron 
        since this signaling occurs with no involvement of the network except to 
        transfer the data packets but perhaps there is something I am missing. 
        </SPAN></FONT></FONT></FONT></P>
        <P><FONT size=2><SPAN class=943153919-22012002>&nbsp;</SPAN>So, 
        establishing QoS between the end systems requires a peer-to-peer 
        agreement between</FONT> <BR><FONT size=2>the end systems, a 
        host-to-cloud agreement for the transport of the packets, and 
        </FONT><BR><FONT size=2>some mechanism within the cloud to ensure that 
        the agreed upon QoS is provided.</FONT> <BR><FONT size=2>Depending upon 
        the complexity of the cloud, the latter could imply all sorts of 
        QoS</FONT> <BR><FONT size=2>agreements between networks and even nodes, 
        for packet forwarding.</FONT> </P>
        <P><FONT size=2>&nbsp; Note that I have purposely NOT stated that any of 
        these agreements are negotiated or</FONT> <BR><FONT size=2>require a 
        signalling protocol. My opinion is that it is better in the long term 
        to</FONT> <BR><FONT size=2>support negotiated services using signalling, 
        as it provides more flexibility. However,</FONT> <BR><FONT size=2>this 
        can be overdone, say, as a silly example, by having the end-system 
        negotiate with</FONT> <BR><FONT size=2>every node in the network. So, 
        the compromise is that some of the QoS agreements will</FONT> <BR><FONT 
        size=2>be incorporated into the network design (e.g. Diff Serv), some 
        will be configured by</FONT> <BR><FONT size=2>the operator(s) (e.g. 
        through traffic engineering and policy management), and others</FONT> 
        <BR><FONT size=2>will be signalled. NSIS seems to be about determining 
        where signalling is appropriate,</FONT> <BR><FONT size=2>and what are 
        the signalling peers, and what is the best protocol solution or 
        solutions.</FONT> <BR><FONT size=2>The catch is that the first two 
        approaches actually encompass a wide variety of technologies</FONT> 
        <BR><FONT size=2>and scenarios.</FONT> <BR><FONT face=Arial><FONT 
        color=#0000ff><FONT size=2><SPAN 
        class=943153919-22012002>[</SPAN>Schneider, Marco]&nbsp;&nbsp;I think 
        you have articulated this very well and I am in general 
        agreement.&nbsp;</FONT></FONT></FONT></P>
        <P><FONT size=2>&nbsp; Sorry for stating the obvious. There is clearly 
        some concern over the use, for example,</FONT> <BR><FONT size=2>of RSVP, 
        and I suspect that some people are concerned that "end-to-end 
        signalling" also</FONT> <BR><FONT size=2>means "hop-by-hop" ala RSVP. It 
        could, but it does not have to.</FONT> <BR><SPAN 
        class=943153919-22012002><FONT color=#0000ff face=Arial 
        size=2>[Schneider, Marco]&nbsp;I think this is a very important 
        distinction. I think that the reverse is true as well in that some 
        people are assuming a hop by hop linear signaling model wherein the 
        signaling takes place in order along the path that the data will follow. 
        The transport signaling that is going to occur within the core&nbsp;of 
        our&nbsp;network will be at a different timescale than UNI signaling and 
        there are a variety of solutions for this including RSVP-te and CR-LDP 
        which were developed for the purpose of allocating traffic 
        trunks.</FONT></SPAN></P>
        <P><SPAN class=943153919-22012002></SPAN><FONT size=2>&nbsp; So, my view 
        is that NSIS needs to ensure that the end-to-end QoS is provided for, 
        and</FONT> <BR><FONT size=2>develope the protocols where they are needed 
        (but not where they are not). At this point,</FONT> <BR><FONT 
        size=2>that would seem to be host to edge, edge to edge, and at the very 
        least, with enough</FONT> <BR><FONT size=2>end to end semantics to 
        ensure that the complete path supports QoS. I am concerned about</FONT> 
        <BR><FONT size=2>node to node signalling, as there are so many different 
        approaches to supporting node-to-node</FONT> <BR><FONT size=2>QoS. At 
        the very least, I would like to see a framework, and the edge solutions 
        defined</FONT> <BR><FONT size=2>before we delve into "intra-network" 
        issues.</FONT> <BR><SPAN class=943153919-22012002><FONT color=#0000ff 
        face=Arial size=2>[Schneider, Marco]&nbsp;I think it all begins with the 
        fact that a user must be able to request a QOS/COS connection/flow to 
        another user. If we can't do that then everything else would appear to 
        be pointless. The next question is whether we want to develop protocols 
        that assist the network portion&nbsp;in delivering this capability and 
        in what context(s).</FONT></SPAN><BR></P><SPAN 
        class=943153919-22012002><FONT color=#0000ff face=Arial 
        size=2></FONT></SPAN>
        <P><FONT size=2>BTW: in writing this, it dawned upon me that it might be 
        best to write a series of</FONT> <BR><FONT size=2>requirements rather 
        then just one - i.e. tackle the problem piece by piece. This 
        approach</FONT> <BR><FONT size=2>does have drawbacks, but working groups 
        seem to work better when they focus on contained</FONT> <BR><FONT 
        size=2>problem domains. A strawman framework might be useful in keeping 
        the incremental solutions</FONT> <BR><FONT size=2>coherent.</FONT> 
        <BR><SPAN class=943153919-22012002><FONT color=#0000ff face=Arial 
        size=2>[Schneider, Marco]&nbsp;I agree with the idea of tackling the 
        requirements by breaking the problem up. There is a catch 22 in that in 
        order to breakup it up we must to some degree presuppose a 
        solution.&nbsp;</FONT></SPAN></P><BR>
        <P><FONT size=2>&gt; [MS] I think our basic requirement is that an 
        end-system be able to request (and </FONT><BR><FONT size=2>&gt; receive) 
        a QOS connection to some other end-system (NSIS UNI). The request part 
        entails </FONT><BR><FONT size=2>&gt; an NSIS UNI. As you say the 
        realization of this request can be achieved in a number of 
        </FONT><BR><FONT size=2>&gt; different ways. Now one solution is to 
        invent an NSIS NNI that runs between domains. If </FONT><BR><FONT 
        size=2>&gt; we develop requirements for such an NSIS UNI then we have 
        already preproposed a </FONT><BR><FONT size=2>&gt; solution ahead of 
        requirements. </FONT></P>
        <P><FONT size=2>[gwk] We have to be extremely careful not to become 
        pre-occupied with requirements</FONT> <BR><FONT size=2>definition. All 
        productive requirements definition efforts begin with assumptions 
        </FONT><BR><FONT size=2>concerning the solution. In my view, 
        requirements specifications are a balance between</FONT> <BR><FONT 
        size=2>presumption and prediction, particularly when dealing with "soft" 
        techologies such as</FONT> <BR><FONT size=2>protocols. The issue really 
        is not whether a requirement is a "MAY" or a "SHOULD" or</FONT> 
        <BR><FONT size=2>whatever, the issue is whether a requirement actually 
        helps us define the solution</FONT> <BR><FONT size=2>(there are lot's of 
        examples of "SHOULD" requirements that do not bring value to the</FONT> 
        <BR><FONT size=2>design process).</FONT> <BR><SPAN 
        class=943153919-22012002><FONT color=#0000ff face=Arial 
        size=2>[Schneider, Marco]&nbsp;I think there is a danger in implicit 
        assumptions that may not lead to the best solution. With&nbsp;respect to 
        network support of a&nbsp;QOS request, there are many different 
        solutions and I am afraid that some participants have presupposed a hop 
        by hop signaling solution.&nbsp;</FONT></SPAN></P>
        <P><FONT size=2>Given my observation above about writing a series of 
        requirements, I would recommend </FONT><BR><FONT size=2>that we roughly 
        map out the solution(some would call this a "framework"). This map would 
        </FONT><BR><FONT size=2>form the preliminary list of deliverables for 
        the wg charter, and then pick a focussed </FONT><BR><FONT size=2>problem 
        area to begin with requirements. This is not "top down" design, but "top 
        down" </FONT><BR><FONT size=2>processes seldom work. If this seems too 
        abstract, what I am saying is that I have no </FONT><BR><FONT 
        size=2>problem identifying that there are N problem areas to be 
        addressed - e.g. host to edge, </FONT><BR><FONT size=2>edge to edge, 
        node to node, etc. - and picking anyone for the first design attempt. Of 
        </FONT><BR><FONT size=2>course, the challenge would be to keep an eye on 
        the "big picture" or end-to-end </FONT><BR><FONT size=2>requirements in 
        the process.</FONT> <BR><SPAN class=943153919-22012002><FONT 
        color=#0000ff face=Arial size=2>[Schneider, Marco]&nbsp;I think that the 
        network context for supporting NSIS UNI is a quagmire, albeit a very fun 
        one. The problems we need to address depend upon what end-to-end 
        architectures we wish to support. There are a number of capabilities 
        already being developed for network QOS and there may be a number of 
        ways to "glue" these together.</FONT></SPAN></P>
        <P><SPAN class=943153919-22012002><FONT color=#0000ff face=Arial 
        size=2>Deludedly yours,</FONT></SPAN></P>
        <P><SPAN class=943153919-22012002><FONT color=#0000ff face=Arial 
        size=2>Marco</FONT></SPAN></P>
        <P><SPAN class=943153919-22012002></SPAN><FONT size=2>Just my deluded 
        point of view.</FONT> <BR><FONT size=2>Cheers,</FONT> <BR><FONT 
        size=2>Gary</FONT> </P>
        <P><FONT size=2>[Schneider, Marco]&nbsp; </FONT><BR><FONT 
        size=2>*snip*</FONT> 
</P></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C1A426.C7CDCB70--

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



From daemon@optimus.ietf.org  Wed Jan 23 11:29: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 LAA15042
	for <nsis-archive@odin.ietf.org>; Wed, 23 Jan 2002 11:29:19 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id LAA03029
	for nsis-archive@odin.ietf.org; Wed, 23 Jan 2002 11:29: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 LAA02710;
	Wed, 23 Jan 2002 11:19: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 LAA02266
	for <nsis@optimus.ietf.org>; Wed, 23 Jan 2002 11:06:18 -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 LAA13937
	for <nsis@ietf.org>; Wed, 23 Jan 2002 11:06:15 -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 g0NG5id26641;
	Wed, 23 Jan 2002 11:05:44 -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 g0NG5gV22739;
	Wed, 23 Jan 2002 11:05:42 -0500 (EST)
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19)
	id <C8PZZ1PC>; Wed, 23 Jan 2002 11:05:43 -0500
Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA479A@zcard031.ca.nortel.com>
From: "Gary Kenward"<gkenward@nortelnetworks.com>
To: "'Brian Williams'" <brian.williams@ericsson.com.au>
Cc: "'Schneider, Marco'" <schneider@tri.sbc.com>,
        "'Roy, Radhika R, ALASO'" <rrroy@att.com>,
        "Loughney  \"John (NRC/Helsinki)" <john.loughney@nokia.com>,
        brunner@ccrle.nec.de, Yaron Kahana <ykahana@comgates.co.il>,
        "Geib, Ruediger" <Ruediger.Geib@t-systems.com>, dick.rr.knight@bt.com,
        nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements
Date: Wed, 23 Jan 2002 11:05:41 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C1A427.CE5596C0"
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_01C1A427.CE5596C0
Content-Type: text/plain;
	charset="ISO-8859-1"

Brian:

  Understood. A similar argument to that put forth for handover.
We shall have to see how the solutions map out. My bias, when it
comes to signalling, is that less is always better, even for wireless.

Gary

> -----Original Message-----
> From: Brian Williams [mailto:brian.williams@ericsson.com.au]
> Sent: January 23, 2002 05:41
> To: Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: 'Schneider, Marco'; 'Roy, Radhika R, ALASO'; Loughney "John
> (NRC/Helsinki); brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
> dick.rr.knight@bt.com; nsis@ietf.org
> Subject: RE: [NSIS] Two kinds of requirements
> 
> 
> On Wed, 2002-01-23 at 08:33, Gary Kenward wrote:
> > Marco:
> >  
> >    Good question: what do I mean by layering. I assume you 
> are familiar
> > with protocol layers and their
> > properties. My major concern would be in the replication of 
> information
> > exchanges at each layer, resulting
> > in greater overhead/delay. The end systems must to be involved in
> > establishing the necessary QoS, including
> > negotiation if viable, but the number of bits that are transported
> > through the network to set up this QoS
> > end to end must be kept to a minimum. Thus, I cringe at the 
> possibility
> > of an end-to-end application exchange
> > triggering an RSVP request, triggering . . . in telephony terms, the
> > analogy is the call setup delay, which has
> > to be acceptable to the user, and, for wireless, has to be bandwidth
> > efficient.
> For cellular wireless networks, reducing the number of 
> signalling layers
> can reduce the amount of signalling, and possibly the setup delays.
> However, wireless spectrum is critical in cellular wireless networks,
> and optimising spectrum for a long session could have benefits over a
> bit less signalling. Thus, it is better to have an additional 
> signalling
> layer to allow better use of the spectrum.  
> /brian
> 
> >   I hope I have explained my concern.
> >  
> > Cheers,
> > Gary
> >  
> >  
> > 
> > -----Original Message-----
> > From: Schneider, Marco [mailto:schneider@tri.sbc.com]
> > Sent: January 22, 2002 15:35
> > To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Roy, Radhika R, 
> ALASO'; Loughney
> > John (NRC/Helsinki); brunner@ccrle.nec.de; Yaron Kahana; 
> Geib, Ruediger;
> > dick.rr.knight@bt.com
> > Cc: nsis@ietf.org
> > Subject: RE: [NSIS] Two kinds of requirements
> > 
> > 
> > Gary,
> > 
> > -----Original Message-----
> > From: Gary Kenward [mailto:gkenward@nortelnetworks.com]
> > Sent: Tuesday, January 22, 2002 9:02 AM
> > To: Schneider, Marco; 'Roy, Radhika R, ALASO'; Loughney John
> > (NRC/Helsinki); brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
> > dick.rr.knight@bt.com
> > Cc: nsis@ietf.org
> > Subject: RE: [NSIS] Two kinds of requirements
> > 
> > 
> > 
> > Marco: 
> > 
> > -----Original Message----- 
> > > [MS]  Yes, exactly. 
> > >   I don't believe you are proposing a "layering" of signalling
> > protocols, 
> > > one for session establishment, then one for transport, etc. 
> > > [MS]  This is exactly what has been proposed in RAP and 
> SIP working
> > groups to the best 
> > > of my understanding. Because there does not exist a proxy 
> signaling
> > capability that 
> > > allows a session to setup a connection on the users behalf, the
> > session forwards a 
> > > token to the end-system and then the end-system includes 
> that token in
> > the RSVP path 
> > > message so that the reservation will go through. In this 
> manner the
> > session layer does 
> > > not need to communicate directly with the transport layer. 
> > 
> > [gwk] I do not understand what "the session" represents in 
> the above. It
> > would seem 
> > to me that you must have a session level entity, and that 
> to "forward a
> > token to the 
> > end-system", it must have an interface/api to the 
> "end-system". If this
> > "end-system" 
> > is including tokens in RSVP, then it is the entity setting up the
> > transport QoS (although 
> > it is not necessarly a transport layer entity, but rather a 
> signalling
> > entity. If these 
> > two entites are co-located, then you do not have layered signalling
> > protocols. 
> > 
> > Have I missed something? 
> > 
> > [Schneider, Marco] I don't think you have missed anything. I may not
> > have understood what you meant by a layering of signaling protocols.
> > Please define this.
> > 
> > BTW: for many links, particularly wireless, layered 
> signalling is not a
> > good idea. 
> > And, in general, layered signalling will always be slower 
> then a single
> > signalling protocol. 
> > > So, the question, 
> > > becomes, how are the QoS transport mechanisms established? In the
> > internet 
> > > model there is only one end-to-end transport session 
> (e.g. TCP, RTP,
> > UDP), 
> > > but underneath the transport is a series of 
> inter-connected networks,
> > each 
> > > with potentially different characteristics. 
> > >   This is end-to-end QoS support structure has to be set up and
> > maintained 
> > > in order for the end to end session QoS to be realized. 
> The solution
> > may be 
> > > a single protocol that travels from host to host, such as 
> RSVP, or it
> > may 
> > > be a collection of protocols that are optimized for each 
> portion of
> > the 
> > > end-to-end path: e.g. host to access network, access to 
> core network, 
> > > core to core network, etc. 
> > >   It is too early to determine which approach is best, 
> but in either
> > case, 
> > > do we not need to understand the end-to-end requirements for this
> > signalling 
> > > capability? 
> > > [MS]  So by end-to-end you are referring to both the 
> end-systems and
> > the devices in 
> > > between. As a point of clarification, I asked Roy what he meant by
> > "End-to-End 
> > > Application Layer QOS Signaling" and his answer implied user
> > (end-system) to user (end- 
> > > system).  We have been using the term end-to-end in different ways
> > (contexts). The way 
> > > I normally use the term "end-to-end" is to include everything in
> > between (all the 
> > > hops). 
> > 
> > [gwk] I see the difference. I would say that I tend towards your
> > definition, in the 
> > following sense: the only QoS that matters is what the 
> end-user sees, so
> > as a service 
> > characteristic, it must be provided between the two end 
> systems / hosts.
> > In order to do 
> > this, however, some level of support is required at each 
> hop along the
> > path. 
> > For me the term end-to-end (for example end-to-end call 
> flow) includes
> > the components within the network that must come together to make it
> > work. The term end-to-end application level signaling seems like an
> > oxymoron since this signaling occurs with no involvement of 
> the network
> > except to transfer the data packets but perhaps there is 
> something I am
> > missing. 
> > 
> >  So, establishing QoS between the end systems requires a 
> peer-to-peer
> > agreement between 
> > the end systems, a host-to-cloud agreement for the transport of the
> > packets, and 
> > some mechanism within the cloud to ensure that the agreed 
> upon QoS is
> > provided. 
> > Depending upon the complexity of the cloud, the latter 
> could imply all
> > sorts of QoS 
> > agreements between networks and even nodes, for packet forwarding. 
> > 
> >   Note that I have purposely NOT stated that any of these 
> agreements are
> > negotiated or 
> > require a signalling protocol. My opinion is that it is 
> better in the
> > long term to 
> > support negotiated services using signalling, as it provides more
> > flexibility. However, 
> > this can be overdone, say, as a silly example, by having 
> the end-system
> > negotiate with 
> > every node in the network. So, the compromise is that some 
> of the QoS
> > agreements will 
> > be incorporated into the network design (e.g. Diff Serv), 
> some will be
> > configured by 
> > the operator(s) (e.g. through traffic engineering and policy
> > management), and others 
> > will be signalled. NSIS seems to be about determining where 
> signalling
> > is appropriate, 
> > and what are the signalling peers, and what is the best protocol
> > solution or solutions. 
> > The catch is that the first two approaches actually encompass a wide
> > variety of technologies 
> > and scenarios. 
> > [Schneider, Marco]  I think you have articulated this very 
> well and I am
> > in general agreement. 
> > 
> >   Sorry for stating the obvious. There is clearly some 
> concern over the
> > use, for example, 
> > of RSVP, and I suspect that some people are concerned that 
> "end-to-end
> > signalling" also 
> > means "hop-by-hop" ala RSVP. It could, but it does not have to. 
> > [Schneider, Marco] I think this is a very important 
> distinction. I think
> > that the reverse is true as well in that some people are 
> assuming a hop
> > by hop linear signaling model wherein the signaling takes 
> place in order
> > along the path that the data will follow. The transport 
> signaling that
> > is going to occur within the core of our network will be at 
> a different
> > timescale than UNI signaling and there are a variety of 
> solutions for
> > this including RSVP-te and CR-LDP which were developed for 
> the purpose
> > of allocating traffic trunks.
> > 
> >   So, my view is that NSIS needs to ensure that the 
> end-to-end QoS is
> > provided for, and 
> > develope the protocols where they are needed (but not where they are
> > not). At this point, 
> > that would seem to be host to edge, edge to edge, and at 
> the very least,
> > with enough 
> > end to end semantics to ensure that the complete path 
> supports QoS. I am
> > concerned about 
> > node to node signalling, as there are so many different 
> approaches to
> > supporting node-to-node 
> > QoS. At the very least, I would like to see a framework, 
> and the edge
> > solutions defined 
> > before we delve into "intra-network" issues. 
> > [Schneider, Marco] I think it all begins with the fact that 
> a user must
> > be able to request a QOS/COS connection/flow to another user. If we
> > can't do that then everything else would appear to be pointless. The
> > next question is whether we want to develop protocols that 
> assist the
> > network portion in delivering this capability and in what 
> context(s).
> > 
> > 
> > BTW: in writing this, it dawned upon me that it might be 
> best to write a
> > series of 
> > requirements rather then just one - i.e. tackle the problem piece by
> > piece. This approach 
> > does have drawbacks, but working groups seem to work better 
> when they
> > focus on contained 
> > problem domains. A strawman framework might be useful in keeping the
> > incremental solutions 
> > coherent. 
> > [Schneider, Marco] I agree with the idea of tackling the 
> requirements by
> > breaking the problem up. There is a catch 22 in that in 
> order to breakup
> > it up we must to some degree presuppose a solution. 
> > 
> > 
> > > [MS] I think our basic requirement is that an end-system 
> be able to
> > request (and 
> > > receive) a QOS connection to some other end-system (NSIS UNI). The
> > request part entails 
> > > an NSIS UNI. As you say the realization of this request can be
> > achieved in a number of 
> > > different ways. Now one solution is to invent an NSIS NNI 
> that runs
> > between domains. If 
> > > we develop requirements for such an NSIS UNI then we have already
> > preproposed a 
> > > solution ahead of requirements. 
> > 
> > [gwk] We have to be extremely careful not to become 
> pre-occupied with
> > requirements 
> > definition. All productive requirements definition efforts 
> begin with
> > assumptions 
> > concerning the solution. In my view, requirements 
> specifications are a
> > balance between 
> > presumption and prediction, particularly when dealing with "soft"
> > techologies such as 
> > protocols. The issue really is not whether a requirement is 
> a "MAY" or a
> > "SHOULD" or 
> > whatever, the issue is whether a requirement actually helps 
> us define
> > the solution 
> > (there are lot's of examples of "SHOULD" requirements that 
> do not bring
> > value to the 
> > design process). 
> > [Schneider, Marco] I think there is a danger in implicit assumptions
> > that may not lead to the best solution. With respect to 
> network support
> > of a QOS request, there are many different solutions and I am afraid
> > that some participants have presupposed a hop by hop 
> signaling solution.
> > 
> > 
> > Given my observation above about writing a series of requirements, I
> > would recommend 
> > that we roughly map out the solution(some would call this a
> > "framework"). This map would 
> > form the preliminary list of deliverables for the wg 
> charter, and then
> > pick a focussed 
> > problem area to begin with requirements. This is not "top 
> down" design,
> > but "top down" 
> > processes seldom work. If this seems too abstract, what I 
> am saying is
> > that I have no 
> > problem identifying that there are N problem areas to be addressed -
> > e.g. host to edge, 
> > edge to edge, node to node, etc. - and picking anyone for the first
> > design attempt. Of 
> > course, the challenge would be to keep an eye on the "big 
> picture" or
> > end-to-end 
> > requirements in the process. 
> > [Schneider, Marco] I think that the network context for 
> supporting NSIS
> > UNI is a quagmire, albeit a very fun one. The problems we need to
> > address depend upon what end-to-end architectures we wish 
> to support.
> > There are a number of capabilities already being developed 
> for network
> > QOS and there may be a number of ways to "glue" these together.
> > 
> > Deludedly yours,
> > 
> > Marco
> > 
> > Just my deluded point of view. 
> > Cheers, 
> > Gary 
> > 
> > [Schneider, Marco]  
> > *snip* 
> > 
> 
> 
> 

------_=_NextPart_001_01C1A427.CE5596C0
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] Two kinds of requirements</TITLE>
</HEAD>
<BODY>

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

<P><FONT SIZE=3D2>&nbsp; Understood. A similar argument to that put =
forth for handover.</FONT>
<BR><FONT SIZE=3D2>We shall have to see how the solutions map out. My =
bias, when it</FONT>
<BR><FONT SIZE=3D2>comes to signalling, is that less is always better, =
even for wireless.</FONT>
</P>

<P><FONT SIZE=3D2>Gary</FONT>
</P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Brian Williams [<A =
HREF=3D"mailto:brian.williams@ericsson.com.au">mailto:brian.williams@eri=
csson.com.au</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: January 23, 2002 05:41</FONT>
<BR><FONT SIZE=3D2>&gt; To: Kenward, Gary [WDLN2:AN10:EXCH]</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: 'Schneider, Marco'; 'Roy, Radhika R, =
ALASO'; Loughney &quot;John</FONT>
<BR><FONT SIZE=3D2>&gt; (NRC/Helsinki); brunner@ccrle.nec.de; Yaron =
Kahana; Geib, Ruediger;</FONT>
<BR><FONT SIZE=3D2>&gt; dick.rr.knight@bt.com; nsis@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: RE: [NSIS] Two kinds of =
requirements</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; On Wed, 2002-01-23 at 08:33, Gary Kenward =
wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Marco:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; Good question: what do I =
mean by layering. I assume you </FONT>
<BR><FONT SIZE=3D2>&gt; are familiar</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; with protocol layers and their</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; properties. My major concern would be in =
the replication of </FONT>
<BR><FONT SIZE=3D2>&gt; information</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; exchanges at each layer, resulting</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; in greater overhead/delay. The end systems =
must to be involved in</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; establishing the necessary QoS, =
including</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; negotiation if viable, but the number of =
bits that are transported</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; through the network to set up this =
QoS</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; end to end must be kept to a minimum. =
Thus, I cringe at the </FONT>
<BR><FONT SIZE=3D2>&gt; possibility</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; of an end-to-end application =
exchange</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; triggering an RSVP request, triggering . . =
. in telephony terms, the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; analogy is the call setup delay, which =
has</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; to be acceptable to the user, and, for =
wireless, has to be bandwidth</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; efficient.</FONT>
<BR><FONT SIZE=3D2>&gt; For cellular wireless networks, reducing the =
number of </FONT>
<BR><FONT SIZE=3D2>&gt; signalling layers</FONT>
<BR><FONT SIZE=3D2>&gt; can reduce the amount of signalling, and =
possibly the setup delays.</FONT>
<BR><FONT SIZE=3D2>&gt; However, wireless spectrum is critical in =
cellular wireless networks,</FONT>
<BR><FONT SIZE=3D2>&gt; and optimising spectrum for a long session =
could have benefits over a</FONT>
<BR><FONT SIZE=3D2>&gt; bit less signalling. Thus, it is better to have =
an additional </FONT>
<BR><FONT SIZE=3D2>&gt; signalling</FONT>
<BR><FONT SIZE=3D2>&gt; layer to allow better use of the =
spectrum.&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; /brian</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp; I hope I have explained my =
concern.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Cheers,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Gary</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; From: Schneider, Marco [<A =
HREF=3D"mailto:schneider@tri.sbc.com">mailto:schneider@tri.sbc.com</A>]<=
/FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Sent: January 22, 2002 15:35</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Roy, =
Radhika R, </FONT>
<BR><FONT SIZE=3D2>&gt; ALASO'; Loughney</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; John (NRC/Helsinki); brunner@ccrle.nec.de; =
Yaron Kahana; </FONT>
<BR><FONT SIZE=3D2>&gt; Geib, Ruediger;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; dick.rr.knight@bt.com</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Cc: nsis@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Subject: RE: [NSIS] Two kinds of =
requirements</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Gary,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; From: Gary Kenward [<A =
HREF=3D"mailto:gkenward@nortelnetworks.com">mailto:gkenward@nortelnetwor=
ks.com</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Sent: Tuesday, January 22, 2002 9:02 =
AM</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; To: Schneider, Marco; 'Roy, Radhika R, =
ALASO'; Loughney John</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; (NRC/Helsinki); brunner@ccrle.nec.de; =
Yaron Kahana; Geib, Ruediger;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; dick.rr.knight@bt.com</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Cc: nsis@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Subject: RE: [NSIS] Two kinds of =
requirements</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Marco: </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; -----Original Message----- </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; [MS]&nbsp; Yes, exactly. </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&nbsp;&nbsp; I don't believe you are =
proposing a &quot;layering&quot; of signalling</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; protocols, </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; one for session establishment, then =
one for transport, etc. </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; [MS]&nbsp; This is exactly what has =
been proposed in RAP and </FONT>
<BR><FONT SIZE=3D2>&gt; SIP working</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; groups to the best </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; of my understanding. Because there =
does not exist a proxy </FONT>
<BR><FONT SIZE=3D2>&gt; signaling</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; capability that </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; allows a session to setup a =
connection on the users behalf, the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; session forwards a </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; token to the end-system and then the =
end-system includes </FONT>
<BR><FONT SIZE=3D2>&gt; that token in</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; the RSVP path </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; message so that the reservation will =
go through. In this </FONT>
<BR><FONT SIZE=3D2>&gt; manner the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; session layer does </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; not need to communicate directly with =
the transport layer. </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; [gwk] I do not understand what &quot;the =
session&quot; represents in </FONT>
<BR><FONT SIZE=3D2>&gt; the above. It</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; would seem </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; to me that you must have a session level =
entity, and that </FONT>
<BR><FONT SIZE=3D2>&gt; to &quot;forward a</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; token to the </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; end-system&quot;, it must have an =
interface/api to the </FONT>
<BR><FONT SIZE=3D2>&gt; &quot;end-system&quot;. If this</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &quot;end-system&quot; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; is including tokens in RSVP, then it is =
the entity setting up the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; transport QoS (although </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; it is not necessarly a transport layer =
entity, but rather a </FONT>
<BR><FONT SIZE=3D2>&gt; signalling</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; entity. If these </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; two entites are co-located, then you do =
not have layered signalling</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; protocols. </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Have I missed something? </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; [Schneider, Marco] I don't think you have =
missed anything. I may not</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; have understood what you meant by a =
layering of signaling protocols.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Please define this.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; BTW: for many links, particularly =
wireless, layered </FONT>
<BR><FONT SIZE=3D2>&gt; signalling is not a</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; good idea. </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; And, in general, layered signalling will =
always be slower </FONT>
<BR><FONT SIZE=3D2>&gt; then a single</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; signalling protocol. </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; So, the question, </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; becomes, how are the QoS transport =
mechanisms established? In the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; internet </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; model there is only one end-to-end =
transport session </FONT>
<BR><FONT SIZE=3D2>&gt; (e.g. TCP, RTP,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; UDP), </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; but underneath the transport is a =
series of </FONT>
<BR><FONT SIZE=3D2>&gt; inter-connected networks,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; each </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; with potentially different =
characteristics. </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&nbsp;&nbsp; This is end-to-end QoS =
support structure has to be set up and</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; maintained </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; in order for the end to end session =
QoS to be realized. </FONT>
<BR><FONT SIZE=3D2>&gt; The solution</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; may be </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; a single protocol that travels from =
host to host, such as </FONT>
<BR><FONT SIZE=3D2>&gt; RSVP, or it</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; may </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; be a collection of protocols that are =
optimized for each </FONT>
<BR><FONT SIZE=3D2>&gt; portion of</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; the </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; end-to-end path: e.g. host to access =
network, access to </FONT>
<BR><FONT SIZE=3D2>&gt; core network, </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; core to core network, etc. </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&nbsp;&nbsp; It is too early to =
determine which approach is best, </FONT>
<BR><FONT SIZE=3D2>&gt; but in either</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; case, </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; do we not need to understand the =
end-to-end requirements for this</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; signalling </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; capability? </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; [MS]&nbsp; So by end-to-end you are =
referring to both the </FONT>
<BR><FONT SIZE=3D2>&gt; end-systems and</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; the devices in </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; between. As a point of clarification, =
I asked Roy what he meant by</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &quot;End-to-End </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Application Layer QOS Signaling&quot; =
and his answer implied user</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; (end-system) to user (end- </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; system).&nbsp; We have been using the =
term end-to-end in different ways</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; (contexts). The way </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; I normally use the term =
&quot;end-to-end&quot; is to include everything in</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; between (all the </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; hops). </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; [gwk] I see the difference. I would say =
that I tend towards your</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; definition, in the </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; following sense: the only QoS that matters =
is what the </FONT>
<BR><FONT SIZE=3D2>&gt; end-user sees, so</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; as a service </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; characteristic, it must be provided =
between the two end </FONT>
<BR><FONT SIZE=3D2>&gt; systems / hosts.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; In order to do </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; this, however, some level of support is =
required at each </FONT>
<BR><FONT SIZE=3D2>&gt; hop along the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; path. </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; For me the term end-to-end (for example =
end-to-end call </FONT>
<BR><FONT SIZE=3D2>&gt; flow) includes</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; the components within the network that =
must come together to make it</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; work. The term end-to-end application =
level signaling seems like an</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; oxymoron since this signaling occurs with =
no involvement of </FONT>
<BR><FONT SIZE=3D2>&gt; the network</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; except to transfer the data packets but =
perhaps there is </FONT>
<BR><FONT SIZE=3D2>&gt; something I am</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; missing. </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; So, establishing QoS between the end =
systems requires a </FONT>
<BR><FONT SIZE=3D2>&gt; peer-to-peer</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; agreement between </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; the end systems, a host-to-cloud agreement =
for the transport of the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; packets, and </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; some mechanism within the cloud to ensure =
that the agreed </FONT>
<BR><FONT SIZE=3D2>&gt; upon QoS is</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; provided. </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Depending upon the complexity of the =
cloud, the latter </FONT>
<BR><FONT SIZE=3D2>&gt; could imply all</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; sorts of QoS </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; agreements between networks and even =
nodes, for packet forwarding. </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp; Note that I have purposely NOT =
stated that any of these </FONT>
<BR><FONT SIZE=3D2>&gt; agreements are</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; negotiated or </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; require a signalling protocol. My opinion =
is that it is </FONT>
<BR><FONT SIZE=3D2>&gt; better in the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; long term to </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; support negotiated services using =
signalling, as it provides more</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; flexibility. However, </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; this can be overdone, say, as a silly =
example, by having </FONT>
<BR><FONT SIZE=3D2>&gt; the end-system</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; negotiate with </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; every node in the network. So, the =
compromise is that some </FONT>
<BR><FONT SIZE=3D2>&gt; of the QoS</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; agreements will </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; be incorporated into the network design =
(e.g. Diff Serv), </FONT>
<BR><FONT SIZE=3D2>&gt; some will be</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; configured by </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; the operator(s) (e.g. through traffic =
engineering and policy</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; management), and others </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; will be signalled. NSIS seems to be about =
determining where </FONT>
<BR><FONT SIZE=3D2>&gt; signalling</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; is appropriate, </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; and what are the signalling peers, and =
what is the best protocol</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; solution or solutions. </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; The catch is that the first two approaches =
actually encompass a wide</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; variety of technologies </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; and scenarios. </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; [Schneider, Marco]&nbsp; I think you have =
articulated this very </FONT>
<BR><FONT SIZE=3D2>&gt; well and I am</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; in general agreement. </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp; Sorry for stating the obvious. =
There is clearly some </FONT>
<BR><FONT SIZE=3D2>&gt; concern over the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; use, for example, </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; of RSVP, and I suspect that some people =
are concerned that </FONT>
<BR><FONT SIZE=3D2>&gt; &quot;end-to-end</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; signalling&quot; also </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; means &quot;hop-by-hop&quot; ala RSVP. It =
could, but it does not have to. </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; [Schneider, Marco] I think this is a very =
important </FONT>
<BR><FONT SIZE=3D2>&gt; distinction. I think</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; that the reverse is true as well in that =
some people are </FONT>
<BR><FONT SIZE=3D2>&gt; assuming a hop</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; by hop linear signaling model wherein the =
signaling takes </FONT>
<BR><FONT SIZE=3D2>&gt; place in order</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; along the path that the data will follow. =
The transport </FONT>
<BR><FONT SIZE=3D2>&gt; signaling that</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; is going to occur within the core of our =
network will be at </FONT>
<BR><FONT SIZE=3D2>&gt; a different</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; timescale than UNI signaling and there are =
a variety of </FONT>
<BR><FONT SIZE=3D2>&gt; solutions for</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; this including RSVP-te and CR-LDP which =
were developed for </FONT>
<BR><FONT SIZE=3D2>&gt; the purpose</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; of allocating traffic trunks.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp; So, my view is that NSIS needs =
to ensure that the </FONT>
<BR><FONT SIZE=3D2>&gt; end-to-end QoS is</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; provided for, and </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; develope the protocols where they are =
needed (but not where they are</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; not). At this point, </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; that would seem to be host to edge, edge =
to edge, and at </FONT>
<BR><FONT SIZE=3D2>&gt; the very least,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; with enough </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; end to end semantics to ensure that the =
complete path </FONT>
<BR><FONT SIZE=3D2>&gt; supports QoS. I am</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; concerned about </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; node to node signalling, as there are so =
many different </FONT>
<BR><FONT SIZE=3D2>&gt; approaches to</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; supporting node-to-node </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; QoS. At the very least, I would like to =
see a framework, </FONT>
<BR><FONT SIZE=3D2>&gt; and the edge</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; solutions defined </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; before we delve into =
&quot;intra-network&quot; issues. </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; [Schneider, Marco] I think it all begins =
with the fact that </FONT>
<BR><FONT SIZE=3D2>&gt; a user must</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; be able to request a QOS/COS =
connection/flow to another user. If we</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; can't do that then everything else would =
appear to be pointless. The</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; next question is whether we want to =
develop protocols that </FONT>
<BR><FONT SIZE=3D2>&gt; assist the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; network portion in delivering this =
capability and in what </FONT>
<BR><FONT SIZE=3D2>&gt; context(s).</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; BTW: in writing this, it dawned upon me =
that it might be </FONT>
<BR><FONT SIZE=3D2>&gt; best to write a</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; series of </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; requirements rather then just one - i.e. =
tackle the problem piece by</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; piece. This approach </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; does have drawbacks, but working groups =
seem to work better </FONT>
<BR><FONT SIZE=3D2>&gt; when they</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; focus on contained </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; problem domains. A strawman framework =
might be useful in keeping the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; incremental solutions </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; coherent. </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; [Schneider, Marco] I agree with the idea =
of tackling the </FONT>
<BR><FONT SIZE=3D2>&gt; requirements by</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; breaking the problem up. There is a catch =
22 in that in </FONT>
<BR><FONT SIZE=3D2>&gt; order to breakup</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; it up we must to some degree presuppose a =
solution. </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; [MS] I think our basic requirement is =
that an end-system </FONT>
<BR><FONT SIZE=3D2>&gt; be able to</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; request (and </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; receive) a QOS connection to some =
other end-system (NSIS UNI). The</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; request part entails </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; an NSIS UNI. As you say the =
realization of this request can be</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; achieved in a number of </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; different ways. Now one solution is =
to invent an NSIS NNI </FONT>
<BR><FONT SIZE=3D2>&gt; that runs</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; between domains. If </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; we develop requirements for such an =
NSIS UNI then we have already</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; preproposed a </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; solution ahead of requirements. =
</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; [gwk] We have to be extremely careful not =
to become </FONT>
<BR><FONT SIZE=3D2>&gt; pre-occupied with</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; requirements </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; definition. All productive requirements =
definition efforts </FONT>
<BR><FONT SIZE=3D2>&gt; begin with</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; assumptions </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; concerning the solution. In my view, =
requirements </FONT>
<BR><FONT SIZE=3D2>&gt; specifications are a</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; balance between </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; presumption and prediction, particularly =
when dealing with &quot;soft&quot;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; techologies such as </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; protocols. The issue really is not whether =
a requirement is </FONT>
<BR><FONT SIZE=3D2>&gt; a &quot;MAY&quot; or a</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &quot;SHOULD&quot; or </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; whatever, the issue is whether a =
requirement actually helps </FONT>
<BR><FONT SIZE=3D2>&gt; us define</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; the solution </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; (there are lot's of examples of =
&quot;SHOULD&quot; requirements that </FONT>
<BR><FONT SIZE=3D2>&gt; do not bring</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; value to the </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; design process). </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; [Schneider, Marco] I think there is a =
danger in implicit assumptions</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; that may not lead to the best solution. =
With respect to </FONT>
<BR><FONT SIZE=3D2>&gt; network support</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; of a QOS request, there are many different =
solutions and I am afraid</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; that some participants have presupposed a =
hop by hop </FONT>
<BR><FONT SIZE=3D2>&gt; signaling solution.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Given my observation above about writing a =
series of requirements, I</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; would recommend </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; that we roughly map out the solution(some =
would call this a</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &quot;framework&quot;). This map would =
</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; form the preliminary list of deliverables =
for the wg </FONT>
<BR><FONT SIZE=3D2>&gt; charter, and then</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; pick a focussed </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; problem area to begin with requirements. =
This is not &quot;top </FONT>
<BR><FONT SIZE=3D2>&gt; down&quot; design,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; but &quot;top down&quot; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; processes seldom work. If this seems too =
abstract, what I </FONT>
<BR><FONT SIZE=3D2>&gt; am saying is</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; that I have no </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; problem identifying that there are N =
problem areas to be addressed -</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; e.g. host to edge, </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; edge to edge, node to node, etc. - and =
picking anyone for the first</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; design attempt. Of </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; course, the challenge would be to keep an =
eye on the &quot;big </FONT>
<BR><FONT SIZE=3D2>&gt; picture&quot; or</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; end-to-end </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; requirements in the process. </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; [Schneider, Marco] I think that the =
network context for </FONT>
<BR><FONT SIZE=3D2>&gt; supporting NSIS</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; UNI is a quagmire, albeit a very fun one. =
The problems we need to</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; address depend upon what end-to-end =
architectures we wish </FONT>
<BR><FONT SIZE=3D2>&gt; to support.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; There are a number of capabilities already =
being developed </FONT>
<BR><FONT SIZE=3D2>&gt; for network</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; QOS and there may be a number of ways to =
&quot;glue&quot; these together.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Deludedly yours,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Marco</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Just my deluded point of view. </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Cheers, </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Gary </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; [Schneider, Marco]&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; *snip* </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1A427.CE5596C0--


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



From daemon@optimus.ietf.org  Wed Jan 23 13:06: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 NAA18807
	for <nsis-archive@odin.ietf.org>; Wed, 23 Jan 2002 13:06:02 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id NAA08842
	for nsis-archive@odin.ietf.org; Wed, 23 Jan 2002 13:06: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 MAA07894;
	Wed, 23 Jan 2002 12:52: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 MAA07863
	for <nsis@optimus.ietf.org>; Wed, 23 Jan 2002 12:52:51 -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 MAA18291
	for <nsis@ietf.org>; Wed, 23 Jan 2002 12:52:50 -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.34)
	  id 16TRZL-0002ZQ-00; Wed, 23 Jan 2002 18:52:19 +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 g0NHqJa14189;
	Wed, 23 Jan 2002 18:52:19 +0100
Message-ID: <3C4EF853.B10F8796@ee.tu-berlin.de>
Date: Wed, 23 Jan 2002 18:52:19 +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: David.Partain@ericsson.com, NSIS <nsis@ietf.org>
Subject: Re: [NSIS] Framework & requirements part of the "Two kinds of 
 requirements" thread
References: <0GQD001M6YBEYP@mbb1.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

Hi David,

A great work to summarize these up-to-date discussions!

> The big issue there is what part of this we should solve here.
> Should we concentrate specifically on the application/host
> to network signalling?  I think not and others have agreed.
> Should we try to design something that goes end to end?  If we
> do that, do we have a "chicken and egg" problem of needing to
> have the technology everywhere for things to work?

IMO end to end is more desired in NSIS. To attain this we may 
allow signaling from host to edge, from edge to edge, from 
hop to hop, etc. As for the "chicken and egg" problem, I believe
some kind of "migration" may also be developed later, e.g., 
"NSIS tunnel" for non-NSIS clouds depending on the needs.

Regards,

Xiaoming

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



From daemon@optimus.ietf.org  Wed Jan 23 13:17: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 NAA19161
	for <nsis-archive@odin.ietf.org>; Wed, 23 Jan 2002 13:17:54 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id NAA09582
	for nsis-archive@odin.ietf.org; Wed, 23 Jan 2002 13:17: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 NAA08877;
	Wed, 23 Jan 2002 13:06: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 NAA08854
	for <nsis@optimus.ietf.org>; Wed, 23 Jan 2002 13:06:18 -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 NAA18823
	for <nsis@ietf.org>; Wed, 23 Jan 2002 13:06:16 -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 g0NI68T14551;
	Wed, 23 Jan 2002 12:06:18 -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 g0NI3R814267;
	Wed, 23 Jan 2002 12:03:27 -0600 (CST)
Received: by TRIMAIL2.ad.tri.sbc.com with Internet Mail Service (5.5.2653.19)
	id <ZND329MD>; Wed, 23 Jan 2002 12:03:54 -0600
Message-ID: <905A1C4ABF353F4C8CC16FA9F53DD0D638B9AD@TRIMAIL2.ad.tri.sbc.com>
From: "Schneider, Marco" <schneider@tri.sbc.com>
To: "'Brian Williams'" <brian.williams@ericsson.com.au>
Cc: "'Gary Kenward'" <gkenward@nortelnetworks.com>,
        "'Roy, Radhika R, ALASO'" <rrroy@att.com>,
        "Loughney  \"John (NRC/Helsinki)" <john.loughney@nokia.com>,
        brunner@ccrle.nec.de, Yaron Kahana <ykahana@comgates.co.il>,
        "Geib, Ruediger" <Ruediger.Geib@t-systems.com>, dick.rr.knight@bt.com,
        nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements
Date: Wed, 23 Jan 2002 12:03:53 -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

Brian,

Thanks for your discussion. So if I understand your comments correctly, you
are concerned with NSIS QOS mapping to layer 2 QOS. Is there any way in
which these requirements would impact the actual signaling protocol?

Marco

-----Original Message-----
From: Brian Williams [mailto:brian.williams@ericsson.com.au]
Sent: Wednesday, January 23, 2002 4:32 AM
To: Schneider, Marco
Cc: 'Gary Kenward'; 'Roy, Radhika R, ALASO'; Loughney "John
(NRC/Helsinki); brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
dick.rr.knight@bt.com; nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


Hi Marco.
On Wed, 2002-01-23 at 09:48, Schneider, Marco wrote:
> Garry,
>  
> >From an architectural/software perspective there is a session layer that
> is logically built on top of the transport capability. From a protocol
> stack perspective the session signaling is not layered on top of the
> transport signaling in the framework I described. 
>  
> Aside: The following scenario is conceivable but not desireable.
> Consider an ADSL customer that is logically connected to an edge router
> via a DSLAM and an edge switch. Thus the layer 3 hop is realized by
> multiple hops at layer 2. 
A similar but slightly different situation exists also with cellular
wireless networks. The layer 3 hop runs over one layer 2 hop, but this
layer 2 hop is actually overlayed on top of multiple underlying layer 2
hops. 

> Existing deployments that I am aware of use a
> preprovisioned PVC for this. Now imagine that the customer does session
> signaling resulting in NSIS signaling at layer 3. This could result in
> the need for a new layer 2 connection because the existing PVC will not
> do the job. 
Certanly the case for cellular that a new lasyer 2 connection coule be
required.

> Thus ATM UNI signaling might be initiated from the ADSL
> Customer to allocate the resources for the layer 3 logical link. Yuck!
> Obviously it is better to avoid this by pre-provisioning the access
> network appropriately. Nevertheless, there may be other circumstances
> where this type of situation will occur and one could imagine promoting
> the layer 2 devices to be aware of NSIS so as to avoid multiple levels
> of signaling. 
For the cellular case, the end host is the device that sets up the layer
2 connection. This connection must use separate signalling to allow
separate development of the layer 2 capabilities (ie dependent on
cellular technology). The host though must be able to relate the QoS
requirements signalled by NSIS to the layer 2 signalling. We are in the
process of producing a draft to clarify these requirements based on
typical layer 2 characteristics of cellular networks.
/brian
  
> Marco
>  
> -----Original Message-----
> From: Gary Kenward [mailto:gkenward@nortelnetworks.com]
> Sent: Tuesday, January 22, 2002 3:34 PM
> To: Schneider, Marco; 'Roy, Radhika R, ALASO'; Loughney John
> (NRC/Helsinki); brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
> dick.rr.knight@bt.com
> Cc: nsis@ietf.org
> Subject: RE: [NSIS] Two kinds of requirements
> 
> 
> 
> Marco:
>  
>    Good question: what do I mean by layering. I assume you are familiar
> with protocol layers and their
> properties. My major concern would be in the replication of information
> exchanges at each layer, resulting
> in greater overhead/delay. The end systems must to be involved in
> establishing the necessary QoS, including
> negotiation if viable, but the number of bits that are transported
> through the network to set up this QoS
> end to end must be kept to a minimum. Thus, I cringe at the possibility
> of an end-to-end application exchange
> triggering an RSVP request, triggering . . . in telephony terms, the
> analogy is the call setup delay, which has
> to be acceptable to the user, and, for wireless, has to be bandwidth
> efficient.
>  
>   I hope I have explained my concern.
>  
> Cheers,
> Gary
>  
>  
> 
> -----Original Message-----
> From: Schneider, Marco [mailto:schneider@tri.sbc.com]
> Sent: January 22, 2002 15:35
> To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Roy, Radhika R, ALASO'; Loughney
> John (NRC/Helsinki); brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
> dick.rr.knight@bt.com
> Cc: nsis@ietf.org
> Subject: RE: [NSIS] Two kinds of requirements
> 
> 
> Gary,
> 
> -----Original Message-----
> From: Gary Kenward [mailto:gkenward@nortelnetworks.com]
> Sent: Tuesday, January 22, 2002 9:02 AM
> To: Schneider, Marco; 'Roy, Radhika R, ALASO'; Loughney John
> (NRC/Helsinki); brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
> dick.rr.knight@bt.com
> Cc: nsis@ietf.org
> Subject: RE: [NSIS] Two kinds of requirements
> 
> 
> 
> Marco: 
> 
> -----Original Message----- 
> > [MS]  Yes, exactly. 
> >   I don't believe you are proposing a "layering" of signalling
> protocols, 
> > one for session establishment, then one for transport, etc. 
> > [MS]  This is exactly what has been proposed in RAP and SIP working
> groups to the best 
> > of my understanding. Because there does not exist a proxy signaling
> capability that 
> > allows a session to setup a connection on the users behalf, the
> session forwards a 
> > token to the end-system and then the end-system includes that token in
> the RSVP path 
> > message so that the reservation will go through. In this manner the
> session layer does 
> > not need to communicate directly with the transport layer. 
> 
> [gwk] I do not understand what "the session" represents in the above. It
> would seem 
> to me that you must have a session level entity, and that to "forward a
> token to the 
> end-system", it must have an interface/api to the "end-system". If this
> "end-system" 
> is including tokens in RSVP, then it is the entity setting up the
> transport QoS (although 
> it is not necessarly a transport layer entity, but rather a signalling
> entity. If these 
> two entites are co-located, then you do not have layered signalling
> protocols. 
> 
> Have I missed something? 
> 
> [Schneider, Marco] I don't think you have missed anything. I may not
> have understood what you meant by a layering of signaling protocols.
> Please define this.
> 
> BTW: for many links, particularly wireless, layered signalling is not a
> good idea. 
> And, in general, layered signalling will always be slower then a single
> signalling protocol. 
> > So, the question, 
> > becomes, how are the QoS transport mechanisms established? In the
> internet 
> > model there is only one end-to-end transport session (e.g. TCP, RTP,
> UDP), 
> > but underneath the transport is a series of inter-connected networks,
> each 
> > with potentially different characteristics. 
> >   This is end-to-end QoS support structure has to be set up and
> maintained 
> > in order for the end to end session QoS to be realized. The solution
> may be 
> > a single protocol that travels from host to host, such as RSVP, or it
> may 
> > be a collection of protocols that are optimized for each portion of
> the 
> > end-to-end path: e.g. host to access network, access to core network, 
> > core to core network, etc. 
> >   It is too early to determine which approach is best, but in either
> case, 
> > do we not need to understand the end-to-end requirements for this
> signalling 
> > capability? 
> > [MS]  So by end-to-end you are referring to both the end-systems and
> the devices in 
> > between. As a point of clarification, I asked Roy what he meant by
> "End-to-End 
> > Application Layer QOS Signaling" and his answer implied user
> (end-system) to user (end- 
> > system).  We have been using the term end-to-end in different ways
> (contexts). The way 
> > I normally use the term "end-to-end" is to include everything in
> between (all the 
> > hops). 
> 
> [gwk] I see the difference. I would say that I tend towards your
> definition, in the 
> following sense: the only QoS that matters is what the end-user sees, so
> as a service 
> characteristic, it must be provided between the two end systems / hosts.
> In order to do 
> this, however, some level of support is required at each hop along the
> path. 
> For me the term end-to-end (for example end-to-end call flow) includes
> the components within the network that must come together to make it
> work. The term end-to-end application level signaling seems like an
> oxymoron since this signaling occurs with no involvement of the network
> except to transfer the data packets but perhaps there is something I am
> missing. 
> 
>  So, establishing QoS between the end systems requires a peer-to-peer
> agreement between 
> the end systems, a host-to-cloud agreement for the transport of the
> packets, and 
> some mechanism within the cloud to ensure that the agreed upon QoS is
> provided. 
> Depending upon the complexity of the cloud, the latter could imply all
> sorts of QoS 
> agreements between networks and even nodes, for packet forwarding. 
> 
>   Note that I have purposely NOT stated that any of these agreements are
> negotiated or 
> require a signalling protocol. My opinion is that it is better in the
> long term to 
> support negotiated services using signalling, as it provides more
> flexibility. However, 
> this can be overdone, say, as a silly example, by having the end-system
> negotiate with 
> every node in the network. So, the compromise is that some of the QoS
> agreements will 
> be incorporated into the network design (e.g. Diff Serv), some will be
> configured by 
> the operator(s) (e.g. through traffic engineering and policy
> management), and others 
> will be signalled. NSIS seems to be about determining where signalling
> is appropriate, 
> and what are the signalling peers, and what is the best protocol
> solution or solutions. 
> The catch is that the first two approaches actually encompass a wide
> variety of technologies 
> and scenarios. 
> [Schneider, Marco]  I think you have articulated this very well and I am
> in general agreement. 
> 
>   Sorry for stating the obvious. There is clearly some concern over the
> use, for example, 
> of RSVP, and I suspect that some people are concerned that "end-to-end
> signalling" also 
> means "hop-by-hop" ala RSVP. It could, but it does not have to. 
> [Schneider, Marco] I think this is a very important distinction. I think
> that the reverse is true as well in that some people are assuming a hop
> by hop linear signaling model wherein the signaling takes place in order
> along the path that the data will follow. The transport signaling that
> is going to occur within the core of our network will be at a different
> timescale than UNI signaling and there are a variety of solutions for
> this including RSVP-te and CR-LDP which were developed for the purpose
> of allocating traffic trunks.
> 
>   So, my view is that NSIS needs to ensure that the end-to-end QoS is
> provided for, and 
> develope the protocols where they are needed (but not where they are
> not). At this point, 
> that would seem to be host to edge, edge to edge, and at the very least,
> with enough 
> end to end semantics to ensure that the complete path supports QoS. I am
> concerned about 
> node to node signalling, as there are so many different approaches to
> supporting node-to-node 
> QoS. At the very least, I would like to see a framework, and the edge
> solutions defined 
> before we delve into "intra-network" issues. 
> [Schneider, Marco] I think it all begins with the fact that a user must
> be able to request a QOS/COS connection/flow to another user. If we
> can't do that then everything else would appear to be pointless. The
> next question is whether we want to develop protocols that assist the
> network portion in delivering this capability and in what context(s).
> 
> 
> BTW: in writing this, it dawned upon me that it might be best to write a
> series of 
> requirements rather then just one - i.e. tackle the problem piece by
> piece. This approach 
> does have drawbacks, but working groups seem to work better when they
> focus on contained 
> problem domains. A strawman framework might be useful in keeping the
> incremental solutions 
> coherent. 
> [Schneider, Marco] I agree with the idea of tackling the requirements by
> breaking the problem up. There is a catch 22 in that in order to breakup
> it up we must to some degree presuppose a solution. 
> 
> 
> > [MS] I think our basic requirement is that an end-system be able to
> request (and 
> > receive) a QOS connection to some other end-system (NSIS UNI). The
> request part entails 
> > an NSIS UNI. As you say the realization of this request can be
> achieved in a number of 
> > different ways. Now one solution is to invent an NSIS NNI that runs
> between domains. If 
> > we develop requirements for such an NSIS UNI then we have already
> preproposed a 
> > solution ahead of requirements. 
> 
> [gwk] We have to be extremely careful not to become pre-occupied with
> requirements 
> definition. All productive requirements definition efforts begin with
> assumptions 
> concerning the solution. In my view, requirements specifications are a
> balance between 
> presumption and prediction, particularly when dealing with "soft"
> techologies such as 
> protocols. The issue really is not whether a requirement is a "MAY" or a
> "SHOULD" or 
> whatever, the issue is whether a requirement actually helps us define
> the solution 
> (there are lot's of examples of "SHOULD" requirements that do not bring
> value to the 
> design process). 
> [Schneider, Marco] I think there is a danger in implicit assumptions
> that may not lead to the best solution. With respect to network support
> of a QOS request, there are many different solutions and I am afraid
> that some participants have presupposed a hop by hop signaling solution.
> 
> 
> Given my observation above about writing a series of requirements, I
> would recommend 
> that we roughly map out the solution(some would call this a
> "framework"). This map would 
> form the preliminary list of deliverables for the wg charter, and then
> pick a focussed 
> problem area to begin with requirements. This is not "top down" design,
> but "top down" 
> processes seldom work. If this seems too abstract, what I am saying is
> that I have no 
> problem identifying that there are N problem areas to be addressed -
> e.g. host to edge, 
> edge to edge, node to node, etc. - and picking anyone for the first
> design attempt. Of 
> course, the challenge would be to keep an eye on the "big picture" or
> end-to-end 
> requirements in the process. 
> [Schneider, Marco] I think that the network context for supporting NSIS
> UNI is a quagmire, albeit a very fun one. The problems we need to
> address depend upon what end-to-end architectures we wish to support.
> There are a number of capabilities already being developed for network
> QOS and there may be a number of ways to "glue" these together.
> 
> Deludedly yours,
> 
> Marco
> 
> Just my deluded point of view. 
> Cheers, 
> Gary 
> 
> [Schneider, Marco]  
> *snip* 
> 



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

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



From daemon@optimus.ietf.org  Wed Jan 23 13:19: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 NAA19245
	for <nsis-archive@odin.ietf.org>; Wed, 23 Jan 2002 13:19:53 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id NAA09685
	for nsis-archive@odin.ietf.org; Wed, 23 Jan 2002 13:19: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 NAA09123;
	Wed, 23 Jan 2002 13:09:58 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA09089
	for <nsis@optimus.ietf.org>; Wed, 23 Jan 2002 13:09:56 -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 NAA18879
	for <nsis@ietf.org>; Wed, 23 Jan 2002 13:09:53 -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 g0NIBxT14592;
	Wed, 23 Jan 2002 12:11:59 -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 g0NI9Jp14461;
	Wed, 23 Jan 2002 12:09:19 -0600 (CST)
Received: by TRIMAIL2.ad.tri.sbc.com with Internet Mail Service (5.5.2653.19)
	id <ZND329NA>; Wed, 23 Jan 2002 12:09:46 -0600
Message-ID: <905A1C4ABF353F4C8CC16FA9F53DD0D638B9AE@TRIMAIL2.ad.tri.sbc.com>
From: "Schneider, Marco" <schneider@tri.sbc.com>
To: "'Gabor.Fodor@era-t.ericsson.se'" <Gabor.Fodor@era-t.ericsson.se>,
        mendes@cs.columbia.edu
Cc: nsis@ietf.org
Subject: RE: [NSIS] Support needed for Throughput Adaptive QoS in wireless
Date: Wed, 23 Jan 2002 12:09:46 -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 Gabor, All

This type of functionality concerns me. The network segment you speak of
could be employing any number of mechanisms to help achieve its part of the
end-to-end QOS. If we are to consider such notification is must be done in a
manner that is independent of mechanism. 

Marco

-----Original Message-----
From: Gabor.Fodor@era-t.ericsson.se
[mailto:Gabor.Fodor@era-t.ericsson.se]
Sent: Wednesday, January 23, 2002 4:51 AM
To: mendes@cs.columbia.edu
Cc: nsis@ietf.org
Subject: Re: [NSIS] Support needed for Throughput Adaptive QoS in
wireless



Paulo,

Paulo Mendes wrote :

> Considering all the references to RSVP in this thread, the amount of 
> resources reserved in the network can be the information to supply 
> applications with. However this information is only useful if the 
> network has per-flow reservation end-to-end, which isn't always true. If 
> some kind of data aggregation in used in (part of) the network, e.g. 
> DiffServ, the information that applications require from NSIS if not the 
> amount of resources reserved to the DiffServ class/service they are 
> using, but the amount of those resources that are allocated to their 
> session.
> 

[GF]
In my view it can also be useful if the NSIS protocol allows a certain
network segment to notify the host about the available resources either
at call setup time or during the call even there is aggregation in
some part(s) of the network. 

That is, the support of re-negotiation and adaptivity can be a 
useful feature even if there is no per-flow resource reservation end-to-end.

An example of such a situation is a wireless access link that has
its own wireless reosurce manager that can notify the application 
about the wireless link status. Since the application runs over IP,
the wireless link manager needs to communicate with the IP level 
signaling entity in order to do this notification. 
[GF]

/Gabor

_______________________________________________
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 Jan 23 13:58:42 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20639
	for <nsis-archive@odin.ietf.org>; Wed, 23 Jan 2002 13:58:42 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id NAA11757
	for nsis-archive@odin.ietf.org; Wed, 23 Jan 2002 13:58: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 NAA11046;
	Wed, 23 Jan 2002 13:47: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 NAA11015
	for <nsis@optimus.ietf.org>; Wed, 23 Jan 2002 13:47:33 -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 NAA20264
	for <nsis@ietf.org>; Wed, 23 Jan 2002 13:47:30 -0500 (EST)
Received: from juniper.net (dhcp-nsw-47.juniper.net [172.17.13.209])
	by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g0NIkY679859;
	Wed, 23 Jan 2002 10:46:34 -0800 (PST)
	(envelope-from pingpan@juniper.net)
Message-ID: <3C4F0560.20508@juniper.net>
Date: Wed, 23 Jan 2002 10:48:00 -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: fu@ee.tu-berlin.de
CC: David.Partain@ericsson.com, NSIS <nsis@ietf.org>
Subject: Re: [NSIS] Framework & requirements part of the "Two kinds of  requirements" thread
References: <0GQD001M6YBEYP@mbb1.ericsson.se> <3C4EF853.B10F8796@ee.tu-berlin.de>
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

Xiaoming Fu wrote:

> Hi David,
> 
> A great work to summarize these up-to-date discussions!
> 
> 
>>The big issue there is what part of this we should solve here.
>>Should we concentrate specifically on the application/host
>>to network signalling?  I think not and others have agreed.
>>Should we try to design something that goes end to end?  If we
>>do that, do we have a "chicken and egg" problem of needing to
>>have the technology everywhere for things to work?
>>
> 
> IMO end to end is more desired in NSIS. To attain this we may 
> allow signaling from host to edge, from edge to edge, from 
> hop to hop, etc. As for the "chicken and egg" problem, I believe
> some kind of "migration" may also be developed later, e.g., 
> "NSIS tunnel" for non-NSIS clouds depending on the needs.
>


Before we define end-to-end, edge-to-edge and domain-to-domain, ask the 
following:

- why do we signal in the first place?
- where do we need to signal?
- will signaling work in provider's networks?

We signal because there is no QoS when we are using some inter-active 
real-time applications. Since most of the Internet traffic is not within 
the scope of this "inter-active" and "real-time", let's not consider a 
kitchen-sink signaling protocol.

Also, let's be careful with adaptive applications. They look very nice 
on paper, but when you see what type of switches are used interfacing 
between voice networks and the Internet, you gotta be kidding me to 
insist on adaptiveness for your traffic....

Currently, most of the backbone networks are over-provisioned, so no 
serious signaling is required yet. End-to-end signaling is very 
attractive to the end users, but the providers will not allow the users 
to tell the routers how much to reserve. In fact, I doubt the providers 
will listen to anything that end-user are throwing at them. So other 
than some end-to-end measurement-based approach, I don't see e2e 
signaling will fly in the present network.

The place where we need signaling is inside the access networks. This is 
the place where the providers have no incentive to over-provision (to 
flat-rate users? please), and this is the place where we may see 
resource shortage.

Finally, the providers are motivated by money to provide any additional 
service. Unless the traffic that they are carrying worth something, they 
will never deploy some extra "stuff" inside the network. So what's worth 
money? ....

- voice traffic! I am not only talking about VoIP; I am talking all the 
voice traffic that use the Internet infrastructure.

- wireless traffic: users packets are not landed inside the backbone, so 
the access network needs to do more to those flows.

- VPN (an over-used term :-)): but some users want to have QoS 
reservation even though they are sending any traffic. Not for any 
technical reason, it's a business reason. Have you seen the amount of 
traffic in a SNA network, and how much they have been charged? :-)

In conclusion, IMHO, NSIS should

1. focus on edge-to-edge signaling;
2. focus on a small set of applications to deal with;
3. focus on the relevant provider impact;
4. don't do a kitchen-sink blahblah that lasts for years.

3 cents,

- Ping Pan



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



From daemon@optimus.ietf.org  Wed Jan 23 14:48: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 OAA22390
	for <nsis-archive@odin.ietf.org>; Wed, 23 Jan 2002 14:48:11 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id OAA13971
	for nsis-archive@odin.ietf.org; Wed, 23 Jan 2002 14:48: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 OAA13644;
	Wed, 23 Jan 2002 14:38: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 OAA13611
	for <nsis@optimus.ietf.org>; Wed, 23 Jan 2002 14:38:00 -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 OAA21929
	for <nsis@ietf.org>; Wed, 23 Jan 2002 14:37:57 -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.34)
	  id 16TTD5-0005N9-00; Wed, 23 Jan 2002 20:37:27 +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 g0NJbRa17103;
	Wed, 23 Jan 2002 20:37:27 +0100
Message-ID: <3C4F10F7.50D418BF@ee.tu-berlin.de>
Date: Wed, 23 Jan 2002 20:37:27 +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: Ping Pan <pingpan@juniper.net>
CC: David.Partain@ericsson.com, NSIS <nsis@ietf.org>
Subject: Re: [NSIS] Framework & requirements part of the "Two kinds of  
 requirements" thread
References: <0GQD001M6YBEYP@mbb1.ericsson.se> <3C4EF853.B10F8796@ee.tu-berlin.de> <3C4F0560.20508@juniper.net>
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 Ping,

My comment inline [XF].

Ping Pan wrote:
> 
> Xiaoming Fu wrote:
> 
> > Hi David,
> >
> > A great work to summarize these up-to-date discussions!
> >
> >
> >>The big issue there is what part of this we should solve here.
> >>Should we concentrate specifically on the application/host
> >>to network signalling?  I think not and others have agreed.
> >>Should we try to design something that goes end to end?  If we
> >>do that, do we have a "chicken and egg" problem of needing to
> >>have the technology everywhere for things to work?
> >>
> >
> > IMO end to end is more desired in NSIS. To attain this we may
> > allow signaling from host to edge, from edge to edge, from
> > hop to hop, etc. As for the "chicken and egg" problem, I believe
> > some kind of "migration" may also be developed later, e.g.,
> > "NSIS tunnel" for non-NSIS clouds depending on the needs.
> >
> 
> Before we define end-to-end, edge-to-edge and domain-to-domain, ask the
> following:
> 
> - why do we signal in the first place?
> - where do we need to signal?
> - will signaling work in provider's networks?
> 
> We signal because there is no QoS when we are using some inter-active
> real-time applications. Since most of the Internet traffic is not within
> the scope of this "inter-active" and "real-time", let's not consider a
> kitchen-sink signaling protocol.
> 
> Also, let's be careful with adaptive applications. They look very nice
> on paper, but when you see what type of switches are used interfacing
> between voice networks and the Internet, you gotta be kidding me to
> insist on adaptiveness for your traffic....
> 
> Currently, most of the backbone networks are over-provisioned, so no
> serious signaling is required yet. End-to-end signaling is very
> attractive to the end users, but the providers will not allow the users
> to tell the routers how much to reserve. 

[XF]Are you assuming signaling carries only for quantitive, final-reserved 
resource parameters? Various QoS paradigms in routers could explain the 
contents in the signaling message differently.

> In fact, I doubt the providers
> will listen to anything that end-user are throwing at them. So other
> than some end-to-end measurement-based approach, I don't see e2e
> signaling will fly in the present network.

[XF]I think providers, at least access network providers, should listen 
to a QoS user's preference for what kind of traffic he's going to get/receive. 
And I guess one reason why QoS has not well-deployed is that no e2e QoS
mechanism/protocol is well-defined.

>
> The place where we need signaling is inside the access networks. This is
> the place where the providers have no incentive to over-provision (to
> flat-rate users? please), and this is the place where we may see
> resource shortage.
>
[XF]There might be incentive for core network providers to calculate/engineering 
how (roughly) the degree of e.g.,over-provisioning for traffic from/to 
access networks, if users/access network providers want e2e QoS.

> 
> Finally, the providers are motivated by money to provide any additional
> service. Unless the traffic that they are carrying worth something, they
> will never deploy some extra "stuff" inside the network. So what's worth
> money? ....

[XF]If traffic/user demanding e2e QoS is more and more popular, still no incentive?
Providers always tend to attract more users.

> 
> - voice traffic! I am not only talking about VoIP; I am talking all the
> voice traffic that use the Internet infrastructure.
>
> 
> - wireless traffic: users packets are not landed inside the backbone, so
> the access network needs to do more to those flows.
> 
> - VPN (an over-used term :-)): but some users want to have QoS
> reservation even though they are sending any traffic. Not for any
> technical reason, it's a business reason. Have you seen the amount of
> traffic in a SNA network, and how much they have been charged? :-)
> 
> In conclusion, IMHO, NSIS should
> 
> 1. focus on edge-to-edge signaling;
same as host-edge? Furthermore inter-domain QoS signaling could serve for a 
final e2e protocol, just like the way how routing works for e2e traffic.

> 2. focus on a small set of applications to deal with;
[XF]I think for the sake of scalability, independence of specific applications 
(but may rely on some signaling description protocol e.g., SDPng) should be a 
goal for NSIS.

> 3. focus on the relevant provider impact;
[XF]From the technical point of view this is part of the edge to edge signaling, 
but I guess policy issues should be out of NSIS scope 

> 4. don't do a kitchen-sink blahblah that lasts for years.
> 
> 3 cents,
> 
> - Ping Pan
> 

Xiaoming

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



From daemon@optimus.ietf.org  Wed Jan 23 15: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 PAA24868
	for <nsis-archive@odin.ietf.org>; Wed, 23 Jan 2002 15:49:49 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id PAA16989
	for nsis-archive@odin.ietf.org; Wed, 23 Jan 2002 15:49: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 PAA16643;
	Wed, 23 Jan 2002 15: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 PAA16577
	for <nsis@optimus.ietf.org>; Wed, 23 Jan 2002 15:37:14 -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 PAA24397
	for <nsis@ietf.org>; Wed, 23 Jan 2002 15:37:10 -0500 (EST)
Received: from juniper.net (dhcp-nsw-47.juniper.net [172.17.13.209])
	by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g0NKad686955;
	Wed, 23 Jan 2002 12:36:39 -0800 (PST)
	(envelope-from pingpan@juniper.net)
Message-ID: <3C4F1F2D.3040805@juniper.net>
Date: Wed, 23 Jan 2002 12:38:05 -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: fu@ee.tu-berlin.de
CC: David.Partain@ericsson.com, NSIS <nsis@ietf.org>
Subject: Re: [NSIS] Framework & requirements part of the "Two kinds of   requirements" thread
References: <0GQD001M6YBEYP@mbb1.ericsson.se> <3C4EF853.B10F8796@ee.tu-berlin.de> <3C4F0560.20508@juniper.net> <3C4F10F7.50D418BF@ee.tu-berlin.de>
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

Xiaoming Fu wrote:

>>
>>We signal because there is no QoS when we are using some inter-active
>>real-time applications. Since most of the Internet traffic is not within
>>the scope of this "inter-active" and "real-time", let's not consider a
>>kitchen-sink signaling protocol.
>>
>>Also, let's be careful with adaptive applications. They look very nice
>>on paper, but when you see what type of switches are used interfacing
>>between voice networks and the Internet, you gotta be kidding me to
>>insist on adaptiveness for your traffic....
>>
>>Currently, most of the backbone networks are over-provisioned, so no
>>serious signaling is required yet. End-to-end signaling is very
>>attractive to the end users, but the providers will not allow the users
>>to tell the routers how much to reserve. 
>>
> 
> [XF]Are you assuming signaling carries only for quantitive, final-reserved 
> resource parameters? Various QoS paradigms in routers could explain the 
> contents in the signaling message differently.
> 


Signaling is signaling is signaling. What's been carried is not a 
consideration here.


> 
>>In fact, I doubt the providers
>>will listen to anything that end-user are throwing at them. So other
>>than some end-to-end measurement-based approach, I don't see e2e
>>signaling will fly in the present network.
>>
> 
> [XF]I think providers, at least access network providers, should listen 
> to a QoS user's preference for what kind of traffic he's going to get/receive. 


Provider's decision is based on how to make money. They subscribe users, 
and provide services to those users. The only thing that a user can do 
is to monitor its own traffic and complain if his/her service contact is 
not honored. Maybe this will change in the future, but not now.


> And I guess one reason why QoS has not well-deployed is that no e2e QoS
> mechanism/protocol is well-defined.
> 


Really? :-)


> [XF]If traffic/user demanding e2e QoS is more and more popular, still no incentive?
> Providers always tend to attract more users.
>


Providers tend to attract more users that are willing to pay more for 
the service. One of the lessons we have learnt from the dot-com is: 
providing nice things for free is a good way to be popular and make 
friends, but it is a lousy way to do business.


>>In conclusion, IMHO, NSIS should
>>
>>1. focus on edge-to-edge signaling;
>>
> same as host-edge? Furthermore inter-domain QoS signaling could serve for a 
> final e2e protocol, just like the way how routing works for e2e traffic.
> 


No! How does routing work for e2e? End users don't even see IGP, and 
never mind inter-domain. BTW, tell me, in the current networking 
enviornment, why providers want to do inter-domain QoS if the objective 
to keep the money-making traffic within their own networks as long as 
possible?


> 
>>2. focus on a small set of applications to deal with;
>>
> [XF]I think for the sake of scalability, independence of specific applications 
> (but may rely on some signaling description protocol e.g., SDPng) should be a 
> goal for NSIS.
> 


Keep on dreaming at end hosts as long as the routers don't have to deal 
with it. :-)

- Ping



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



From daemon@optimus.ietf.org  Wed Jan 23 15:56: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 PAA25115
	for <nsis-archive@odin.ietf.org>; Wed, 23 Jan 2002 15:56:35 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id PAA17315
	for nsis-archive@odin.ietf.org; Wed, 23 Jan 2002 15:56: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 PAA16909;
	Wed, 23 Jan 2002 15:46: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 PAA16878
	for <nsis@optimus.ietf.org>; Wed, 23 Jan 2002 15:46:33 -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 PAA24816
	for <nsis@ietf.org>; Wed, 23 Jan 2002 15:46:29 -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 g0NKk0d26954;
	Wed, 23 Jan 2002 12:46:00 -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 AAS82374;
	Wed, 23 Jan 2002 12:45:29 -0800 (PST)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA19233; Wed, 23 Jan 2002 12:45:59 -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: <15439.8455.819353.220275@thomasm-u1.cisco.com>
Date: Wed, 23 Jan 2002 12:45:59 -0800 (PST)
To: Ping Pan <pingpan@juniper.net>
Cc: fu@ee.tu-berlin.de, David.Partain@ericsson.com, NSIS <nsis@ietf.org>
Subject: Re: [NSIS] Framework & requirements part of the "Two kinds of   requirements" thread
In-Reply-To: <3C4F1F2D.3040805@juniper.net>
References: <0GQD001M6YBEYP@mbb1.ericsson.se>
	<3C4EF853.B10F8796@ee.tu-berlin.de>
	<3C4F0560.20508@juniper.net>
	<3C4F10F7.50D418BF@ee.tu-berlin.de>
	<3C4F1F2D.3040805@juniper.net>
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

Ping Pan writes:
 > Xiaoming Fu wrote:
 > >>In fact, I doubt the providers
 > >>will listen to anything that end-user are throwing at them. So other
 > >>than some end-to-end measurement-based approach, I don't see e2e
 > >>signaling will fly in the present network.
 > >>
 > > 
 > > [XF]I think providers, at least access network providers, should listen 
 > > to a QoS user's preference for what kind of traffic he's going to get/receive. 
 > 
 > 
 > Provider's decision is based on how to make money. They subscribe users, 
 > and provide services to those users. The only thing that a user can do 
 > is to monitor its own traffic and complain if his/her service contact is 
 > not honored. Maybe this will change in the future, but not now.

   This seems to presuppose that provider/$$$ is what
   will drive qos deployment. Enterprise does not have
   the same economic goals, and signaled qos may very
   well be viable as a means of admission control and
   perhaps accounting. 

		       Mike

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



From daemon@optimus.ietf.org  Wed Jan 23 16:03: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 QAA25313
	for <nsis-archive@odin.ietf.org>; Wed, 23 Jan 2002 16:03:44 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id QAA17845
	for nsis-archive@odin.ietf.org; Wed, 23 Jan 2002 16: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 PAA17190;
	Wed, 23 Jan 2002 15:53: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 PAA17161
	for <nsis@optimus.ietf.org>; Wed, 23 Jan 2002 15:53:36 -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 PAA25043
	for <nsis@ietf.org>; Wed, 23 Jan 2002 15:53:32 -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 g0NKteT15396;
	Wed, 23 Jan 2002 14:55:40 -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 g0NKqvq22202;
	Wed, 23 Jan 2002 14:52:57 -0600 (CST)
Received: by TRIMAIL2.ad.tri.sbc.com with Internet Mail Service (5.5.2653.19)
	id <ZND320NJ>; Wed, 23 Jan 2002 14:53:25 -0600
Message-ID: <905A1C4ABF353F4C8CC16FA9F53DD0D638B9AF@TRIMAIL2.ad.tri.sbc.com>
From: "Schneider, Marco" <schneider@tri.sbc.com>
To: "'Georgios Karagiannis (ELN)'" <Georgios.Karagiannis@eln.ericsson.se>
Cc: "'nsis@ietf.org'" <nsis@ietf.org>
Subject: RE: [NSIS] Georgios' framework decomposition (was Two kinds of re
	 quirements)
Date: Wed, 23 Jan 2002 14:53:25 -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 Georgios, David

First of all, I support the goal of modular extensible protocol.

The framework appears to make a some presuppositions about the solution that
impose unnecessary and undesireable constraints on the solution. Perhaps it
is simply a matter of clarifying the framework.

We need to develop requirements for an NSIS UNI that allows a host to
request a QOS connection across the network to another host. This protocol
will run across a host to network interface. Presumably this is between host
and edge in the framework diagram provided.

1) The framework refers to an "every hop" protocol component which is shown
in the interior of the network. This presupposes a hop by hop signaling
protocol within the interior of the network. There are a wide variety of
approaches to achieving the QOS connection. 

2) The framework imposes this assumption (of hop by hop signaling) on the
functionality for the NSIS UNI since "everyhop" is shown as part of the host
functionality. 

3) Whereas hop by hop signaling within the interior of a network may require
information on the topology of the network, our requirement is that the host
should not be able to access any topology information. 
 
Marco

-----Original Message-----
From: Georgios Karagiannis (ELN)
[mailto:Georgios.Karagiannis@eln.ericsson.se]
Sent: Wednesday, January 23, 2002 4:55 AM
To: Schneider, Marco
Cc: 'nsis@ietf.org'
Subject: RE: [NSIS] Georgios' framework decomposition (was Two kinds of
re quirements)


Hi Marco

I agree with David's explanation (see below)!

Best Regards,
georgios

-----Original Message-----
From: David Partain [mailto:David.Partain@ericsson.com]
Sent: woensdag 23 januari 2002 11:30
To: NSIS Mailing List
Subject: [NSIS] Georgios' framework decomposition (was Two kinds of
requirements)


Hi,

Georgios Karagiannis wrote:

> The possible NSIS protocol components that can be
> used on the different NSIS protocol types are the following:
>
>  * used components in "end host to end host" NSIS scenario:
>       [everyhost], [everyedge], [everyhop]
>
>  * used components in "end host to proxy" NSIS scenario:
>       [everyhost], [everyedge], [everyhop]
>
>  * used components in "end host to edge" NSIS scenario:
>       [everyedge], [everyhop]
>
>  * used components in "edge to edge" NSIS scenario:
>       [everyedge], [everyhop]
>
> Regarding the priority, we should decide it after the requirements,
> architecture and framework drafts are done!

Marco Schneider responded:

> Are you suggesting that we organize our requirements according to the
> implementation solution you have proposed below? If that is the case then
I
> strongly disagree.

I don't see Georgios' framework figure or the text above as an
"implementation solution".  It's simply a way of taking a _big_
problem and breaking it down into smaller problem areas that
need attention.

The requirements, in my view, must be based upon the
applications that will use the network ("use case based
requirements").  There seem to be several voices pushing
for this.

If you could, please help me understand exactly what you
disagree with.

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  Wed Jan 23 16:26: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 QAA26088
	for <nsis-archive@odin.ietf.org>; Wed, 23 Jan 2002 16:26:18 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id QAA18385
	for nsis-archive@odin.ietf.org; Wed, 23 Jan 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 QAA18111;
	Wed, 23 Jan 2002 16:16:42 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA18080
	for <nsis@optimus.ietf.org>; Wed, 23 Jan 2002 16:16:40 -0500 (EST)
Received: from heyday.seas.upenn.edu (root@HEYDAY.SEAS.UPENN.EDU [158.130.64.49])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25729
	for <nsis@ietf.org>; Wed, 23 Jan 2002 16:16:35 -0500 (EST)
Received: from seas.upenn.edu (IDENT:rute@M306PC6.SEAS.UPENN.EDU [158.130.66.239])
	by heyday.seas.upenn.edu (8.10.1/8.10.1) with ESMTP id g0NLGYG22252
	for <nsis@ietf.org>; Wed, 23 Jan 2002 16:16:35 -0500 (EST)
Message-ID: <3C4F26EB.7050209@seas.upenn.edu>
Date: Wed, 23 Jan 2002 16:11:07 -0500
From: Rute Sofia <rsofia@seas.upenn.edu>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.6) Gecko/20011120
X-Accept-Language: en-us
MIME-Version: 1.0
To: nsis@ietf.org
Subject: Re: [NSIS] Framework & requirements part of the "Two kinds of   requirements" thread
References: <0GQD001M6YBEYP@mbb1.ericsson.se> <3C4EF853.B10F8796@ee.tu-berlin.de> <3C4F0560.20508@juniper.net> <3C4F10F7.50D418BF@ee.tu-berlin.de> <3C4F1F2D.3040805@juniper.net>
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

 >
 > Provider's decision is based on how to make money. They subscribe
 > users, and provide services to those users. The only thing that a user
 > can do is to monitor its own traffic and complain if his/her service
 > contact is not honored. Maybe this will change in the future, but not
 > now.
 >
True. But here we have the "chicken & egg" problem: providers subscribe
users and provide (supposedly) adequate services to users; however,
users will only subscribe a payed service if it prooves to really work.
More, users don't want to try something that is payed, they want
*assurance* about the quality of that service *before* they use it...so,
by that way of thinking we end up with BE again and don't need signaling...


 >
 > Providers tend to attract more users that are willing to pay more for
 > the service. One of the lessons we have learnt from the dot-com is:
 > providing nice things for free is a good way to be popular and make
 > friends, but it is a lousy way to do business.

Once again, we'll have the same problem; you mention "Dot.coms"; as
counter-example, we have the downloading of mp3...after napster, does
the same percentage of users gets/buys music streams? ...

This comments are just to mean that maybe we're deviating from the
goal...thinking what is the best way to please providers so QoS
mechanisms will be "fastly" deployed is not the solution.

I agree with:

- focusing on edge-to-edge signalling;
- study small set of applications and possibly adaptive behavior.


regards,

Rute






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



From daemon@optimus.ietf.org  Wed Jan 23 17:12: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 RAA27752
	for <nsis-archive@odin.ietf.org>; Wed, 23 Jan 2002 17:12:00 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id RAA20550
	for nsis-archive@odin.ietf.org; Wed, 23 Jan 2002 17:12:01 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA19545;
	Wed, 23 Jan 2002 16:59: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 QAA19512
	for <nsis@optimus.ietf.org>; Wed, 23 Jan 2002 16:59:37 -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 QAA27478
	for <nsis@ietf.org>; Wed, 23 Jan 2002 16:59:35 -0500 (EST)
Received: from juniper.net (dhcp-nsw-47.juniper.net [172.17.13.209])
	by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g0NLwu691472;
	Wed, 23 Jan 2002 13:58:56 -0800 (PST)
	(envelope-from pingpan@juniper.net)
Message-ID: <3C4F3276.9050705@juniper.net>
Date: Wed, 23 Jan 2002 14:00:22 -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: Michael Thomas <mat@cisco.com>
CC: fu@ee.tu-berlin.de, David.Partain@ericsson.com, NSIS <nsis@ietf.org>
Subject: Re: [NSIS] Framework & requirements part of the "Two kinds of   requirements" thread
References: <0GQD001M6YBEYP@mbb1.ericsson.se>	<3C4EF853.B10F8796@ee.tu-berlin.de>	<3C4F0560.20508@juniper.net>	<3C4F10F7.50D418BF@ee.tu-berlin.de>	<3C4F1F2D.3040805@juniper.net> <15439.8455.819353.220275@thomasm-u1.cisco.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

Michael Thomas wrote:

> Ping Pan writes:
>  > Xiaoming Fu wrote:
>  > >>In fact, I doubt the providers
>  > >>will listen to anything that end-user are throwing at them. So other
>  > >>than some end-to-end measurement-based approach, I don't see e2e
>  > >>signaling will fly in the present network.
>  > >>
>  > > 
>  > > [XF]I think providers, at least access network providers, should listen 
>  > > to a QoS user's preference for what kind of traffic he's going to get/receive. 
>  > 
>  > 
>  > Provider's decision is based on how to make money. They subscribe users, 
>  > and provide services to those users. The only thing that a user can do 
>  > is to monitor its own traffic and complain if his/her service contact is 
>  > not honored. Maybe this will change in the future, but not now.
> 
>    This seems to presuppose that provider/$$$ is what
>    will drive qos deployment. Enterprise does not have
>    the same economic goals, and signaled qos may very
>    well be viable as a means of admission control and
>    perhaps accounting. 
>


Mike,

You are right about enterprise. I have overlooked things. Thank you!

- Ping


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



From daemon@optimus.ietf.org  Thu Jan 24 03:54: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 DAA17804
	for <nsis-archive@odin.ietf.org>; Thu, 24 Jan 2002 03:54:29 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id DAA18643
	for nsis-archive@odin.ietf.org; Thu, 24 Jan 2002 03:54: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 DAA18270;
	Thu, 24 Jan 2002 03:43: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 DAA18239
	for <nsis@optimus.ietf.org>; Thu, 24 Jan 2002 03:43:24 -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 DAA17664
	for <nsis@ietf.org>; Thu, 24 Jan 2002 03:43:21 -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 g0O8jTT17717;
	Thu, 24 Jan 2002 02:45:29 -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 g0O8goS12274;
	Thu, 24 Jan 2002 02:42:50 -0600 (CST)
Received: by TRIMAIL2.ad.tri.sbc.com with Internet Mail Service (5.5.2653.19)
	id <ZND3JBSK>; Thu, 24 Jan 2002 02:43:16 -0600
Message-ID: <905A1C4ABF353F4C8CC16FA9F53DD0D60271A0@TRIMAIL2.ad.tri.sbc.com>
From: "Chen, Weijing" <wchen@tri.sbc.com>
To: David.Partain@ericsson.com
Cc: NSIS Mailing List <nsis@ietf.org>
Subject: RE: [NSIS] Framework & requirements part of the "Two kinds of req
	uirements" thread
Date: Thu, 24 Jan 2002 02:43:16 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: nsis-admin@ietf.org
Errors-To: nsis-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Next Steps in Signaling <nsis.ietf.org>
X-BeenThere: nsis@ietf.org


I have fundamental disagreement with David's point.

1. David's proposal of working requirement within so called "framework" is
putting the cart before the horse. Because we think one framework is cool,
we confine our requirements and use cases within that framework. It is
totally unacceptable.

2. 

|-----|                                                  |-----|
|ehost|<------------------------------------------------>|ehost|
|-----|                                                  |-----|
|     |                                                  |     |
|-----|            |-----|            |-----|            |-----|
|eedge|<---------->|eedge|<---------->|eedge|<---------->|eedge|
|-----|            |-----|            |-----|            |-----|
|     |            |     |            |     |            |     |
|-----|   |----|   |-----|   |----|   |-----|   |----|   |-----|
|ehop |<->|ehop|<->|ehop |<->|ehop|<->|ehop |<->|ehop|<->|ehop |
|-----|   |----|   |-----|   |----|   |-----|   |----|   |-----|
 host    interior   edge    interior   edge     interior  host
         w/in domain       w/in domain        w/in domain

In above picture, [host] has to assemble and process the [ehop], [eedge] in
addition to [ehost] part. How will the [host] correctly assemble and process
the [ehop] and [eedge] pieces? It implies that [host] has global view of
[ehop] and [eedge] in every domains. For this to happen, there must be
another protocol to exchange network information and pass whole network view
to [host]. So on, and so on, and sooner we know that we revive an ultimate
engineer dream: a protocol for all and do all. Be there, done that, and
failed. Otherwise we wouldn't be here to debate about what NSIS should be.

The right picture should be (if you insist talking about the framework
before requirement):

                   |-----|   |----|   |-----|  
                   |ehop |<->|ehop|<->|ehop |   
                   |-----|   |----|   |-----| 
                   |     |            |     |
                   |-----|            |-----|
                   |glue |            |glue |
                   |-----|            |-----|
                   |     |            |     |
|-----|            |-----|            |-----|            |-----|
|ehost|<---------->|ehost|<---------->|ehost|<---------->|ehost|
|-----|            |-----|            |-----|            |-----|
 host                edge     hop      edge                host
           domain            domains             domain
                             (inter and
                              intra)
           NSIS                                   NSIS

Now what about "glue"? Shall NSIS do it? Part of me says yes, another says
no. I am 50/50.

--
Weijing Chen
SBC Technology Resources
9505 Arboretum Blvd.
Austin, TX 78759
512 372 5710
wchen@tri.sbc.com



-----Original Message-----
From: David Partain [mailto:David.Partain@ericsson.com] 
Sent: Wednesday, January 23, 2002 3:58 AM
To: NSIS Mailing List
Subject: [NSIS] Framework & requirements part of the "Two kinds of
requirements" thread

Greetings all,

I'd like to offer my take on part of the thread "Two kinds
of requirements" to see if we can collectively reach any sort
of conclusion based on what's been written.  I doubt I'll say
anything new, but perhaps it'll help summarize a bit.

To cut to the chase, the conclusion of this mail is that
I think:

 - we should use the "framework" below as the starting point of
   framework discussions
 - the requirements should grow from use cases of particular
   applications that will use the network

The original mail postulated that people are wanting to work
on two kinds of requirements here:

 - end-host to end-host, or application to application
   signalling

 - transport level signalling

From that point, there has been a hearty debate about whether
this indeed is true, as well as a host of other issues.

I think the following points have been made, amongst others:

 - It should support the use of throughput adaptive applications
   and the ability for a traffic flow to express its QoS
   preferences with regard to the throughput values which it
   may be allocated.

 - One part of the thread was about whether RSVP and related
   work (e.g., RFC 2998), or perhaps SDPng, are suitable
   solutions.  While it's obvious that we need to learn from
   and perhaps start from one of these efforts in working on
   NSIS, it also seems clear that we shouldn't start working
   on that until the requirements are done.

 - There's no chance we'll create a single one-size-fits-all
   application-related signalling protocol that will be used
   by everyone.  That seems very clear.

 - There's a need for something transport independent that can
   help signal QoS needs across multiple domains in order
   to help the application-related signalling protocols do
   their thing.

The big issue there is what part of this we should solve here.
Should we concentrate specifically on the application/host
to network signalling?  I think not and others have agreed.
Should we try to design something that goes end to end?  If we
do that, do we have a "chicken and egg" problem of needing to
have the technology everywhere for things to work?

A case has been made that the goal should be to create a
signalling protocol that has different kinds of components
appropriate to different parts of the problem.  Georgios K.
proposed the following figure, which I like quite a lot and
which others have said is good, as a way of looking at it:

|-----|                                                  |-----|
|ehost|<------------------------------------------------>|ehost|
|-----|                                                  |-----|
|     |                                                  |     |
|-----|            |-----|            |-----|            |-----|
|eedge|<---------->|eedge|<---------->|eedge|<---------->|eedge|
|-----|            |-----|            |-----|            |-----|
|     |            |     |            |     |            |     |
|-----|   |----|   |-----|   |----|   |-----|   |----|   |-----|
|ehop |<->|ehop|<->|ehop |<->|ehop|<->|ehop |<->|ehop|<->|ehop |
|-----|   |----|   |-----|   |----|   |-----|   |----|   |-----|
 host    interior   edge    interior   edge     interior  host
         w/in domain       w/in domain        w/in domain

   ehost = everyhost
   eedge = everyedge
   ehop  = everyhop

NSIS protocol decomposition:

 * A "host" could be an end host or a proxy.  It can process
   and use the "everyhost", "everyedge", and "everyhop"
   protocol components.

 * An "edge" can be a Diffserv edge, MPLS edge, etc.  It can
   process and use the "everyedge", and "everyhop" protocol
   components. The "everyhost" protocol component is not
   processed (used or checked) but is carried onward.

 * An "interior within domain" can be any router within
   a domain.  It can process and use only the "everyhop"
   protocol component.  The "everyhost" and "everyedge"
   protocol components are not processed (used or checked)
   but are carried onward.

The everyhop bit within a domain provides signalling facilities
for that particular domain and is very likely to differ from
the everyhop bit used in the next boarding domain.

The point of all of this is to get a concatenation of results.
Each domain is responsible for taking its own decisions in its
own domain-specific ways.  The concatenation of the everyhop
decisions within a domain provides the domain's answer.
The concatenation of the domains' results gives and end to
end answer that can be used by the everyhost bit.

I think that having this overall framework -- for lack of a
better term -- in mind is very helpful.

If we can agree that this is a reasonable framework to use as
the basis of discussion, I think that what we need to do is
to produce a set of requirements for different "applications"
that will use these networks/this framework.  Indeed, I believe
this matches Keith Allen's request that requirements be based on
use cases.  If we know we're going to use the NSIS protocol on
a cellular wireless network (just to pull an example out of the
air :-)), then that "use case" implies a set of requirements.
A different scenario (e.g., the core of the network) implies
another set of requirements.

I personally think this is the right way forward and would
like to see this group move in this direction.

Georgios added some more thoughts on this topic
which addressed the applicability and prioritization
of work.  That can be found in the archive at
http://www1.ietf.org/mail-archive/working-groups/nsis/current/msg00418.html

I realize that I haven't covered everyone's particular topic
in this thread, but perhaps it'll help focus on one part of
the discussion.  If someone wants to summarize some other
sub-thread, that would be great...

Cheers,

dlp

ps. I think it would be very useful if Subject lines could more
accurately reflect the topic covered in the mail.  Long threads
with the same subject and covering a multitude of topics is
difficult to follow...

_______________________________________________
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 Jan 24 04:34: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 EAA18287
	for <nsis-archive@odin.ietf.org>; Thu, 24 Jan 2002 04:34:00 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id EAA20243
	for nsis-archive@odin.ietf.org; Thu, 24 Jan 2002 04:34: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 EAA19549;
	Thu, 24 Jan 2002 04:24: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 EAA19481
	for <nsis@optimus.ietf.org>; Thu, 24 Jan 2002 04:24:16 -0500 (EST)
Received: from newish7.ericsson.com.au (newish7.ericsson.com.au [203.61.155.116])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18116
	for <nsis@ietf.org>; Thu, 24 Jan 2002 04:24:11 -0500 (EST)
Received: from brsf10.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10])
	by newish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id UAA03811;
	Thu, 24 Jan 2002 20:22:49 +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 UAA14157;
	Thu, 24 Jan 2002 20:24:07 +1100 (EST)
Received: from localhost.localdomain (MINDY [147.214.68.87]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id XRFZPHV4; Thu, 24 Jan 2002 20:24:03 +1100
Subject: RE: [NSIS] Two kinds of requirements
From: Brian Williams <brian.williams@ericsson.com.au>
To: Marco Schneider <schneider@tri.sbc.com>
Cc: Gary Kenward <gkenward@nortelnetworks.com>, Radhika Roy <rrroy@att.com>,
        john loughney <john.loughney@nokia.com>, brunner@ccrle.nec.de,
        Yaron Kahana <ykahana@comgates.co.il>,
        Ruediger Geib <Ruediger.Geib@t-systems.com>,
        Dick Knight <dick.rr.knight@bt.com>, nsis@ietf.org
In-Reply-To: 
	<905A1C4ABF353F4C8CC16FA9F53DD0D638B9AD@TRIMAIL2.ad.tri.sbc.com>
References: <905A1C4ABF353F4C8CC16FA9F53DD0D638B9AD@TRIMAIL2.ad.tri.sbc.com>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Mailer: Evolution/1.0.1 
Date: 24 Jan 2002 20:19:57 +1100
Message-Id: <1011864004.2259.24.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 Marco.

On Thu, 2002-01-24 at 05:03, Schneider, Marco wrote:
> Brian,
> 
> Thanks for your discussion. So if I understand your comments correctly, you
> are concerned with NSIS QOS mapping to layer 2 QOS. Is there any way in
> which these requirements would impact the actual signaling protocol?
The comments highlighting the different network architectures was of
course simply to identify that the solution must allow for different
layering of communication in different networks. This is only to ensure
that limited views of networks and QoS layering don't lead to solutions
only tailored to one type.

The other aspect which I think you are actually questioning is whether
the layer 2 QoS mechanism shall impact the signalling protocol. My
position here is the actual signalling mechanism should be independent
of the lower layers, but the data carried to express the traffic and QoS
requirements can vary. 
/brian

 
> Marco
> 
> -----Original Message-----
> From: Brian Williams [mailto:brian.williams@ericsson.com.au]
> Sent: Wednesday, January 23, 2002 4:32 AM
> To: Schneider, Marco
> Cc: 'Gary Kenward'; 'Roy, Radhika R, ALASO'; Loughney "John
> (NRC/Helsinki); brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
> dick.rr.knight@bt.com; nsis@ietf.org
> Subject: RE: [NSIS] Two kinds of requirements
> 
> 
> Hi Marco.
> On Wed, 2002-01-23 at 09:48, Schneider, Marco wrote:
> > Garry,
> >  
> > >From an architectural/software perspective there is a session layer that
> > is logically built on top of the transport capability. From a protocol
> > stack perspective the session signaling is not layered on top of the
> > transport signaling in the framework I described. 
> >  
> > Aside: The following scenario is conceivable but not desireable.
> > Consider an ADSL customer that is logically connected to an edge router
> > via a DSLAM and an edge switch. Thus the layer 3 hop is realized by
> > multiple hops at layer 2. 
> A similar but slightly different situation exists also with cellular
> wireless networks. The layer 3 hop runs over one layer 2 hop, but this
> layer 2 hop is actually overlayed on top of multiple underlying layer 2
> hops. 
> 
> > Existing deployments that I am aware of use a
> > preprovisioned PVC for this. Now imagine that the customer does session
> > signaling resulting in NSIS signaling at layer 3. This could result in
> > the need for a new layer 2 connection because the existing PVC will not
> > do the job. 
> Certanly the case for cellular that a new lasyer 2 connection coule be
> required.
> 
> > Thus ATM UNI signaling might be initiated from the ADSL
> > Customer to allocate the resources for the layer 3 logical link. Yuck!
> > Obviously it is better to avoid this by pre-provisioning the access
> > network appropriately. Nevertheless, there may be other circumstances
> > where this type of situation will occur and one could imagine promoting
> > the layer 2 devices to be aware of NSIS so as to avoid multiple levels
> > of signaling. 
> For the cellular case, the end host is the device that sets up the layer
> 2 connection. This connection must use separate signalling to allow
> separate development of the layer 2 capabilities (ie dependent on
> cellular technology). The host though must be able to relate the QoS
> requirements signalled by NSIS to the layer 2 signalling. We are in the
> process of producing a draft to clarify these requirements based on
> typical layer 2 characteristics of cellular networks.
> /brian
>   
> > Marco
> >  
> > -----Original Message-----
> > From: Gary Kenward [mailto:gkenward@nortelnetworks.com]
> > Sent: Tuesday, January 22, 2002 3:34 PM
> > To: Schneider, Marco; 'Roy, Radhika R, ALASO'; Loughney John
> > (NRC/Helsinki); brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
> > dick.rr.knight@bt.com
> > Cc: nsis@ietf.org
> > Subject: RE: [NSIS] Two kinds of requirements
> > 
> > 
> > 
> > Marco:
> >  
> >    Good question: what do I mean by layering. I assume you are familiar
> > with protocol layers and their
> > properties. My major concern would be in the replication of information
> > exchanges at each layer, resulting
> > in greater overhead/delay. The end systems must to be involved in
> > establishing the necessary QoS, including
> > negotiation if viable, but the number of bits that are transported
> > through the network to set up this QoS
> > end to end must be kept to a minimum. Thus, I cringe at the possibility
> > of an end-to-end application exchange
> > triggering an RSVP request, triggering . . . in telephony terms, the
> > analogy is the call setup delay, which has
> > to be acceptable to the user, and, for wireless, has to be bandwidth
> > efficient.
> >  
> >   I hope I have explained my concern.
> >  
> > Cheers,
> > Gary
> >  
> >  
> > 
> > -----Original Message-----
> > From: Schneider, Marco [mailto:schneider@tri.sbc.com]
> > Sent: January 22, 2002 15:35
> > To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Roy, Radhika R, ALASO'; Loughney
> > John (NRC/Helsinki); brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
> > dick.rr.knight@bt.com
> > Cc: nsis@ietf.org
> > Subject: RE: [NSIS] Two kinds of requirements
> > 
> > 
> > Gary,
> > 
> > -----Original Message-----
> > From: Gary Kenward [mailto:gkenward@nortelnetworks.com]
> > Sent: Tuesday, January 22, 2002 9:02 AM
> > To: Schneider, Marco; 'Roy, Radhika R, ALASO'; Loughney John
> > (NRC/Helsinki); brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
> > dick.rr.knight@bt.com
> > Cc: nsis@ietf.org
> > Subject: RE: [NSIS] Two kinds of requirements
> > 
> > 
> > 
> > Marco: 
> > 
> > -----Original Message----- 
> > > [MS]  Yes, exactly. 
> > >   I don't believe you are proposing a "layering" of signalling
> > protocols, 
> > > one for session establishment, then one for transport, etc. 
> > > [MS]  This is exactly what has been proposed in RAP and SIP working
> > groups to the best 
> > > of my understanding. Because there does not exist a proxy signaling
> > capability that 
> > > allows a session to setup a connection on the users behalf, the
> > session forwards a 
> > > token to the end-system and then the end-system includes that token in
> > the RSVP path 
> > > message so that the reservation will go through. In this manner the
> > session layer does 
> > > not need to communicate directly with the transport layer. 
> > 
> > [gwk] I do not understand what "the session" represents in the above. It
> > would seem 
> > to me that you must have a session level entity, and that to "forward a
> > token to the 
> > end-system", it must have an interface/api to the "end-system". If this
> > "end-system" 
> > is including tokens in RSVP, then it is the entity setting up the
> > transport QoS (although 
> > it is not necessarly a transport layer entity, but rather a signalling
> > entity. If these 
> > two entites are co-located, then you do not have layered signalling
> > protocols. 
> > 
> > Have I missed something? 
> > 
> > [Schneider, Marco] I don't think you have missed anything. I may not
> > have understood what you meant by a layering of signaling protocols.
> > Please define this.
> > 
> > BTW: for many links, particularly wireless, layered signalling is not a
> > good idea. 
> > And, in general, layered signalling will always be slower then a single
> > signalling protocol. 
> > > So, the question, 
> > > becomes, how are the QoS transport mechanisms established? In the
> > internet 
> > > model there is only one end-to-end transport session (e.g. TCP, RTP,
> > UDP), 
> > > but underneath the transport is a series of inter-connected networks,
> > each 
> > > with potentially different characteristics. 
> > >   This is end-to-end QoS support structure has to be set up and
> > maintained 
> > > in order for the end to end session QoS to be realized. The solution
> > may be 
> > > a single protocol that travels from host to host, such as RSVP, or it
> > may 
> > > be a collection of protocols that are optimized for each portion of
> > the 
> > > end-to-end path: e.g. host to access network, access to core network, 
> > > core to core network, etc. 
> > >   It is too early to determine which approach is best, but in either
> > case, 
> > > do we not need to understand the end-to-end requirements for this
> > signalling 
> > > capability? 
> > > [MS]  So by end-to-end you are referring to both the end-systems and
> > the devices in 
> > > between. As a point of clarification, I asked Roy what he meant by
> > "End-to-End 
> > > Application Layer QOS Signaling" and his answer implied user
> > (end-system) to user (end- 
> > > system).  We have been using the term end-to-end in different ways
> > (contexts). The way 
> > > I normally use the term "end-to-end" is to include everything in
> > between (all the 
> > > hops). 
> > 
> > [gwk] I see the difference. I would say that I tend towards your
> > definition, in the 
> > following sense: the only QoS that matters is what the end-user sees, so
> > as a service 
> > characteristic, it must be provided between the two end systems / hosts.
> > In order to do 
> > this, however, some level of support is required at each hop along the
> > path. 
> > For me the term end-to-end (for example end-to-end call flow) includes
> > the components within the network that must come together to make it
> > work. The term end-to-end application level signaling seems like an
> > oxymoron since this signaling occurs with no involvement of the network
> > except to transfer the data packets but perhaps there is something I am
> > missing. 
> > 
> >  So, establishing QoS between the end systems requires a peer-to-peer
> > agreement between 
> > the end systems, a host-to-cloud agreement for the transport of the
> > packets, and 
> > some mechanism within the cloud to ensure that the agreed upon QoS is
> > provided. 
> > Depending upon the complexity of the cloud, the latter could imply all
> > sorts of QoS 
> > agreements between networks and even nodes, for packet forwarding. 
> > 
> >   Note that I have purposely NOT stated that any of these agreements are
> > negotiated or 
> > require a signalling protocol. My opinion is that it is better in the
> > long term to 
> > support negotiated services using signalling, as it provides more
> > flexibility. However, 
> > this can be overdone, say, as a silly example, by having the end-system
> > negotiate with 
> > every node in the network. So, the compromise is that some of the QoS
> > agreements will 
> > be incorporated into the network design (e.g. Diff Serv), some will be
> > configured by 
> > the operator(s) (e.g. through traffic engineering and policy
> > management), and others 
> > will be signalled. NSIS seems to be about determining where signalling
> > is appropriate, 
> > and what are the signalling peers, and what is the best protocol
> > solution or solutions. 
> > The catch is that the first two approaches actually encompass a wide
> > variety of technologies 
> > and scenarios. 
> > [Schneider, Marco]  I think you have articulated this very well and I am
> > in general agreement. 
> > 
> >   Sorry for stating the obvious. There is clearly some concern over the
> > use, for example, 
> > of RSVP, and I suspect that some people are concerned that "end-to-end
> > signalling" also 
> > means "hop-by-hop" ala RSVP. It could, but it does not have to. 
> > [Schneider, Marco] I think this is a very important distinction. I think
> > that the reverse is true as well in that some people are assuming a hop
> > by hop linear signaling model wherein the signaling takes place in order
> > along the path that the data will follow. The transport signaling that
> > is going to occur within the core of our network will be at a different
> > timescale than UNI signaling and there are a variety of solutions for
> > this including RSVP-te and CR-LDP which were developed for the purpose
> > of allocating traffic trunks.
> > 
> >   So, my view is that NSIS needs to ensure that the end-to-end QoS is
> > provided for, and 
> > develope the protocols where they are needed (but not where they are
> > not). At this point, 
> > that would seem to be host to edge, edge to edge, and at the very least,
> > with enough 
> > end to end semantics to ensure that the complete path supports QoS. I am
> > concerned about 
> > node to node signalling, as there are so many different approaches to
> > supporting node-to-node 
> > QoS. At the very least, I would like to see a framework, and the edge
> > solutions defined 
> > before we delve into "intra-network" issues. 
> > [Schneider, Marco] I think it all begins with the fact that a user must
> > be able to request a QOS/COS connection/flow to another user. If we
> > can't do that then everything else would appear to be pointless. The
> > next question is whether we want to develop protocols that assist the
> > network portion in delivering this capability and in what context(s).
> > 
> > 
> > BTW: in writing this, it dawned upon me that it might be best to write a
> > series of 
> > requirements rather then just one - i.e. tackle the problem piece by
> > piece. This approach 
> > does have drawbacks, but working groups seem to work better when they
> > focus on contained 
> > problem domains. A strawman framework might be useful in keeping the
> > incremental solutions 
> > coherent. 
> > [Schneider, Marco] I agree with the idea of tackling the requirements by
> > breaking the problem up. There is a catch 22 in that in order to breakup
> > it up we must to some degree presuppose a solution. 
> > 
> > 
> > > [MS] I think our basic requirement is that an end-system be able to
> > request (and 
> > > receive) a QOS connection to some other end-system (NSIS UNI). The
> > request part entails 
> > > an NSIS UNI. As you say the realization of this request can be
> > achieved in a number of 
> > > different ways. Now one solution is to invent an NSIS NNI that runs
> > between domains. If 
> > > we develop requirements for such an NSIS UNI then we have already
> > preproposed a 
> > > solution ahead of requirements. 
> > 
> > [gwk] We have to be extremely careful not to become pre-occupied with
> > requirements 
> > definition. All productive requirements definition efforts begin with
> > assumptions 
> > concerning the solution. In my view, requirements specifications are a
> > balance between 
> > presumption and prediction, particularly when dealing with "soft"
> > techologies such as 
> > protocols. The issue really is not whether a requirement is a "MAY" or a
> > "SHOULD" or 
> > whatever, the issue is whether a requirement actually helps us define
> > the solution 
> > (there are lot's of examples of "SHOULD" requirements that do not bring
> > value to the 
> > design process). 
> > [Schneider, Marco] I think there is a danger in implicit assumptions
> > that may not lead to the best solution. With respect to network support
> > of a QOS request, there are many different solutions and I am afraid
> > that some participants have presupposed a hop by hop signaling solution.
> > 
> > 
> > Given my observation above about writing a series of requirements, I
> > would recommend 
> > that we roughly map out the solution(some would call this a
> > "framework"). This map would 
> > form the preliminary list of deliverables for the wg charter, and then
> > pick a focussed 
> > problem area to begin with requirements. This is not "top down" design,
> > but "top down" 
> > processes seldom work. If this seems too abstract, what I am saying is
> > that I have no 
> > problem identifying that there are N problem areas to be addressed -
> > e.g. host to edge, 
> > edge to edge, node to node, etc. - and picking anyone for the first
> > design attempt. Of 
> > course, the challenge would be to keep an eye on the "big picture" or
> > end-to-end 
> > requirements in the process. 
> > [Schneider, Marco] I think that the network context for supporting NSIS
> > UNI is a quagmire, albeit a very fun one. The problems we need to
> > address depend upon what end-to-end architectures we wish to support.
> > There are a number of capabilities already being developed for network
> > QOS and there may be a number of ways to "glue" these together.
> > 
> > Deludedly yours,
> > 
> > Marco
> > 
> > Just my deluded point of view. 
> > Cheers, 
> > Gary 
> > 
> > [Schneider, Marco]  
> > *snip* 
> > 
> 
> 
> 
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis
> 
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis



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



From daemon@optimus.ietf.org  Thu Jan 24 04:44: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 EAA18507
	for <nsis-archive@odin.ietf.org>; Thu, 24 Jan 2002 04:44:49 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id EAA20750
	for nsis-archive@odin.ietf.org; Thu, 24 Jan 2002 04:44: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 EAA20219;
	Thu, 24 Jan 2002 04: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 EAA20192
	for <nsis@optimus.ietf.org>; Thu, 24 Jan 2002 04:33:43 -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 EAA18281
	for <nsis@ietf.org>; Thu, 24 Jan 2002 04:33:39 -0500 (EST)
Received: from esealnt409.al.sw.ericsson.se (ESEALNT409.al.sw.ericsson.se [153.88.251.32])
	by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g0O9Xfw13786
	for <nsis@ietf.org>; Thu, 24 Jan 2002 10:33:41 +0100 (MET)
Received: FROM esealnt746.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Thu Jan 24 10:32:44 2002 +0100
Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <YHLJMMCD>; Thu, 24 Jan 2002 10:32:27 +0100
Message-ID: <E244E44D6AB85E40AEEF7EAABE3545FA8233B3@enleent104.nl.eu.ericsson.se>
From: "Georgios Karagiannis (ELN)" <Georgios.Karagiannis@eln.ericsson.se>
To: "'Chen, Weijing'" <wchen@tri.sbc.com>
Cc: NSIS Mailing List <nsis@ietf.org>
Subject: RE: [NSIS] Framework & requirements part of the "Two kinds of req
	 uirements" thread
Date: Thu, 24 Jan 2002 10:32:42 +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 Weijing

Please see my comments in line.

[WC]>> 1. David's proposal of working requirement within so 
[WC]>> called "framework" is putting the cart before the horse. 
[WC]>> Because we think one framework is cool,
[WC]>> we confine our requirements and use cases within 
[WC]>> that framework. It is totally unacceptable.

In principle I agree with you. The framework should not be used
to  define the NSIS requirements. The NSIS requirements should be
produced based on different QoS needs of certain application types.
However, the mentioned framework can be used to decompose a 
complex QoS problem into certain simpler QoS problems.

[WC]>> 2. Figure
[WC]>>  In above picture, [host] has to assemble and process 
[WC]>>  the [ehop], [eedge] in addition to [ehost] part. How will 
[WC]>>  the [host] correctly assemble and process
[WC]>> the [ehop] and [eedge] pieces? It implies that [host] has 
[WC]>> global view of [ehop] and [eedge] in every domains. 
[WC]>> to happen, there must be another protocol to exchange network 
[WC]>> information and pass whole network view
[WC]>> to [host]. 

No it is not required that the "host" has a global view 
of the domains. The way of how this NSIS protocol finds the edges
and the hops is similar with the way the RSVPv1 protocol does it.

[WC] >> Now what about "glue"? Shall NSIS do it? Part of me 
[WC] >> says yes, another says
[WC] >> no. I am 50/50.

Please note that the NSIS charter mentions that a "framework" 
draft should be specified by March 2002.

Best regards,
Georgios


-----Original Message-----
From: Chen, Weijing [mailto:wchen@tri.sbc.com]
Sent: donderdag 24 januari 2002 9:43
To: David.Partain@ericsson.com
Cc: NSIS Mailing List
Subject: RE: [NSIS] Framework & requirements part of the "Two kinds of
req uirements" thread



I have fundamental disagreement with David's point.

1. David's proposal of working requirement within so called "framework" is
putting the cart before the horse. Because we think one framework is cool,
we confine our requirements and use cases within that framework. It is
totally unacceptable.

2. 

|-----|                                                  |-----|
|ehost|<------------------------------------------------>|ehost|
|-----|                                                  |-----|
|     |                                                  |     |
|-----|            |-----|            |-----|            |-----|
|eedge|<---------->|eedge|<---------->|eedge|<---------->|eedge|
|-----|            |-----|            |-----|            |-----|
|     |            |     |            |     |            |     |
|-----|   |----|   |-----|   |----|   |-----|   |----|   |-----|
|ehop |<->|ehop|<->|ehop |<->|ehop|<->|ehop |<->|ehop|<->|ehop |
|-----|   |----|   |-----|   |----|   |-----|   |----|   |-----|
 host    interior   edge    interior   edge     interior  host
         w/in domain       w/in domain        w/in domain

In above picture, [host] has to assemble and process the [ehop], [eedge] in
addition to [ehost] part. How will the [host] correctly assemble and process
the [ehop] and [eedge] pieces? It implies that [host] has global view of
[ehop] and [eedge] in every domains. For this to happen, there must be
another protocol to exchange network information and pass whole network view
to [host]. So on, and so on, and sooner we know that we revive an ultimate
engineer dream: a protocol for all and do all. Be there, done that, and
failed. Otherwise we wouldn't be here to debate about what NSIS should be.

The right picture should be (if you insist talking about the framework
before requirement):

                   |-----|   |----|   |-----|  
                   |ehop |<->|ehop|<->|ehop |   
                   |-----|   |----|   |-----| 
                   |     |            |     |
                   |-----|            |-----|
                   |glue |            |glue |
                   |-----|            |-----|
                   |     |            |     |
|-----|            |-----|            |-----|            |-----|
|ehost|<---------->|ehost|<---------->|ehost|<---------->|ehost|
|-----|            |-----|            |-----|            |-----|
 host                edge     hop      edge                host
           domain            domains             domain
                             (inter and
                              intra)
           NSIS                                   NSIS

Now what about "glue"? Shall NSIS do it? Part of me says yes, another says
no. I am 50/50.

--
Weijing Chen
SBC Technology Resources
9505 Arboretum Blvd.
Austin, TX 78759
512 372 5710
wchen@tri.sbc.com



-----Original Message-----
From: David Partain [mailto:David.Partain@ericsson.com] 
Sent: Wednesday, January 23, 2002 3:58 AM
To: NSIS Mailing List
Subject: [NSIS] Framework & requirements part of the "Two kinds of
requirements" thread

Greetings all,

I'd like to offer my take on part of the thread "Two kinds
of requirements" to see if we can collectively reach any sort
of conclusion based on what's been written.  I doubt I'll say
anything new, but perhaps it'll help summarize a bit.

To cut to the chase, the conclusion of this mail is that
I think:

 - we should use the "framework" below as the starting point of
   framework discussions
 - the requirements should grow from use cases of particular
   applications that will use the network

The original mail postulated that people are wanting to work
on two kinds of requirements here:

 - end-host to end-host, or application to application
   signalling

 - transport level signalling

From that point, there has been a hearty debate about whether
this indeed is true, as well as a host of other issues.

I think the following points have been made, amongst others:

 - It should support the use of throughput adaptive applications
   and the ability for a traffic flow to express its QoS
   preferences with regard to the throughput values which it
   may be allocated.

 - One part of the thread was about whether RSVP and related
   work (e.g., RFC 2998), or perhaps SDPng, are suitable
   solutions.  While it's obvious that we need to learn from
   and perhaps start from one of these efforts in working on
   NSIS, it also seems clear that we shouldn't start working
   on that until the requirements are done.

 - There's no chance we'll create a single one-size-fits-all
   application-related signalling protocol that will be used
   by everyone.  That seems very clear.

 - There's a need for something transport independent that can
   help signal QoS needs across multiple domains in order
   to help the application-related signalling protocols do
   their thing.

The big issue there is what part of this we should solve here.
Should we concentrate specifically on the application/host
to network signalling?  I think not and others have agreed.
Should we try to design something that goes end to end?  If we
do that, do we have a "chicken and egg" problem of needing to
have the technology everywhere for things to work?

A case has been made that the goal should be to create a
signalling protocol that has different kinds of components
appropriate to different parts of the problem.  Georgios K.
proposed the following figure, which I like quite a lot and
which others have said is good, as a way of looking at it:

|-----|                                                  |-----|
|ehost|<------------------------------------------------>|ehost|
|-----|                                                  |-----|
|     |                                                  |     |
|-----|            |-----|            |-----|            |-----|
|eedge|<---------->|eedge|<---------->|eedge|<---------->|eedge|
|-----|            |-----|            |-----|            |-----|
|     |            |     |            |     |            |     |
|-----|   |----|   |-----|   |----|   |-----|   |----|   |-----|
|ehop |<->|ehop|<->|ehop |<->|ehop|<->|ehop |<->|ehop|<->|ehop |
|-----|   |----|   |-----|   |----|   |-----|   |----|   |-----|
 host    interior   edge    interior   edge     interior  host
         w/in domain       w/in domain        w/in domain

   ehost = everyhost
   eedge = everyedge
   ehop  = everyhop

NSIS protocol decomposition:

 * A "host" could be an end host or a proxy.  It can process
   and use the "everyhost", "everyedge", and "everyhop"
   protocol components.

 * An "edge" can be a Diffserv edge, MPLS edge, etc.  It can
   process and use the "everyedge", and "everyhop" protocol
   components. The "everyhost" protocol component is not
   processed (used or checked) but is carried onward.

 * An "interior within domain" can be any router within
   a domain.  It can process and use only the "everyhop"
   protocol component.  The "everyhost" and "everyedge"
   protocol components are not processed (used or checked)
   but are carried onward.

The everyhop bit within a domain provides signalling facilities
for that particular domain and is very likely to differ from
the everyhop bit used in the next boarding domain.

The point of all of this is to get a concatenation of results.
Each domain is responsible for taking its own decisions in its
own domain-specific ways.  The concatenation of the everyhop
decisions within a domain provides the domain's answer.
The concatenation of the domains' results gives and end to
end answer that can be used by the everyhost bit.

I think that having this overall framework -- for lack of a
better term -- in mind is very helpful.

If we can agree that this is a reasonable framework to use as
the basis of discussion, I think that what we need to do is
to produce a set of requirements for different "applications"
that will use these networks/this framework.  Indeed, I believe
this matches Keith Allen's request that requirements be based on
use cases.  If we know we're going to use the NSIS protocol on
a cellular wireless network (just to pull an example out of the
air :-)), then that "use case" implies a set of requirements.
A different scenario (e.g., the core of the network) implies
another set of requirements.

I personally think this is the right way forward and would
like to see this group move in this direction.

Georgios added some more thoughts on this topic
which addressed the applicability and prioritization
of work.  That can be found in the archive at
http://www1.ietf.org/mail-archive/working-groups/nsis/current/msg00418.html

I realize that I haven't covered everyone's particular topic
in this thread, but perhaps it'll help focus on one part of
the discussion.  If someone wants to summarize some other
sub-thread, that would be great...

Cheers,

dlp

ps. I think it would be very useful if Subject lines could more
accurately reflect the topic covered in the mail.  Long threads
with the same subject and covering a multitude of topics is
difficult to follow...

_______________________________________________
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  Thu Jan 24 04:44: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 EAA18523
	for <nsis-archive@odin.ietf.org>; Thu, 24 Jan 2002 04:44:51 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id EAA20765
	for nsis-archive@odin.ietf.org; Thu, 24 Jan 2002 04:44: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 EAA20345;
	Thu, 24 Jan 2002 04:35: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 EAA20308
	for <nsis@optimus.ietf.org>; Thu, 24 Jan 2002 04:35:24 -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 EAA18306
	for <nsis@ietf.org>; Thu, 24 Jan 2002 04:35:20 -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 g0O9ZMIB007415
	for <nsis@ietf.org>; Thu, 24 Jan 2002 10:35:22 +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 <0GQF005LORYX85@mbb1.ericsson.se> for nsis@ietf.org; Thu,
 24 Jan 2002 10:35:22 +0100 (MET)
Date: Thu, 24 Jan 2002 10:35:50 +0100
From: David Partain <David.Partain@ericsson.com>
Subject: Re: [NSIS] Framework & requirements part of the
 "Two kinds of  requirements" thread
In-reply-to: <3C4F0560.20508@juniper.net>
To: NSIS Mailing List <nsis@ietf.org>
Reply-to: David.Partain@ericsson.com
Message-id: <0GQF005LPRYY85@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: <0GQD001M6YBEYP@mbb1.ericsson.se>
 <3C4EF853.B10F8796@ee.tu-berlin.de> <3C4F0560.20508@juniper.net>
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,

[Previous discussion clipped]

Ping Pan gave a very down-to-earth view of what we should be
doing.  Thank you.

> Before we define end-to-end, edge-to-edge and domain-to-domain, ask the
> following:
>
> - why do we signal in the first place?
> - where do we need to signal?
> - will signaling work in provider's networks?
>
> We signal because there is no QoS when we are using some inter-active
> real-time applications. Since most of the Internet traffic is not within
> the scope of this "inter-active" and "real-time", let's not consider a
> kitchen-sink signaling protocol.

If we try to throw every possible problem area into the NSIS
work, this working group will still be talking when we're rolling
out 8th generation mobile telephony :-)  We have to work very
hard at limiting the scope of what we are trying to do.  Yes,
everyone has their particular area of interest, and everyone's
not going to be happy (I may be one of them).  But we _must_
start by solving the most acute problems.  If we demonstrate
competence at doing that, maybe we can move onto other problems
later.

[clipped bit on adaptive applications]

> Currently, most of the backbone networks are over-provisioned, so no
> serious signaling is required yet. End-to-end signaling is very
> attractive to the end users, but the providers will not allow the users
> to tell the routers how much to reserve. In fact, I doubt the providers
> will listen to anything that end-user are throwing at them. So other
> than some end-to-end measurement-based approach, I don't see e2e
> signaling will fly in the present network.

"End-to-end signalling" doesn't necessarily imply that everyone
in the path has to care.  That's what I think is so important
about the framework picture that I sent out yesterday:  each
domain decides how it's going to provide (or not) the quality
of service being requested.  There are going to be those with
Big Fat Pipes who may _never_ introduce any kind QoS mechanisms
into their boxes.  Their domain-specific solution is
overprovisioning, which is cool.  If their customers/partners
agree to this (the business side of things), then we can still
provide "end-to-end" QoS.

You want to provide QoS differentiation with DiffServ?  Fine.
You want to do it with IntServ?  Fine.  You want to use traffic
engineering with MPLS?  Fine.  You want to use it with YAFQoSP
(yet another future QoS protocol)?  Fine.  Just give the "layer"
above the answer so that we can build an end-to-end answer.

There is no alternative, in my view, to having end-to-end QoS
as a product of the concatenation of domain-specific responses
to QoS requests.  We will never have homogeneity.  If we don't
create with this assumption in NSIS, I think we'll lose.

> The place where we need signaling is inside the access networks. This is
> the place where the providers have no incentive to over-provision (to
> flat-rate users? please), and this is the place where we may see
> resource shortage.

I certainly agree that this where I think the most acute
needs are.

> Finally, the providers are motivated by money to provide any additional
> service. Unless the traffic that they are carrying worth something, they
> will never deploy some extra "stuff" inside the network. So what's worth
> money? ....
>
> - voice traffic! I am not only talking about VoIP; I am talking all the
> voice traffic that use the Internet infrastructure.
>
> - wireless traffic: users packets are not landed inside the backbone, so
> the access network needs to do more to those flows.
>
> - VPN (an over-used term :-)): but some users want to have QoS
> reservation even though they are sending any traffic. Not for any
> technical reason, it's a business reason. Have you seen the amount of
> traffic in a SNA network, and how much they have been charged? :-)
>
> In conclusion, IMHO, NSIS should
>
> 1. focus on edge-to-edge signaling;
> 2. focus on a small set of applications to deal with;
> 3. focus on the relevant provider impact;
> 4. don't do a kitchen-sink blahblah that lasts for years.

Thank you for helping to keep us focused.  I might perhaps
put a heavier wireless emphasis on what you're saying, but I
completely agree with it.

> 3 cents,

2 eurocents.

Cheers,

dlp

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



From daemon@optimus.ietf.org  Thu Jan 24 09:24: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 JAA22112
	for <nsis-archive@odin.ietf.org>; Thu, 24 Jan 2002 09:24:20 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id JAA00073
	for nsis-archive@odin.ietf.org; Thu, 24 Jan 2002 09:24: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 JAA29445;
	Thu, 24 Jan 2002 09:13: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 JAA29373
	for <nsis@optimus.ietf.org>; Thu, 24 Jan 2002 09:13:14 -0500 (EST)
Received: from cbibipnt03.HC.BT.COM (saturn.bt.com [193.113.57.20])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21911
	for <nsis@ietf.org>; Thu, 24 Jan 2002 09:13:09 -0500 (EST)
From: dick.rr.knight@bt.com
Received: by cbibipnt03.hc.bt.com with Internet Mail Service (5.5.2652.35)
	id <DQ1XM717>; Thu, 24 Jan 2002 14:12:54 -0000
Message-ID: <451D45016C2CD2119DA50000F8FE7F07080E5A75@mlngcbnt01.hc.bt.com>
To: brian.williams@ericsson.com.au, schneider@tri.sbc.com
Cc: gkenward@nortelnetworks.com, rrroy@att.com, john.loughney@nokia.com,
        brunner@ccrle.nec.de, ykahana@comgates.co.il,
        Ruediger.Geib@t-systems.com, dick.rr.knight@bt.com, nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements
Date: Thu, 24 Jan 2002 14:11:55 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
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

Brian,
 No, sorry I don't agree.

We ought to stay closer to the user. NSIS should carry the requested (and
the negotiated) QoS. If we carry the actual QoS parameters specific to the
L2 mechanism, then we have only repeated the same information in different
envelopes.

Dick

-----Original Message-----
From: Brian Williams [mailto:brian.williams@ericsson.com.au]
Sent: 24 January 2002 09:20
To: Marco Schneider
Cc: Gary Kenward; Radhika Roy; john loughney; brunner@ccrle.nec.de;
Yaron Kahana; Ruediger Geib; Dick Knight; nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


Hi Marco.

On Thu, 2002-01-24 at 05:03, Schneider, Marco wrote:
> Brian,
> 
> Thanks for your discussion. So if I understand your comments correctly,
you
> are concerned with NSIS QOS mapping to layer 2 QOS. Is there any way in
> which these requirements would impact the actual signaling protocol?
The comments highlighting the different network architectures was of
course simply to identify that the solution must allow for different
layering of communication in different networks. This is only to ensure
that limited views of networks and QoS layering don't lead to solutions
only tailored to one type.

The other aspect which I think you are actually questioning is whether
the layer 2 QoS mechanism shall impact the signalling protocol. My
position here is the actual signalling mechanism should be independent
of the lower layers, but the data carried to express the traffic and QoS
requirements can vary. 
/brian

 
> Marco
> 
> -----Original Message-----
> From: Brian Williams [mailto:brian.williams@ericsson.com.au]
> Sent: Wednesday, January 23, 2002 4:32 AM
> To: Schneider, Marco
> Cc: 'Gary Kenward'; 'Roy, Radhika R, ALASO'; Loughney "John
> (NRC/Helsinki); brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
> dick.rr.knight@bt.com; nsis@ietf.org
> Subject: RE: [NSIS] Two kinds of requirements
> 
> 
> Hi Marco.
> On Wed, 2002-01-23 at 09:48, Schneider, Marco wrote:
> > Garry,
> >  
> > >From an architectural/software perspective there is a session layer
that
> > is logically built on top of the transport capability. From a protocol
> > stack perspective the session signaling is not layered on top of the
> > transport signaling in the framework I described. 
> >  
> > Aside: The following scenario is conceivable but not desireable.
> > Consider an ADSL customer that is logically connected to an edge router
> > via a DSLAM and an edge switch. Thus the layer 3 hop is realized by
> > multiple hops at layer 2. 
> A similar but slightly different situation exists also with cellular
> wireless networks. The layer 3 hop runs over one layer 2 hop, but this
> layer 2 hop is actually overlayed on top of multiple underlying layer 2
> hops. 
> 
> > Existing deployments that I am aware of use a
> > preprovisioned PVC for this. Now imagine that the customer does session
> > signaling resulting in NSIS signaling at layer 3. This could result in
> > the need for a new layer 2 connection because the existing PVC will not
> > do the job. 
> Certanly the case for cellular that a new lasyer 2 connection coule be
> required.
> 
> > Thus ATM UNI signaling might be initiated from the ADSL
> > Customer to allocate the resources for the layer 3 logical link. Yuck!
> > Obviously it is better to avoid this by pre-provisioning the access
> > network appropriately. Nevertheless, there may be other circumstances
> > where this type of situation will occur and one could imagine promoting
> > the layer 2 devices to be aware of NSIS so as to avoid multiple levels
> > of signaling. 
> For the cellular case, the end host is the device that sets up the layer
> 2 connection. This connection must use separate signalling to allow
> separate development of the layer 2 capabilities (ie dependent on
> cellular technology). The host though must be able to relate the QoS
> requirements signalled by NSIS to the layer 2 signalling. We are in the
> process of producing a draft to clarify these requirements based on
> typical layer 2 characteristics of cellular networks.
> /brian
>   
> > Marco
> >  
> > -----Original Message-----
> > From: Gary Kenward [mailto:gkenward@nortelnetworks.com]
> > Sent: Tuesday, January 22, 2002 3:34 PM
> > To: Schneider, Marco; 'Roy, Radhika R, ALASO'; Loughney John
> > (NRC/Helsinki); brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
> > dick.rr.knight@bt.com
> > Cc: nsis@ietf.org
> > Subject: RE: [NSIS] Two kinds of requirements
> > 
> > 
> > 
> > Marco:
> >  
> >    Good question: what do I mean by layering. I assume you are familiar
> > with protocol layers and their
> > properties. My major concern would be in the replication of information
> > exchanges at each layer, resulting
> > in greater overhead/delay. The end systems must to be involved in
> > establishing the necessary QoS, including
> > negotiation if viable, but the number of bits that are transported
> > through the network to set up this QoS
> > end to end must be kept to a minimum. Thus, I cringe at the possibility
> > of an end-to-end application exchange
> > triggering an RSVP request, triggering . . . in telephony terms, the
> > analogy is the call setup delay, which has
> > to be acceptable to the user, and, for wireless, has to be bandwidth
> > efficient.
> >  
> >   I hope I have explained my concern.
> >  
> > Cheers,
> > Gary
> >  
> >  
> > 
> > -----Original Message-----
> > From: Schneider, Marco [mailto:schneider@tri.sbc.com]
> > Sent: January 22, 2002 15:35
> > To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Roy, Radhika R, ALASO'; Loughney
> > John (NRC/Helsinki); brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
> > dick.rr.knight@bt.com
> > Cc: nsis@ietf.org
> > Subject: RE: [NSIS] Two kinds of requirements
> > 
> > 
> > Gary,
> > 
> > -----Original Message-----
> > From: Gary Kenward [mailto:gkenward@nortelnetworks.com]
> > Sent: Tuesday, January 22, 2002 9:02 AM
> > To: Schneider, Marco; 'Roy, Radhika R, ALASO'; Loughney John
> > (NRC/Helsinki); brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
> > dick.rr.knight@bt.com
> > Cc: nsis@ietf.org
> > Subject: RE: [NSIS] Two kinds of requirements
> > 
> > 
> > 
> > Marco: 
> > 
> > -----Original Message----- 
> > > [MS]  Yes, exactly. 
> > >   I don't believe you are proposing a "layering" of signalling
> > protocols, 
> > > one for session establishment, then one for transport, etc. 
> > > [MS]  This is exactly what has been proposed in RAP and SIP working
> > groups to the best 
> > > of my understanding. Because there does not exist a proxy signaling
> > capability that 
> > > allows a session to setup a connection on the users behalf, the
> > session forwards a 
> > > token to the end-system and then the end-system includes that token in
> > the RSVP path 
> > > message so that the reservation will go through. In this manner the
> > session layer does 
> > > not need to communicate directly with the transport layer. 
> > 
> > [gwk] I do not understand what "the session" represents in the above. It
> > would seem 
> > to me that you must have a session level entity, and that to "forward a
> > token to the 
> > end-system", it must have an interface/api to the "end-system". If this
> > "end-system" 
> > is including tokens in RSVP, then it is the entity setting up the
> > transport QoS (although 
> > it is not necessarly a transport layer entity, but rather a signalling
> > entity. If these 
> > two entites are co-located, then you do not have layered signalling
> > protocols. 
> > 
> > Have I missed something? 
> > 
> > [Schneider, Marco] I don't think you have missed anything. I may not
> > have understood what you meant by a layering of signaling protocols.
> > Please define this.
> > 
> > BTW: for many links, particularly wireless, layered signalling is not a
> > good idea. 
> > And, in general, layered signalling will always be slower then a single
> > signalling protocol. 
> > > So, the question, 
> > > becomes, how are the QoS transport mechanisms established? In the
> > internet 
> > > model there is only one end-to-end transport session (e.g. TCP, RTP,
> > UDP), 
> > > but underneath the transport is a series of inter-connected networks,
> > each 
> > > with potentially different characteristics. 
> > >   This is end-to-end QoS support structure has to be set up and
> > maintained 
> > > in order for the end to end session QoS to be realized. The solution
> > may be 
> > > a single protocol that travels from host to host, such as RSVP, or it
> > may 
> > > be a collection of protocols that are optimized for each portion of
> > the 
> > > end-to-end path: e.g. host to access network, access to core network, 
> > > core to core network, etc. 
> > >   It is too early to determine which approach is best, but in either
> > case, 
> > > do we not need to understand the end-to-end requirements for this
> > signalling 
> > > capability? 
> > > [MS]  So by end-to-end you are referring to both the end-systems and
> > the devices in 
> > > between. As a point of clarification, I asked Roy what he meant by
> > "End-to-End 
> > > Application Layer QOS Signaling" and his answer implied user
> > (end-system) to user (end- 
> > > system).  We have been using the term end-to-end in different ways
> > (contexts). The way 
> > > I normally use the term "end-to-end" is to include everything in
> > between (all the 
> > > hops). 
> > 
> > [gwk] I see the difference. I would say that I tend towards your
> > definition, in the 
> > following sense: the only QoS that matters is what the end-user sees, so
> > as a service 
> > characteristic, it must be provided between the two end systems / hosts.
> > In order to do 
> > this, however, some level of support is required at each hop along the
> > path. 
> > For me the term end-to-end (for example end-to-end call flow) includes
> > the components within the network that must come together to make it
> > work. The term end-to-end application level signaling seems like an
> > oxymoron since this signaling occurs with no involvement of the network
> > except to transfer the data packets but perhaps there is something I am
> > missing. 
> > 
> >  So, establishing QoS between the end systems requires a peer-to-peer
> > agreement between 
> > the end systems, a host-to-cloud agreement for the transport of the
> > packets, and 
> > some mechanism within the cloud to ensure that the agreed upon QoS is
> > provided. 
> > Depending upon the complexity of the cloud, the latter could imply all
> > sorts of QoS 
> > agreements between networks and even nodes, for packet forwarding. 
> > 
> >   Note that I have purposely NOT stated that any of these agreements are
> > negotiated or 
> > require a signalling protocol. My opinion is that it is better in the
> > long term to 
> > support negotiated services using signalling, as it provides more
> > flexibility. However, 
> > this can be overdone, say, as a silly example, by having the end-system
> > negotiate with 
> > every node in the network. So, the compromise is that some of the QoS
> > agreements will 
> > be incorporated into the network design (e.g. Diff Serv), some will be
> > configured by 
> > the operator(s) (e.g. through traffic engineering and policy
> > management), and others 
> > will be signalled. NSIS seems to be about determining where signalling
> > is appropriate, 
> > and what are the signalling peers, and what is the best protocol
> > solution or solutions. 
> > The catch is that the first two approaches actually encompass a wide
> > variety of technologies 
> > and scenarios. 
> > [Schneider, Marco]  I think you have articulated this very well and I am
> > in general agreement. 
> > 
> >   Sorry for stating the obvious. There is clearly some concern over the
> > use, for example, 
> > of RSVP, and I suspect that some people are concerned that "end-to-end
> > signalling" also 
> > means "hop-by-hop" ala RSVP. It could, but it does not have to. 
> > [Schneider, Marco] I think this is a very important distinction. I think
> > that the reverse is true as well in that some people are assuming a hop
> > by hop linear signaling model wherein the signaling takes place in order
> > along the path that the data will follow. The transport signaling that
> > is going to occur within the core of our network will be at a different
> > timescale than UNI signaling and there are a variety of solutions for
> > this including RSVP-te and CR-LDP which were developed for the purpose
> > of allocating traffic trunks.
> > 
> >   So, my view is that NSIS needs to ensure that the end-to-end QoS is
> > provided for, and 
> > develope the protocols where they are needed (but not where they are
> > not). At this point, 
> > that would seem to be host to edge, edge to edge, and at the very least,
> > with enough 
> > end to end semantics to ensure that the complete path supports QoS. I am
> > concerned about 
> > node to node signalling, as there are so many different approaches to
> > supporting node-to-node 
> > QoS. At the very least, I would like to see a framework, and the edge
> > solutions defined 
> > before we delve into "intra-network" issues. 
> > [Schneider, Marco] I think it all begins with the fact that a user must
> > be able to request a QOS/COS connection/flow to another user. If we
> > can't do that then everything else would appear to be pointless. The
> > next question is whether we want to develop protocols that assist the
> > network portion in delivering this capability and in what context(s).
> > 
> > 
> > BTW: in writing this, it dawned upon me that it might be best to write a
> > series of 
> > requirements rather then just one - i.e. tackle the problem piece by
> > piece. This approach 
> > does have drawbacks, but working groups seem to work better when they
> > focus on contained 
> > problem domains. A strawman framework might be useful in keeping the
> > incremental solutions 
> > coherent. 
> > [Schneider, Marco] I agree with the idea of tackling the requirements by
> > breaking the problem up. There is a catch 22 in that in order to breakup
> > it up we must to some degree presuppose a solution. 
> > 
> > 
> > > [MS] I think our basic requirement is that an end-system be able to
> > request (and 
> > > receive) a QOS connection to some other end-system (NSIS UNI). The
> > request part entails 
> > > an NSIS UNI. As you say the realization of this request can be
> > achieved in a number of 
> > > different ways. Now one solution is to invent an NSIS NNI that runs
> > between domains. If 
> > > we develop requirements for such an NSIS UNI then we have already
> > preproposed a 
> > > solution ahead of requirements. 
> > 
> > [gwk] We have to be extremely careful not to become pre-occupied with
> > requirements 
> > definition. All productive requirements definition efforts begin with
> > assumptions 
> > concerning the solution. In my view, requirements specifications are a
> > balance between 
> > presumption and prediction, particularly when dealing with "soft"
> > techologies such as 
> > protocols. The issue really is not whether a requirement is a "MAY" or a
> > "SHOULD" or 
> > whatever, the issue is whether a requirement actually helps us define
> > the solution 
> > (there are lot's of examples of "SHOULD" requirements that do not bring
> > value to the 
> > design process). 
> > [Schneider, Marco] I think there is a danger in implicit assumptions
> > that may not lead to the best solution. With respect to network support
> > of a QOS request, there are many different solutions and I am afraid
> > that some participants have presupposed a hop by hop signaling solution.
> > 
> > 
> > Given my observation above about writing a series of requirements, I
> > would recommend 
> > that we roughly map out the solution(some would call this a
> > "framework"). This map would 
> > form the preliminary list of deliverables for the wg charter, and then
> > pick a focussed 
> > problem area to begin with requirements. This is not "top down" design,
> > but "top down" 
> > processes seldom work. If this seems too abstract, what I am saying is
> > that I have no 
> > problem identifying that there are N problem areas to be addressed -
> > e.g. host to edge, 
> > edge to edge, node to node, etc. - and picking anyone for the first
> > design attempt. Of 
> > course, the challenge would be to keep an eye on the "big picture" or
> > end-to-end 
> > requirements in the process. 
> > [Schneider, Marco] I think that the network context for supporting NSIS
> > UNI is a quagmire, albeit a very fun one. The problems we need to
> > address depend upon what end-to-end architectures we wish to support.
> > There are a number of capabilities already being developed for network
> > QOS and there may be a number of ways to "glue" these together.
> > 
> > Deludedly yours,
> > 
> > Marco
> > 
> > Just my deluded point of view. 
> > Cheers, 
> > Gary 
> > 
> > [Schneider, Marco]  
> > *snip* 
> > 
> 
> 
> 
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis
> 
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis


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



From daemon@ns.ietf.org  Thu Jan 24 11:15:11 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25481
	for <nsis-archive@odin.ietf.org>; Thu, 24 Jan 2002 11:15:10 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id LAA05351
	for nsis-archive@odin.ietf.org; Thu, 24 Jan 2002 11:15: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 LAA04961;
	Thu, 24 Jan 2002 11:02:12 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA04932
	for <nsis@ns.ietf.org>; Thu, 24 Jan 2002 11:02:10 -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 LAA24857
	for <nsis@ietf.org>; Thu, 24 Jan 2002 11:02:06 -0500 (EST)
Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56])
	by zcars0m9.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g0OG1cc25034;
	Thu, 24 Jan 2002 11:01:38 -0500 (EST)
Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7])
	by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g0OG1a520468;
	Thu, 24 Jan 2002 11:01:36 -0500 (EST)
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19)
	id <C8PZ54M3>; Thu, 24 Jan 2002 11:01:38 -0500
Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA47B0@zcard031.ca.nortel.com>
From: "Gary Kenward"<gkenward@nortelnetworks.com>
To: "'David.Partain@ericsson.com'" <David.Partain@ericsson.com>,
        NSIS Mailing List <nsis@ietf.org>
Subject: RE: [NSIS] Framework & requirements part of the "Two kinds of  re
	quirements" thread
Date: Thu, 24 Jan 2002 11:01:38 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C1A4F0.67FB8E10"
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_01C1A4F0.67FB8E10
Content-Type: text/plain;
	charset="ISO-8859-1"

I don't believe that anyone has proposed "kitchen sink" or
signalling that is not needed. I believe that there are a number
of very important problem areas that need to be addressed. At the
moment, the prevalent thread is whether all or many of these signalling
needs can be resolved with one protocol. There is a great risk in
attacking the problem in a piecemeal fashion: the result may not hold
solve enough of the problem to be useful.

Some specific comments:

  - if there is a need for a protocol to run end-to-end at the application
    layer without interacting with the network, then this can be resolved 
    in two ways: a separate protocol that is designed *only* for this 
    purpose; a protocol that can interact with a network, if the network
    is able and willing (i.e. has the functional and policy support).
 
    the first solution fulfils only one of the needs stated so far on this
    list, and implies a requirement for multiple signalling protocols to 
    set up the end to end *and* network QoS; on the plus side, it is a 
    self contained problem (by definition), independent upon network 
    architecture.

    the second solution is tougher because it requires a definition of
    a generic framework that will allow interaction between the end-to-
    end and entities within the network; on the plus side, it is likely 
    to be more efficient then the first solution.

  - implicit in Ping Pan's proposal is the idea that a useful signalling
    protocol will emerge out of the sequential development of hop-by-hop
    signalling (i.e. host to edge, node to node, edge to edge, etc.); this
    is somewhat like trying to build a jet engine one piece at a time, it
    will not work unless you have an idea where the pieces fit ahead of
time.

  - while I'm not entirely sure what Ping Pan means by an "application"
    (i.e. a usage scenario coupled with network services, a piece of
software)
    basing the design on a subset of applications may be the fastest way
    of generating a solution, but no likely the most useful in the long
term.

 
Finally, I support the idea of tackling a specific problem are first: my
preference being host to edge, but I strongly recommend that we make an
attempt
to define a strawman framework first. I emphasize "strawman" - the term
implies
that the framework will be evolve significantly.

I do not support the idea of using a subset of applications to design a
protocol.
I like the idea of using use cases, as long as they are acceptable to the
IESG,
and as long as they go beyond "user/end system interaction". 

Gary K.

> -----Original Message-----
> From: David Partain [mailto:David.Partain@ericsson.com]
> Sent: January 24, 2002 04:36
> To: NSIS Mailing List
> Subject: Re: [NSIS] Framework & requirements part of the "Two kinds of
> requirements" thread
> 
> 
> Hi all,
> 
> [Previous discussion clipped]
> 
> Ping Pan gave a very down-to-earth view of what we should be
> doing.  Thank you.
> 
> > Before we define end-to-end, edge-to-edge and 
> domain-to-domain, ask the
> > following:
> >
> > - why do we signal in the first place?
> > - where do we need to signal?
> > - will signaling work in provider's networks?
> >
> > We signal because there is no QoS when we are using some 
> inter-active
> > real-time applications. Since most of the Internet traffic 
> is not within
> > the scope of this "inter-active" and "real-time", let's not 
> consider a
> > kitchen-sink signaling protocol.
> 
> If we try to throw every possible problem area into the NSIS
> work, this working group will still be talking when we're rolling
> out 8th generation mobile telephony :-)  We have to work very
> hard at limiting the scope of what we are trying to do.  Yes,
> everyone has their particular area of interest, and everyone's
> not going to be happy (I may be one of them).  But we _must_
> start by solving the most acute problems.  If we demonstrate
> competence at doing that, maybe we can move onto other problems
> later.
> 
> [clipped bit on adaptive applications]
> 
> > Currently, most of the backbone networks are over-provisioned, so no
> > serious signaling is required yet. End-to-end signaling is very
> > attractive to the end users, but the providers will not 
> allow the users
> > to tell the routers how much to reserve. In fact, I doubt 
> the providers
> > will listen to anything that end-user are throwing at them. So other
> > than some end-to-end measurement-based approach, I don't see e2e
> > signaling will fly in the present network.
> 
> "End-to-end signalling" doesn't necessarily imply that everyone
> in the path has to care.  That's what I think is so important
> about the framework picture that I sent out yesterday:  each
> domain decides how it's going to provide (or not) the quality
> of service being requested.  There are going to be those with
> Big Fat Pipes who may _never_ introduce any kind QoS mechanisms
> into their boxes.  Their domain-specific solution is
> overprovisioning, which is cool.  If their customers/partners
> agree to this (the business side of things), then we can still
> provide "end-to-end" QoS.
> 
> You want to provide QoS differentiation with DiffServ?  Fine.
> You want to do it with IntServ?  Fine.  You want to use traffic
> engineering with MPLS?  Fine.  You want to use it with YAFQoSP
> (yet another future QoS protocol)?  Fine.  Just give the "layer"
> above the answer so that we can build an end-to-end answer.
> 
> There is no alternative, in my view, to having end-to-end QoS
> as a product of the concatenation of domain-specific responses
> to QoS requests.  We will never have homogeneity.  If we don't
> create with this assumption in NSIS, I think we'll lose.
> 
> > The place where we need signaling is inside the access 
> networks. This is
> > the place where the providers have no incentive to 
> over-provision (to
> > flat-rate users? please), and this is the place where we may see
> > resource shortage.
> 
> I certainly agree that this where I think the most acute
> needs are.
> 
> > Finally, the providers are motivated by money to provide 
> any additional
> > service. Unless the traffic that they are carrying worth 
> something, they
> > will never deploy some extra "stuff" inside the network. So 
> what's worth
> > money? ....
> >
> > - voice traffic! I am not only talking about VoIP; I am 
> talking all the
> > voice traffic that use the Internet infrastructure.
> >
> > - wireless traffic: users packets are not landed inside the 
> backbone, so
> > the access network needs to do more to those flows.
> >
> > - VPN (an over-used term :-)): but some users want to have QoS
> > reservation even though they are sending any traffic. Not for any
> > technical reason, it's a business reason. Have you seen the 
> amount of
> > traffic in a SNA network, and how much they have been charged? :-)
> >
> > In conclusion, IMHO, NSIS should
> >
> > 1. focus on edge-to-edge signaling;
> > 2. focus on a small set of applications to deal with;
> > 3. focus on the relevant provider impact;
> > 4. don't do a kitchen-sink blahblah that lasts for years.
> 
> Thank you for helping to keep us focused.  I might perhaps
> put a heavier wireless emphasis on what you're saying, but I
> completely agree with it.
> 
> > 3 cents,
> 
> 2 eurocents.
> 
> Cheers,
> 
> dlp
> 
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis
> 

------_=_NextPart_001_01C1A4F0.67FB8E10
Content-Type: text/html;
	charset="ISO-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2654.89">
<TITLE>RE: [NSIS] Framework &amp; requirements part of the &quot;Two kinds of  requirements&quot; thread</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>I don't believe that anyone has proposed &quot;kitchen sink&quot; or</FONT>
<BR><FONT SIZE=2>signalling that is not needed. I believe that there are a number</FONT>
<BR><FONT SIZE=2>of very important problem areas that need to be addressed. At the</FONT>
<BR><FONT SIZE=2>moment, the prevalent thread is whether all or many of these signalling</FONT>
<BR><FONT SIZE=2>needs can be resolved with one protocol. There is a great risk in</FONT>
<BR><FONT SIZE=2>attacking the problem in a piecemeal fashion: the result may not hold</FONT>
<BR><FONT SIZE=2>solve enough of the problem to be useful.</FONT>
</P>

<P><FONT SIZE=2>Some specific comments:</FONT>
</P>

<P><FONT SIZE=2>&nbsp; - if there is a need for a protocol to run end-to-end at the application</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp; layer without interacting with the network, then this can be resolved </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp; in two ways: a separate protocol that is designed *only* for this </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp; purpose; a protocol that can interact with a network, if the network</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp; is able and willing (i.e. has the functional and policy support).</FONT>
<BR><FONT SIZE=2>&nbsp;</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp; the first solution fulfils only one of the needs stated so far on this</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp; list, and implies a requirement for multiple signalling protocols to </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp; set up the end to end *and* network QoS; on the plus side, it is a </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp; self contained problem (by definition), independent upon network </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp; architecture.</FONT>
</P>

<P><FONT SIZE=2>&nbsp;&nbsp;&nbsp; the second solution is tougher because it requires a definition of</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp; a generic framework that will allow interaction between the end-to-</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp; end and entities within the network; on the plus side, it is likely </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp; to be more efficient then the first solution.</FONT>
</P>

<P><FONT SIZE=2>&nbsp; - implicit in Ping Pan's proposal is the idea that a useful signalling</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp; protocol will emerge out of the sequential development of hop-by-hop</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp; signalling (i.e. host to edge, node to node, edge to edge, etc.); this</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp; is somewhat like trying to build a jet engine one piece at a time, it</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp; will not work unless you have an idea where the pieces fit ahead of time.</FONT>
</P>

<P><FONT SIZE=2>&nbsp; - while I'm not entirely sure what Ping Pan means by an &quot;application&quot;</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp; (i.e. a usage scenario coupled with network services, a piece of software)</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp; basing the design on a subset of applications may be the fastest way</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp; of generating a solution, but no likely the most useful in the long term.</FONT>
</P>

<P><FONT SIZE=2>&nbsp;</FONT>
<BR><FONT SIZE=2>Finally, I support the idea of tackling a specific problem are first: my</FONT>
<BR><FONT SIZE=2>preference being host to edge, but I strongly recommend that we make an attempt</FONT>
<BR><FONT SIZE=2>to define a strawman framework first. I emphasize &quot;strawman&quot; - the term implies</FONT>
<BR><FONT SIZE=2>that the framework will be evolve significantly.</FONT>
</P>

<P><FONT SIZE=2>I do not support the idea of using a subset of applications to design a protocol.</FONT>
<BR><FONT SIZE=2>I like the idea of using use cases, as long as they are acceptable to the IESG,</FONT>
<BR><FONT SIZE=2>and as long as they go beyond &quot;user/end system interaction&quot;. </FONT>
</P>

<P><FONT SIZE=2>Gary K.</FONT>
</P>

<P><FONT SIZE=2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; From: David Partain [<A HREF="mailto:David.Partain@ericsson.com">mailto:David.Partain@ericsson.com</A>]</FONT>
<BR><FONT SIZE=2>&gt; Sent: January 24, 2002 04:36</FONT>
<BR><FONT SIZE=2>&gt; To: NSIS Mailing List</FONT>
<BR><FONT SIZE=2>&gt; Subject: Re: [NSIS] Framework &amp; requirements part of the &quot;Two kinds of</FONT>
<BR><FONT SIZE=2>&gt; requirements&quot; thread</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Hi all,</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; [Previous discussion clipped]</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Ping Pan gave a very down-to-earth view of what we should be</FONT>
<BR><FONT SIZE=2>&gt; doing.&nbsp; Thank you.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; Before we define end-to-end, edge-to-edge and </FONT>
<BR><FONT SIZE=2>&gt; domain-to-domain, ask the</FONT>
<BR><FONT SIZE=2>&gt; &gt; following:</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; - why do we signal in the first place?</FONT>
<BR><FONT SIZE=2>&gt; &gt; - where do we need to signal?</FONT>
<BR><FONT SIZE=2>&gt; &gt; - will signaling work in provider's networks?</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; We signal because there is no QoS when we are using some </FONT>
<BR><FONT SIZE=2>&gt; inter-active</FONT>
<BR><FONT SIZE=2>&gt; &gt; real-time applications. Since most of the Internet traffic </FONT>
<BR><FONT SIZE=2>&gt; is not within</FONT>
<BR><FONT SIZE=2>&gt; &gt; the scope of this &quot;inter-active&quot; and &quot;real-time&quot;, let's not </FONT>
<BR><FONT SIZE=2>&gt; consider a</FONT>
<BR><FONT SIZE=2>&gt; &gt; kitchen-sink signaling protocol.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; If we try to throw every possible problem area into the NSIS</FONT>
<BR><FONT SIZE=2>&gt; work, this working group will still be talking when we're rolling</FONT>
<BR><FONT SIZE=2>&gt; out 8th generation mobile telephony :-)&nbsp; We have to work very</FONT>
<BR><FONT SIZE=2>&gt; hard at limiting the scope of what we are trying to do.&nbsp; Yes,</FONT>
<BR><FONT SIZE=2>&gt; everyone has their particular area of interest, and everyone's</FONT>
<BR><FONT SIZE=2>&gt; not going to be happy (I may be one of them).&nbsp; But we _must_</FONT>
<BR><FONT SIZE=2>&gt; start by solving the most acute problems.&nbsp; If we demonstrate</FONT>
<BR><FONT SIZE=2>&gt; competence at doing that, maybe we can move onto other problems</FONT>
<BR><FONT SIZE=2>&gt; later.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; [clipped bit on adaptive applications]</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; Currently, most of the backbone networks are over-provisioned, so no</FONT>
<BR><FONT SIZE=2>&gt; &gt; serious signaling is required yet. End-to-end signaling is very</FONT>
<BR><FONT SIZE=2>&gt; &gt; attractive to the end users, but the providers will not </FONT>
<BR><FONT SIZE=2>&gt; allow the users</FONT>
<BR><FONT SIZE=2>&gt; &gt; to tell the routers how much to reserve. In fact, I doubt </FONT>
<BR><FONT SIZE=2>&gt; the providers</FONT>
<BR><FONT SIZE=2>&gt; &gt; will listen to anything that end-user are throwing at them. So other</FONT>
<BR><FONT SIZE=2>&gt; &gt; than some end-to-end measurement-based approach, I don't see e2e</FONT>
<BR><FONT SIZE=2>&gt; &gt; signaling will fly in the present network.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &quot;End-to-end signalling&quot; doesn't necessarily imply that everyone</FONT>
<BR><FONT SIZE=2>&gt; in the path has to care.&nbsp; That's what I think is so important</FONT>
<BR><FONT SIZE=2>&gt; about the framework picture that I sent out yesterday:&nbsp; each</FONT>
<BR><FONT SIZE=2>&gt; domain decides how it's going to provide (or not) the quality</FONT>
<BR><FONT SIZE=2>&gt; of service being requested.&nbsp; There are going to be those with</FONT>
<BR><FONT SIZE=2>&gt; Big Fat Pipes who may _never_ introduce any kind QoS mechanisms</FONT>
<BR><FONT SIZE=2>&gt; into their boxes.&nbsp; Their domain-specific solution is</FONT>
<BR><FONT SIZE=2>&gt; overprovisioning, which is cool.&nbsp; If their customers/partners</FONT>
<BR><FONT SIZE=2>&gt; agree to this (the business side of things), then we can still</FONT>
<BR><FONT SIZE=2>&gt; provide &quot;end-to-end&quot; QoS.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; You want to provide QoS differentiation with DiffServ?&nbsp; Fine.</FONT>
<BR><FONT SIZE=2>&gt; You want to do it with IntServ?&nbsp; Fine.&nbsp; You want to use traffic</FONT>
<BR><FONT SIZE=2>&gt; engineering with MPLS?&nbsp; Fine.&nbsp; You want to use it with YAFQoSP</FONT>
<BR><FONT SIZE=2>&gt; (yet another future QoS protocol)?&nbsp; Fine.&nbsp; Just give the &quot;layer&quot;</FONT>
<BR><FONT SIZE=2>&gt; above the answer so that we can build an end-to-end answer.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; There is no alternative, in my view, to having end-to-end QoS</FONT>
<BR><FONT SIZE=2>&gt; as a product of the concatenation of domain-specific responses</FONT>
<BR><FONT SIZE=2>&gt; to QoS requests.&nbsp; We will never have homogeneity.&nbsp; If we don't</FONT>
<BR><FONT SIZE=2>&gt; create with this assumption in NSIS, I think we'll lose.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; The place where we need signaling is inside the access </FONT>
<BR><FONT SIZE=2>&gt; networks. This is</FONT>
<BR><FONT SIZE=2>&gt; &gt; the place where the providers have no incentive to </FONT>
<BR><FONT SIZE=2>&gt; over-provision (to</FONT>
<BR><FONT SIZE=2>&gt; &gt; flat-rate users? please), and this is the place where we may see</FONT>
<BR><FONT SIZE=2>&gt; &gt; resource shortage.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; I certainly agree that this where I think the most acute</FONT>
<BR><FONT SIZE=2>&gt; needs are.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; Finally, the providers are motivated by money to provide </FONT>
<BR><FONT SIZE=2>&gt; any additional</FONT>
<BR><FONT SIZE=2>&gt; &gt; service. Unless the traffic that they are carrying worth </FONT>
<BR><FONT SIZE=2>&gt; something, they</FONT>
<BR><FONT SIZE=2>&gt; &gt; will never deploy some extra &quot;stuff&quot; inside the network. So </FONT>
<BR><FONT SIZE=2>&gt; what's worth</FONT>
<BR><FONT SIZE=2>&gt; &gt; money? ....</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; - voice traffic! I am not only talking about VoIP; I am </FONT>
<BR><FONT SIZE=2>&gt; talking all the</FONT>
<BR><FONT SIZE=2>&gt; &gt; voice traffic that use the Internet infrastructure.</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; - wireless traffic: users packets are not landed inside the </FONT>
<BR><FONT SIZE=2>&gt; backbone, so</FONT>
<BR><FONT SIZE=2>&gt; &gt; the access network needs to do more to those flows.</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; - VPN (an over-used term :-)): but some users want to have QoS</FONT>
<BR><FONT SIZE=2>&gt; &gt; reservation even though they are sending any traffic. Not for any</FONT>
<BR><FONT SIZE=2>&gt; &gt; technical reason, it's a business reason. Have you seen the </FONT>
<BR><FONT SIZE=2>&gt; amount of</FONT>
<BR><FONT SIZE=2>&gt; &gt; traffic in a SNA network, and how much they have been charged? :-)</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; In conclusion, IMHO, NSIS should</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; 1. focus on edge-to-edge signaling;</FONT>
<BR><FONT SIZE=2>&gt; &gt; 2. focus on a small set of applications to deal with;</FONT>
<BR><FONT SIZE=2>&gt; &gt; 3. focus on the relevant provider impact;</FONT>
<BR><FONT SIZE=2>&gt; &gt; 4. don't do a kitchen-sink blahblah that lasts for years.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Thank you for helping to keep us focused.&nbsp; I might perhaps</FONT>
<BR><FONT SIZE=2>&gt; put a heavier wireless emphasis on what you're saying, but I</FONT>
<BR><FONT SIZE=2>&gt; completely agree with it.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; 3 cents,</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; 2 eurocents.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Cheers,</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; dlp</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; _______________________________________________</FONT>
<BR><FONT SIZE=2>&gt; nsis mailing list</FONT>
<BR><FONT SIZE=2>&gt; nsis@ietf.org</FONT>
<BR><FONT SIZE=2>&gt; <A HREF="https://www1.ietf.org/mailman/listinfo/nsis" TARGET="_blank">https://www1.ietf.org/mailman/listinfo/nsis</A></FONT>
<BR><FONT SIZE=2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1A4F0.67FB8E10--

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



From daemon@ns.ietf.org  Thu Jan 24 11:27: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 LAA25956
	for <nsis-archive@odin.ietf.org>; Thu, 24 Jan 2002 11:26:58 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id LAA05869
	for nsis-archive@odin.ietf.org; Thu, 24 Jan 2002 11:27: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 LAA05523;
	Thu, 24 Jan 2002 11:17: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 LAA05464
	for <nsis@ns.ietf.org>; Thu, 24 Jan 2002 11:17:42 -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 LAA25578
	for <nsis@ietf.org>; Thu, 24 Jan 2002 11:17:39 -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 g0OGHAc05965;
	Thu, 24 Jan 2002 11:17:10 -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 g0OGH9t06819;
	Thu, 24 Jan 2002 11:17:09 -0500 (EST)
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19)
	id <C8PZ5WFF>; Thu, 24 Jan 2002 11:17:10 -0500
Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA47B2@zcard031.ca.nortel.com>
From: "Gary Kenward"<gkenward@nortelnetworks.com>
To: "'David.Partain@ericsson.com'" <David.Partain@ericsson.com>,
        "'NSIS Mailing List'" <nsis@ietf.org>
Subject: RE: [NSIS] Framework & requirements part of the "Two kinds of  re
	quirements" thread
Date: Thu, 24 Jan 2002 11:17:09 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C1A4F2.92F9F460"
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_01C1A4F2.92F9F460
Content-Type: text/plain;
	charset="ISO-8859-1"

I don't believe that anyone has proposed "kitchen sink" or
signalling that is not needed. I believe that there are a number
of very important problem areas that need to be addressed. At the
moment, the prevalent thread is whether all or many of these signalling
needs can be resolved with one protocol. There is a great risk in
attacking the problem in a piecemeal fashion: the result may not hold
solve enough of the problem to be useful.

Some specific comments:

  - if there is a need for a protocol to run end-to-end at the application
    layer without interacting with the network, then this can be resolved 
    in two ways: a separate protocol that is designed *only* for this 
    purpose; a protocol that can interact with a network, if the network
    is able and willing (i.e. has the functional and policy support).
 
    the first solution fulfils only one of the needs stated so far on this
    list, and implies a requirement for multiple signalling protocols to 
    set up the end to end *and* network QoS; on the plus side, it is a 
    self contained problem (by definition), independent upon network 
    architecture.

    the second solution is tougher because it requires a definition of
    a generic framework that will allow interaction between the end-to-
    end and entities within the network; on the plus side, it is likely 
    to be more efficient then the first solution.

  - implicit in Ping Pan's proposal is the idea that a useful signalling
    protocol will emerge out of the sequential development of hop-by-hop
    signalling (i.e. host to edge, node to node, edge to edge, etc.); this
    is somewhat like trying to build a jet engine one piece at a time, it
    will not work unless you have an idea where the pieces fit ahead of
time.

  - while I'm not entirely sure what Ping Pan means by an "application"
    (i.e. a usage scenario coupled with network services, a piece of
software)
    basing the design on a subset of applications may be the fastest way
    of generating a solution, but no likely the most useful in the long
term.

 
Finally, I support the idea of tackling a specific problem are first: my
preference being host to edge, but I strongly recommend that we make an
attempt
to define a strawman framework first. I emphasize "strawman" - the term
implies
that the framework will be evolve significantly.

I do not support the idea of using a subset of applications to design a
protocol.
I like the idea of using use cases, as long as they are acceptable to the
IESG,
and as long as they go beyond "user/end system interaction". 

Gary K.

> -----Original Message-----
> From: David Partain [mailto:David.Partain@ericsson.com]
> Sent: January 24, 2002 04:36
> To: NSIS Mailing List
> Subject: Re: [NSIS] Framework & requirements part of the "Two kinds of
> requirements" thread
> 
> 
> Hi all,
> 
> [Previous discussion clipped]
> 
> Ping Pan gave a very down-to-earth view of what we should be
> doing.  Thank you.
> 

*snip*

> > In conclusion, IMHO, NSIS should
> >
> > 1. focus on edge-to-edge signaling;
> > 2. focus on a small set of applications to deal with;
> > 3. focus on the relevant provider impact;
> > 4. don't do a kitchen-sink blahblah that lasts for years.
> 
> Thank you for helping to keep us focused.  I might perhaps
> put a heavier wireless emphasis on what you're saying, but I
> completely agree with it.
> 
> > 3 cents,
> 
> 2 eurocents.
> 
> Cheers,
> 
> dlp
> 
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis
> 

------_=_NextPart_001_01C1A4F2.92F9F460
Content-Type: text/html;
	charset="ISO-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2654.89">
<TITLE>RE: [NSIS] Framework &amp; requirements part of the &quot;Two kinds of  requirements&quot; thread</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>I don't believe that anyone has proposed &quot;kitchen sink&quot; or</FONT>
<BR><FONT SIZE=2>signalling that is not needed. I believe that there are a number</FONT>
<BR><FONT SIZE=2>of very important problem areas that need to be addressed. At the</FONT>
<BR><FONT SIZE=2>moment, the prevalent thread is whether all or many of these signalling</FONT>
<BR><FONT SIZE=2>needs can be resolved with one protocol. There is a great risk in</FONT>
<BR><FONT SIZE=2>attacking the problem in a piecemeal fashion: the result may not hold</FONT>
<BR><FONT SIZE=2>solve enough of the problem to be useful.</FONT>
</P>

<P><FONT SIZE=2>Some specific comments:</FONT>
</P>

<P><FONT SIZE=2>&nbsp; - if there is a need for a protocol to run end-to-end at the application</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp; layer without interacting with the network, then this can be resolved </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp; in two ways: a separate protocol that is designed *only* for this </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp; purpose; a protocol that can interact with a network, if the network</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp; is able and willing (i.e. has the functional and policy support).</FONT>
<BR><FONT SIZE=2>&nbsp;</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp; the first solution fulfils only one of the needs stated so far on this</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp; list, and implies a requirement for multiple signalling protocols to </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp; set up the end to end *and* network QoS; on the plus side, it is a </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp; self contained problem (by definition), independent upon network </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp; architecture.</FONT>
</P>

<P><FONT SIZE=2>&nbsp;&nbsp;&nbsp; the second solution is tougher because it requires a definition of</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp; a generic framework that will allow interaction between the end-to-</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp; end and entities within the network; on the plus side, it is likely </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp; to be more efficient then the first solution.</FONT>
</P>

<P><FONT SIZE=2>&nbsp; - implicit in Ping Pan's proposal is the idea that a useful signalling</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp; protocol will emerge out of the sequential development of hop-by-hop</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp; signalling (i.e. host to edge, node to node, edge to edge, etc.); this</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp; is somewhat like trying to build a jet engine one piece at a time, it</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp; will not work unless you have an idea where the pieces fit ahead of time.</FONT>
</P>

<P><FONT SIZE=2>&nbsp; - while I'm not entirely sure what Ping Pan means by an &quot;application&quot;</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp; (i.e. a usage scenario coupled with network services, a piece of software)</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp; basing the design on a subset of applications may be the fastest way</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp; of generating a solution, but no likely the most useful in the long term.</FONT>
</P>

<P><FONT SIZE=2>&nbsp;</FONT>
<BR><FONT SIZE=2>Finally, I support the idea of tackling a specific problem are first: my</FONT>
<BR><FONT SIZE=2>preference being host to edge, but I strongly recommend that we make an attempt</FONT>
<BR><FONT SIZE=2>to define a strawman framework first. I emphasize &quot;strawman&quot; - the term implies</FONT>
<BR><FONT SIZE=2>that the framework will be evolve significantly.</FONT>
</P>

<P><FONT SIZE=2>I do not support the idea of using a subset of applications to design a protocol.</FONT>
<BR><FONT SIZE=2>I like the idea of using use cases, as long as they are acceptable to the IESG,</FONT>
<BR><FONT SIZE=2>and as long as they go beyond &quot;user/end system interaction&quot;. </FONT>
</P>

<P><FONT SIZE=2>Gary K.</FONT>
</P>

<P><FONT SIZE=2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; From: David Partain [<A HREF="mailto:David.Partain@ericsson.com">mailto:David.Partain@ericsson.com</A>]</FONT>
<BR><FONT SIZE=2>&gt; Sent: January 24, 2002 04:36</FONT>
<BR><FONT SIZE=2>&gt; To: NSIS Mailing List</FONT>
<BR><FONT SIZE=2>&gt; Subject: Re: [NSIS] Framework &amp; requirements part of the &quot;Two kinds of</FONT>
<BR><FONT SIZE=2>&gt; requirements&quot; thread</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Hi all,</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; [Previous discussion clipped]</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Ping Pan gave a very down-to-earth view of what we should be</FONT>
<BR><FONT SIZE=2>&gt; doing.&nbsp; Thank you.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
</P>

<P><FONT SIZE=2>*snip*</FONT>
</P>

<P><FONT SIZE=2>&gt; &gt; In conclusion, IMHO, NSIS should</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; 1. focus on edge-to-edge signaling;</FONT>
<BR><FONT SIZE=2>&gt; &gt; 2. focus on a small set of applications to deal with;</FONT>
<BR><FONT SIZE=2>&gt; &gt; 3. focus on the relevant provider impact;</FONT>
<BR><FONT SIZE=2>&gt; &gt; 4. don't do a kitchen-sink blahblah that lasts for years.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Thank you for helping to keep us focused.&nbsp; I might perhaps</FONT>
<BR><FONT SIZE=2>&gt; put a heavier wireless emphasis on what you're saying, but I</FONT>
<BR><FONT SIZE=2>&gt; completely agree with it.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; 3 cents,</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; 2 eurocents.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Cheers,</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; dlp</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; _______________________________________________</FONT>
<BR><FONT SIZE=2>&gt; nsis mailing list</FONT>
<BR><FONT SIZE=2>&gt; nsis@ietf.org</FONT>
<BR><FONT SIZE=2>&gt; <A HREF="https://www1.ietf.org/mailman/listinfo/nsis" TARGET="_blank">https://www1.ietf.org/mailman/listinfo/nsis</A></FONT>
<BR><FONT SIZE=2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1A4F2.92F9F460--

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



From daemon@ns.ietf.org  Thu Jan 24 11:47:27 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26672
	for <nsis-archive@odin.ietf.org>; Thu, 24 Jan 2002 11:47:27 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id LAA07328
	for nsis-archive@odin.ietf.org; Thu, 24 Jan 2002 11:47:30 -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 LAA06625;
	Thu, 24 Jan 2002 11:36:05 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA06590
	for <nsis@ns.ietf.org>; Thu, 24 Jan 2002 11:36:03 -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 LAA26275
	for <nsis@ietf.org>; Thu, 24 Jan 2002 11:35:58 -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 g0OGa5t27133
	for <nsis@ietf.org>; Thu, 24 Jan 2002 18:36:05 +0200 (EET)
Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T58a63122f4ac158f23077@esvir03nok.nokia.com>;
 Thu, 24 Jan 2002 18:36:00 +0200
Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779);
	 Thu, 24 Jan 2002 18:35:56 +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] Framework & requirements part of the"Two kinds of  requirements" thread
Date: Thu, 24 Jan 2002 18:35:55 +0200
Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF5D9459@esebe004.NOE.Nokia.com>
Thread-Topic: [NSIS] Framework & requirements part of the"Two kinds of  requirements" thread
Thread-Index: AcGkuoebzynltI+LS5iUNgFagEuDZwAOmRhg
To: <David.Partain@ericsson.com>, <nsis@ietf.org>
X-OriginalArrivalTime: 24 Jan 2002 16:35:56.0380 (UTC) FILETIME=[3278B9C0:01C1A4F5]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA06591
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,

> If we try to throw every possible problem area into the NSIS
> work, this working group will still be talking when we're rolling
> out 8th generation mobile telephony :-)  

Hopefully, we are thinking of more than just mobile telephony ;)

Please note that we are looking to solve practical problems, while
ensure an open structure / framework for future extensibility.
The reason for the short timeline on the deliverables is to help us
focus on the task at hand.  I do not think we should through every
possible problem at NSIS.

John

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



From daemon@ns.ietf.org  Thu Jan 24 11:51: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 LAA26887
	for <nsis-archive@odin.ietf.org>; Thu, 24 Jan 2002 11:51:56 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id LAA07699
	for nsis-archive@odin.ietf.org; Thu, 24 Jan 2002 11:51: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 LAA06970;
	Thu, 24 Jan 2002 11:42: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 LAA06939
	for <nsis@ns.ietf.org>; Thu, 24 Jan 2002 11:42:35 -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 LAA26492
	for <nsis@ietf.org>; Thu, 24 Jan 2002 11:42:31 -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.34)
	  id 16Tmwt-0001dg-00; Thu, 24 Jan 2002 17:42:03 +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 g0OGg3a15815;
	Thu, 24 Jan 2002 17:42:03 +0100
Message-ID: <3C50395B.72FCC49C@ee.tu-berlin.de>
Date: Thu, 24 Jan 2002 17:42:03 +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: Gary Kenward <gkenward@nortelnetworks.com>
CC: "'David.Partain@ericsson.com'" <David.Partain@ericsson.com>,
        NSIS Mailing List <nsis@ietf.org>
Subject: Re: [NSIS] Framework & requirements part of the "Two kinds of  
 requirements" thread
References: <9FBD322B7824D511B36900508BF93C9C01AA47B0@zcard031.ca.nortel.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: nsis-admin@ietf.org
Errors-To: nsis-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Next Steps in Signaling <nsis.ietf.org>
X-BeenThere: nsis@ietf.org
Content-Transfer-Encoding: 7bit

Gary, 

I agree with your explanation.

Cheers,
Xiaoming
> Gary Kenward wrote:
> 
> I don't believe that anyone has proposed "kitchen sink" or
> signalling that is not needed. I believe that there are a number
> of very important problem areas that need to be addressed. At the
> moment, the prevalent thread is whether all or many of these signalling
> needs can be resolved with one protocol. There is a great risk in
> attacking the problem in a piecemeal fashion: the result may not hold
> solve enough of the problem to be useful.
> 
> Some specific comments:
> 
>   - if there is a need for a protocol to run end-to-end at the application
>     layer without interacting with the network, then this can be resolved
>     in two ways: a separate protocol that is designed *only* for this
>     purpose; a protocol that can interact with a network, if the network
>     is able and willing (i.e. has the functional and policy support).
> 
>     the first solution fulfils only one of the needs stated so far on this
>     list, and implies a requirement for multiple signalling protocols to
>     set up the end to end *and* network QoS; on the plus side, it is a
>     self contained problem (by definition), independent upon network
>     architecture.
> 
>     the second solution is tougher because it requires a definition of
>     a generic framework that will allow interaction between the end-to-
>     end and entities within the network; on the plus side, it is likely
>     to be more efficient then the first solution.
> 
>   - implicit in Ping Pan's proposal is the idea that a useful signalling
>     protocol will emerge out of the sequential development of hop-by-hop
>     signalling (i.e. host to edge, node to node, edge to edge, etc.); this
>     is somewhat like trying to build a jet engine one piece at a time, it
>     will not work unless you have an idea where the pieces fit ahead of time.
> 
>   - while I'm not entirely sure what Ping Pan means by an "application"
>     (i.e. a usage scenario coupled with network services, a piece of software)
>     basing the design on a subset of applications may be the fastest way
>     of generating a solution, but no likely the most useful in the long term.
> 
> 
> Finally, I support the idea of tackling a specific problem are first: my
> preference being host to edge, but I strongly recommend that we make an attempt
> to define a strawman framework first. I emphasize "strawman" - the term implies
> that the framework will be evolve significantly.
> 
> I do not support the idea of using a subset of applications to design a protocol.
> I like the idea of using use cases, as long as they are acceptable to the IESG,
> and as long as they go beyond "user/end system interaction".
> 
> Gary K.
> 
> > -----Original Message-----
> > From: David Partain [mailto:David.Partain@ericsson.com]
> > Sent: January 24, 2002 04:36
> > To: NSIS Mailing List
> > Subject: Re: [NSIS] Framework & requirements part of the "Two kinds of
> > requirements" thread
> >
> >
> > Hi all,
> >
> > [Previous discussion clipped]
> >
> > Ping Pan gave a very down-to-earth view of what we should be
> > doing.  Thank you.
> >
> > > Before we define end-to-end, edge-to-edge and
> > domain-to-domain, ask the
> > > following:
> > >
> > > - why do we signal in the first place?
> > > - where do we need to signal?
> > > - will signaling work in provider's networks?
> > >
> > > We signal because there is no QoS when we are using some
> > inter-active
> > > real-time applications. Since most of the Internet traffic
> > is not within
> > > the scope of this "inter-active" and "real-time", let's not
> > consider a
> > > kitchen-sink signaling protocol.
> >
> > If we try to throw every possible problem area into the NSIS
> > work, this working group will still be talking when we're rolling
> > out 8th generation mobile telephony :-)  We have to work very
> > hard at limiting the scope of what we are trying to do.  Yes,
> > everyone has their particular area of interest, and everyone's
> > not going to be happy (I may be one of them).  But we _must_
> > start by solving the most acute problems.  If we demonstrate
> > competence at doing that, maybe we can move onto other problems
> > later.
> >
> > [clipped bit on adaptive applications]
> >
> > > Currently, most of the backbone networks are over-provisioned, so no
> > > serious signaling is required yet. End-to-end signaling is very
> > > attractive to the end users, but the providers will not
> > allow the users
> > > to tell the routers how much to reserve. In fact, I doubt
> > the providers
> > > will listen to anything that end-user are throwing at them. So other
> > > than some end-to-end measurement-based approach, I don't see e2e
> > > signaling will fly in the present network.
> >
> > "End-to-end signalling" doesn't necessarily imply that everyone
> > in the path has to care.  That's what I think is so important
> > about the framework picture that I sent out yesterday:  each
> > domain decides how it's going to provide (or not) the quality
> > of service being requested.  There are going to be those with
> > Big Fat Pipes who may _never_ introduce any kind QoS mechanisms
> > into their boxes.  Their domain-specific solution is
> > overprovisioning, which is cool.  If their customers/partners
> > agree to this (the business side of things), then we can still
> > provide "end-to-end" QoS.
> >
> > You want to provide QoS differentiation with DiffServ?  Fine.
> > You want to do it with IntServ?  Fine.  You want to use traffic
> > engineering with MPLS?  Fine.  You want to use it with YAFQoSP
> > (yet another future QoS protocol)?  Fine.  Just give the "layer"
> > above the answer so that we can build an end-to-end answer.
> >
> > There is no alternative, in my view, to having end-to-end QoS
> > as a product of the concatenation of domain-specific responses
> > to QoS requests.  We will never have homogeneity.  If we don't
> > create with this assumption in NSIS, I think we'll lose.
> >
> > > The place where we need signaling is inside the access
> > networks. This is
> > > the place where the providers have no incentive to
> > over-provision (to
> > > flat-rate users? please), and this is the place where we may see
> > > resource shortage.
> >
> > I certainly agree that this where I think the most acute
> > needs are.
> >
> > > Finally, the providers are motivated by money to provide
> > any additional
> > > service. Unless the traffic that they are carrying worth
> > something, they
> > > will never deploy some extra "stuff" inside the network. So
> > what's worth
> > > money? ....
> > >
> > > - voice traffic! I am not only talking about VoIP; I am
> > talking all the
> > > voice traffic that use the Internet infrastructure.
> > >
> > > - wireless traffic: users packets are not landed inside the
> > backbone, so
> > > the access network needs to do more to those flows.
> > >
> > > - VPN (an over-used term :-)): but some users want to have QoS
> > > reservation even though they are sending any traffic. Not for any
> > > technical reason, it's a business reason. Have you seen the
> > amount of
> > > traffic in a SNA network, and how much they have been charged? :-)
> > >
> > > In conclusion, IMHO, NSIS should
> > >
> > > 1. focus on edge-to-edge signaling;
> > > 2. focus on a small set of applications to deal with;
> > > 3. focus on the relevant provider impact;
> > > 4. don't do a kitchen-sink blahblah that lasts for years.
> >
> > Thank you for helping to keep us focused.  I might perhaps
> > put a heavier wireless emphasis on what you're saying, but I
> > completely agree with it.
> >
> > > 3 cents,
> >
> > 2 eurocents.
> >
> > 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@ns.ietf.org  Thu Jan 24 11:57: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 LAA27112
	for <nsis-archive@odin.ietf.org>; Thu, 24 Jan 2002 11:57:34 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id LAA07959
	for nsis-archive@odin.ietf.org; Thu, 24 Jan 2002 11:57: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 LAA07381;
	Thu, 24 Jan 2002 11:47: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 LAA07346
	for <nsis@ns.ietf.org>; Thu, 24 Jan 2002 11:47:50 -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 LAA26689
	for <nsis@ietf.org>; Thu, 24 Jan 2002 11:47:45 -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 g0OGlTj26805
	for <nsis@ietf.org>; Thu, 24 Jan 2002 18:47:29 +0200 (EET)
Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T58a63bef5cac158f254fc@esvir05nok.ntc.nokia.com>;
 Thu, 24 Jan 2002 18:47:47 +0200
Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779);
	 Thu, 24 Jan 2002 18:47:46 +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] Framework & requirements part of the "Two kinds of  requirements" thread
Date: Thu, 24 Jan 2002 18:47:45 +0200
Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF5D945B@esebe004.NOE.Nokia.com>
Thread-Topic: [NSIS] Framework & requirements part of the "Two kinds of  requirements" thread
Thread-Index: AcGkPnisuyA4QJHTSP6m55hK5t15ugAuB0Pg
To: <pingpan@juniper.net>
Cc: <nsis@ietf.org>
X-OriginalArrivalTime: 24 Jan 2002 16:47:46.0416 (UTC) FILETIME=[D9AF9F00:01C1A4F6]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA07347
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 Ping,

> Before we define end-to-end, edge-to-edge and 
> domain-to-domain, ask the 
> following:
> 
> - why do we signal in the first place?
> - where do we need to signal?
> - will signaling work in provider's networks?
> 
> We signal because there is no QoS when we are using some inter-active 
> real-time applications. Since most of the Internet traffic is 
> not within the scope of this "inter-active" and "real-time", let's not 
> consider a kitchen-sink signaling protocol.

I agree.  You are asking very good questions and these are
the items we should focus on.

John

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



From daemon@ns.ietf.org  Thu Jan 24 11:58: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 LAA27130
	for <nsis-archive@odin.ietf.org>; Thu, 24 Jan 2002 11:58:02 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id LAA07976
	for nsis-archive@odin.ietf.org; Thu, 24 Jan 2002 11:58: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 LAA07475;
	Thu, 24 Jan 2002 11:48: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 LAA07438
	for <nsis@ns.ietf.org>; Thu, 24 Jan 2002 11:48:09 -0500 (EST)
Received: from arb-exchange1.cetaceannetworks.com ([63.127.199.202])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26714
	for <nsis@ietf.org>; Thu, 24 Jan 2002 11:48:06 -0500 (EST)
Received: by mail.cetaceannetworks.com with Internet Mail Service (5.5.2653.19)
	id <DGB67NNJ>; Thu, 24 Jan 2002 11:45:03 -0500
Message-ID: <6D8664171C38D511B5AD0002B325CE6633EC8D@mail.cetaceannetworks.com>
From: "Freytsis, Ilya" <ifreytsis@cetacean.com>
To: "'nsis@ietf.org'" <nsis@ietf.org>
Subject: RE: [NSIS] Framework & requirements part of the "Two kinds of req
	uirements" thread
Date: Thu, 24 Jan 2002 11:45:00 -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

Weijing,

I like your diagram much better than original one and agree with you that
detailed Use Cases should lead to the diagram of this sort not the other way
around.
I want to comment on your "glue" - it looks to me very much as an adaptation
layer to the domain specific QoS technology in use. From this perspective I
would say NO, NSIS should not deal with it.  Though it should not prohibit a
QoS technology re-use NSIS if it finds it useful.

Ilya Freytsis

 

From: "Chen, Weijing" <wchen@tri.sbc.com>
To: David.Partain@ericsson.com
Cc: NSIS Mailing List <nsis@ietf.org>
Subject: RE: [NSIS] Framework & requirements part of the "Two kinds of
requirements" thread
Date: Thu, 24 Jan 2002 02:43:16 -0600


I have fundamental disagreement with David's point.

1. David's proposal of working requirement within so called "framework" is
putting the cart before the horse. Because we think one framework is cool,
we confine our requirements and use cases within that framework. It is
totally unacceptable.

2. 

|-----|                                                  |-----|
|ehost|<------------------------------------------------>|ehost|
|-----|                                                  |-----|
|     |                                                  |     |
|-----|            |-----|            |-----|            |-----|
|eedge|<---------->|eedge|<---------->|eedge|<---------->|eedge|
|-----|            |-----|            |-----|            |-----|
|     |            |     |            |     |            |     |
|-----|   |----|   |-----|   |----|   |-----|   |----|   |-----|
|ehop |<->|ehop|<->|ehop |<->|ehop|<->|ehop |<->|ehop|<->|ehop |
|-----|   |----|   |-----|   |----|   |-----|   |----|   |-----|
 host    interior   edge    interior   edge     interior  host
         w/in domain       w/in domain        w/in domain

In above picture, [host] has to assemble and process the [ehop], [eedge] in
addition to [ehost] part. How will the [host] correctly assemble and process
the [ehop] and [eedge] pieces? It implies that [host] has global view of
[ehop] and [eedge] in every domains. For this to happen, there must be
another protocol to exchange network information and pass whole network view
to [host]. So on, and so on, and sooner we know that we revive an ultimate
engineer dream: a protocol for all and do all. Be there, done that, and
failed. Otherwise we wouldn't be here to debate about what NSIS should be.

The right picture should be (if you insist talking about the framework
before requirement):

                   |-----|   |----|   |-----|  
                   |ehop |<->|ehop|<->|ehop |   
                   |-----|   |----|   |-----| 
                   |     |            |     |
                   |-----|            |-----|
                   |glue |            |glue |
                   |-----|            |-----|
                   |     |            |     |
|-----|            |-----|            |-----|            |-----|
|ehost|<---------->|ehost|<---------->|ehost|<---------->|ehost|
|-----|            |-----|            |-----|            |-----|
 host                edge     hop      edge                host
           domain            domains             domain
                             (inter and
                              intra)
           NSIS                                   NSIS

Now what about "glue"? Shall NSIS do it? Part of me says yes, another says
no. I am 50/50.

--
Weijing Chen
SBC Technology Resources
9505 Arboretum Blvd.
Austin, TX 78759
512 372 5710
wchen@tri.sbc.com




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



From daemon@ns.ietf.org  Thu Jan 24 12:02: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 MAA27440
	for <nsis-archive@odin.ietf.org>; Thu, 24 Jan 2002 12:02:15 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id MAA09418
	for nsis-archive@odin.ietf.org; Thu, 24 Jan 2002 12:02: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 LAA07778;
	Thu, 24 Jan 2002 11:52: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 LAA07750
	for <nsis@ns.ietf.org>; Thu, 24 Jan 2002 11:52:28 -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 LAA26937
	for <nsis@ietf.org>; Thu, 24 Jan 2002 11:52:24 -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 g0OGq8j28281
	for <nsis@ietf.org>; Thu, 24 Jan 2002 18:52:08 +0200 (EET)
Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T58a6402fadac158f254fc@esvir05nok.ntc.nokia.com>;
 Thu, 24 Jan 2002 18:52:26 +0200
Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779);
	 Thu, 24 Jan 2002 18:52:03 +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] Two kinds of requirements
Date: Thu, 24 Jan 2002 18:52:02 +0200
Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF5D945C@esebe004.NOE.Nokia.com>
Thread-Topic: [NSIS] Two kinds of requirements
Thread-Index: AcGjrD7+YLmTrm/hSJ6xJIV1/fVRbgBStS8g
To: <mendes@cs.columbia.edu>
Cc: <nsis@ietf.org>
X-OriginalArrivalTime: 24 Jan 2002 16:52:03.0519 (UTC) FILETIME=[72EE6CF0:01C1A4F7]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA07751
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 Paulo,

> What happens with one-to-many applications like video-on-demand or 
> InternetTV? In this case you can't establish a session level QoS 
> agreement between provider and clients before the session 
> starts (and so before the reservation of resources) because you would 
> not know all your clients at that time.

Currently, I do not see this as a major part of NSIS.  I think this
should be held for later consideration.  I do not see that VOD or
Internet TV as burning issues.  I'm hoping we focus on one-to-one
signaling.

John

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



From daemon@ns.ietf.org  Thu Jan 24 12:10: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 MAA27805
	for <nsis-archive@odin.ietf.org>; Thu, 24 Jan 2002 12:10:49 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id MAA09797
	for nsis-archive@odin.ietf.org; Thu, 24 Jan 2002 12:10: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 MAA08909;
	Thu, 24 Jan 2002 12:00:42 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA08876
	for <nsis@ns.ietf.org>; Thu, 24 Jan 2002 12:00:39 -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 MAA27358
	for <nsis@ietf.org>; Thu, 24 Jan 2002 12:00:34 -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 g0OH2hT19145
	for <nsis@ietf.org>; Thu, 24 Jan 2002 11:02:43 -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 g0OH02q24418
	for <nsis@ietf.org>; Thu, 24 Jan 2002 11:00:02 -0600 (CST)
Received: by TRIMAIL2.ad.tri.sbc.com with Internet Mail Service (5.5.2653.19)
	id <ZND3JDF9>; Thu, 24 Jan 2002 11:00:30 -0600
Message-ID: <905A1C4ABF353F4C8CC16FA9F53DD0D62A7016@TRIMAIL2.ad.tri.sbc.com>
From: "Allen, Keith" <kallen@tri.sbc.com>
To: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements
Date: Thu, 24 Jan 2002 11:00:30 -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 Paulo,

> What happens with one-to-many applications like video-on-demand or 
> InternetTV? In this case you can't establish a session level QoS 
> agreement between provider and clients before the session 
> starts (and so before the reservation of resources) because you would 
> not know all your clients at that time.

Currently, I do not see this as a major part of NSIS.  I think this
should be held for later consideration.  I do not see that VOD or
Internet TV as burning issues.  I'm hoping we focus on one-to-one
signaling.

John


Actually, I would like to see NSIS address this issue.  I don't see all the
clients have to be known at the beginning of the session, though.  The
content provider can merely instantiate the session, and others can join or
drop as they wish (or be added and dropped by the content provider, if
that's how we decide we want it to work).  As far as determining what the
QoS of the session will be, that would be up to the content provider.

Keith Allen
SBC Technology Resources
9505 Arboretum Blvd.
Austin, TX 78759
(512) 372-5741
kallen@tri.sbc.com

 -----Original Message-----
From: 	john.loughney@nokia.com [mailto:john.loughney@nokia.com] 
Sent:	Thursday, January 24, 2002 10:52 AM
To:	mendes@cs.columbia.edu
Cc:	nsis@ietf.org
Subject:	RE: [NSIS] Two kinds of requirements

Hi Paulo,

> What happens with one-to-many applications like video-on-demand or 
> InternetTV? In this case you can't establish a session level QoS 
> agreement between provider and clients before the session 
> starts (and so before the reservation of resources) because you would 
> not know all your clients at that time.

Currently, I do not see this as a major part of NSIS.  I think this
should be held for later consideration.  I do not see that VOD or
Internet TV as burning issues.  I'm hoping we focus on one-to-one
signaling.

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  Thu Jan 24 12:12: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 MAA27999
	for <nsis-archive@odin.ietf.org>; Thu, 24 Jan 2002 12:12:20 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id MAA09968
	for nsis-archive@odin.ietf.org; Thu, 24 Jan 2002 12:12: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 MAA09512;
	Thu, 24 Jan 2002 12:02: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 MAA09476
	for <nsis@ns.ietf.org>; Thu, 24 Jan 2002 12:02:46 -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 MAA27468
	for <nsis@ietf.org>; Thu, 24 Jan 2002 12:02:37 -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 g0OH2ft07635
	for <nsis@ietf.org>; Thu, 24 Jan 2002 19:02:41 +0200 (EET)
Received: from esebh002.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T58a6497de6ac158f22078@esvir02nok.ntc.nokia.com>;
 Thu, 24 Jan 2002 19:02:36 +0200
Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779);
	 Thu, 24 Jan 2002 19:02:36 +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] Two kinds of requirements   (unsupported domains + chick en and eggs)
Date: Thu, 24 Jan 2002 19:02:35 +0200
Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF5D9460@esebe004.NOE.Nokia.com>
Thread-Topic: [NSIS] Two kinds of requirements   (unsupported domains + chick en and eggs)
Thread-Index: AcGgP2DZvR2X/hIxR2WKob0Cr2jw4AEuXv+w
To: <dick.rr.knight@bt.com>, <Hemant.Chaskar@nokia.com>, <nsis@ietf.org>
X-OriginalArrivalTime: 24 Jan 2002 17:02:36.0302 (UTC) FILETIME=[EC1972E0:01C1A4F8]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id MAA09477
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 Dick,

> Interesting though this is, I don't think that this is what 
> NSIS is all about.

Agreed, I believe this is outside the scope of NSIS.

John

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



From daemon@ns.ietf.org  Thu Jan 24 15:23: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 PAA04565
	for <nsis-archive@odin.ietf.org>; Thu, 24 Jan 2002 15:23:00 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id PAA20083
	for nsis-archive@odin.ietf.org; Thu, 24 Jan 2002 15:23: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 PAA19312;
	Thu, 24 Jan 2002 15:08: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 PAA19282
	for <nsis@ns.ietf.org>; Thu, 24 Jan 2002 15:08:38 -0500 (EST)
Received: from sierra.seas.upenn.edu (root@sierra.seas.upenn.edu [158.130.64.180])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04185
	for <nsis@ietf.org>; Thu, 24 Jan 2002 15:08:34 -0500 (EST)
Received: from cs.columbia.edu (DHCP64-23.SEAS.UPENN.EDU [158.130.64.102])
	by sierra.seas.upenn.edu (8.9.3/8.9.3) with ESMTP id PAA08998;
	Thu, 24 Jan 2002 15:08:30 -0500 (EST)
Message-ID: <3C5069C1.1050802@cs.columbia.edu>
Date: Thu, 24 Jan 2002 15:08:33 -0500
From: Paulo Mendes <mendes@cs.columbia.edu>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1
X-Accept-Language: en-us
MIME-Version: 1.0
To: "Geib, Ruediger" <Ruediger.Geib@t-systems.com>
CC: h.demeer@ee.ucl.ac.uk, nsis@ietf.org
Subject: Re: [NSIS] Support needed for Throughput Adaptive QoS in  wireles	s
References: <DFD875E85664D3118FA6080006277DE70362C83E@U8PN2>
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



Geib, Ruediger wrote:

> Paulo,
> 
> 
>>[PM] It should be interesting to complement this congestion 
>>notification with some information to help applications to
>>converge quickly to the optimal rate. Let say for example
>>inform applications about the bandwidth the network allocs
>>to their session. NSIS could get this information from
>>network level protocols.
>>
> 
> Adding resource reduction information per application may be a good idea. But it means we'd have to find a simple way of letting the resource reducing node learn which applications currently are active and which amounts of rates may be reduced per application. It further may have to learn the addresses of these applications.
> As you say, deriving rate reduction targets for aggregates may not be useful. Looking at a core network node, a congestion notification sent upstream certainly is reasonable. The rate/duration of congestion notifications or a signalled weight may indicate how severe the congestion is. "Per flow signalling nodes" closer to the application or the application itself could interpret the congestion notification and decide on target rates for applications. The absence of congestion notifications may then result in a return to standard rate.


Yes.. I agree that we need to find this simple way of letting the 
network (I say edge routers for sake of scalability) know which 
applications/sessions should have their bandwidth increased or 
decreased. This because one of NSIS requirements, in my opinion, is to 
inform the client about the quality level his entitle to, at setup up 
and during the session.

However, probably is better to include this study in the future 
discussion of NSIS framework. By now the point is to discuss 
requirements. IMHO, NSIS notification to clients should be included in 
the requirements list. And this notification should be more than a 
congestion/non-congestion notification, as I mentioned before.

As example of one advantage of sure notification, I could say motivate 
clients to adapt to quality oscillations, re-negotiate or just leave the 
session freeing resources for others.

Cheers
Paulo



-- 
| Paulo Mendes
| www.cs.columbia.edu/~mendes


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



From daemon@ns.ietf.org  Thu Jan 24 15:57:42 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05575
	for <nsis-archive@odin.ietf.org>; Thu, 24 Jan 2002 15:57:42 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id PAA22086
	for nsis-archive@odin.ietf.org; Thu, 24 Jan 2002 15:57: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 PAA21516;
	Thu, 24 Jan 2002 15:45: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 PAA21464
	for <nsis@ns.ietf.org>; Thu, 24 Jan 2002 15:45:31 -0500 (EST)
Received: from sierra.seas.upenn.edu (root@sierra.seas.upenn.edu [158.130.64.180])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05163
	for <nsis@ietf.org>; Thu, 24 Jan 2002 15:45:27 -0500 (EST)
Received: from cs.columbia.edu (DHCP64-23.SEAS.UPENN.EDU [158.130.64.102])
	by sierra.seas.upenn.edu (8.9.3/8.9.3) with ESMTP id PAA11257;
	Thu, 24 Jan 2002 15:24:10 -0500 (EST)
Message-ID: <3C506D6D.6010203@cs.columbia.edu>
Date: Thu, 24 Jan 2002 15:24:13 -0500
From: Paulo Mendes <mendes@cs.columbia.edu>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1
X-Accept-Language: en-us
MIME-Version: 1.0
To: dick.rr.knight@bt.com
CC: rrroy@att.com, schneider@tri.sbc.com, gkenward@nortelnetworks.com,
        john.loughney@nokia.com, brunner@ccrle.nec.de, ykahana@comgates.co.il,
        Ruediger.Geib@t-systems.com, nsis@ietf.org
Subject: Re: [NSIS] Two kinds of requirements
References: <451D45016C2CD2119DA50000F8FE7F07080E5A60@mlngcbnt01.hc.bt.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



dick.rr.knight@bt.com wrote:

> Nice one. I was waiting for this.
> 
> So .. another new requirement. To support one-to-many applications.


Yeap.. I say this is another requirement. I think that if we don't keep 
in mind one-to-many applications we'll specialize NSIS functionality to 
one-to-one cases, and then it would be hard to use NSIS with other type 
of applications...

Probably one-to-one requirements could be seen as a sub-group of one-to-many requirements.


> There are two aspects to this:
> 1. The easy case. In internet TV, a provider (source of the TV) is
> available. The first client uses NSIS to negotiate QoS with the network and
> the source. Assuming the negotiation is successful a "connection" is
> established. The second client then attepts to receive the TV. On initiating
> the NSIS negotiation of QoS, they get a "take it or leave it" result of the
> first client's negotiation. Anything else is not scalable.
> 2. A business conference will be established, with a known (limited) number
> of clients. The provider can initiate the negotiation with the clients to
> achieve the best possible QoS using the least resources.
> 
> The first case is no extra requirements above an IP telephony call. The
> second requires multiparty negotiation at establishment.



I don't think this "take it of leave it" approach is the best one. For 
example, if the first client has a low quality requirement all the other 
clients can refuse join the session if they have a high quality expectation.
I think that a more flexible approach is needed. For example, the 
content provider should negotiate with the network provider a minimum 
quality level for the session, since he doesn't want to provide services 
with lower quality than that. After this, every client that joins the 
session can accept that level of quality or they can try to re-negotiate 
   with the network an increase of quality.

Cheers
Paulo

> 
> Dick
> 
> -----Original Message-----
> From: Paulo Mendes [mailto:mendes@cs.columbia.edu]
> Sent: 23 January 2002 01:21
> To: Roy, Radhika R, ALASO
> Cc: Schneider, Marco; Gary Kenward; Loughney John (NRC/Helsinki);
> brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
> dick.rr.knight@bt.com; nsis@ietf.org
> Subject: Re: [NSIS] Two kinds of requirements
> 
> 
> If I understood correctly NSIS should be a QoS signalling protocol 
> useful to all applications, right?
> 
> However it seems that this division between Application Layer QoS 
> signalling (NSIS QoS) and posterior reservation request to the network 
> for the necessary QoS agreed to at the session level only works for 
> one-to-one applications, like IP telephony.
> 
> What happens with one-to-many applications like video-on-demand or 
> InternetTV? In this case you can't establish a session level QoS 
> agreement between provider and clients before the session starts (and so 
> before the reservation of resources) because you would not know all your 
> clients at that time.
> 
> Paulo Mendes
> 
> 
> 
> 
> Roy, Radhika R, ALASO wrote:
> 
> 
>>Hi, Marco:
>>
>>Let me try to clarify from your point of view.
>>
>>It seems to agree that there needs to be a session level QOS agreement.
>>
> Let us analyze what is this. To make an agreement, we need to send some
> messages between the end points. This may be termed as "signaling."
> 
>>A session expresses its QOS for its "application" that may consist of
>>
> media: audio, video, and/or data.
> 
>>In general, the above two items can be expressed as "Application Layer QOS
>>
> signaling."
> 
>>I think that we are agreeing on technical points.
>>
>>Best regards,
>>Radhika R. Roy
>>
>>-----Original Message-----
>>From: Schneider, Marco [mailto:schneider@tri.sbc.com]
>>Sent: Friday, January 18, 2002 3:10 PM
>>To: Roy, Radhika R, ALASO; Gary Kenward; Loughney John (NRC/Helsinki);
>>brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
>>dick.rr.knight@bt.com
>>Cc: nsis@ietf.org
>>Subject: RE: [NSIS] Two kinds of requirements
>>
>>
>>Hi Roy,
>>
>>Below is the original text from your reponse to Gary Kenward. Hopefully
>>
> the
> 
>>context is clear.
>>
>>"[Roy, Radhika R, ALARC]  I would say that it is the QOS needs of the
>>application (e.g., SIP-based VoIP) that the user likes to express (as
>>opposed to "service"). Similarly, instead of network services, we would
>>
> say
> 
>>network layer QOS services (e.g., RSVP, DiffServ, MPLS). We would develop
>>the end-to-end (application layer) QOS signaling protocol (say, NSIS QOS).
>>Now, there needs to have some kinds of standards how NSIS QOS will be
>>
> mapped
> 
>>over RSVP, DiffServ, MPLS, etc."
>>
>>So by End-to-End you mean between directly between two "users". This is
>>session level signaling and I don't believe the signaling part is within
>>
> the
> 
>>scope of this working group. An application level QOS specification may
>>
> be. 
> 
>>After a session level agreement on QOS, the host/client/customer will need
>>to signal an actual reservation request to the network for the necessary
>>
> QOS
> 
>>agreed to at the session level. This is the protocol that we need to work
>>on. 
>>
>>This approach is discussed in the SIP draft "SIP Extensions for Media
>>Authorization" (draft-ietf-sip-call-auth-03.txt) and the RAP draft
>>"Framework for session set-up with media authorization"
>>(draft-ietf-rap-session-auth-02.txt).
>>
>>Marco Schneider
>>
>>-----Original Message-----
>>From: Roy, Radhika R, ALASO [mailto:rrroy@att.com]
>>Sent: Friday, January 18, 2002 9:18 AM
>>To: Schneider, Marco; Gary Kenward; Loughney John (NRC/Helsinki);
>>brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
>>dick.rr.knight@bt.com
>>Cc: nsis@ietf.org
>>Subject: RE: [NSIS] Two kinds of requirements
>>
>>
>>Defined below [RRR]
>>
>>-----Original Message-----
>>From: Schneider, Marco [mailto:schneider@tri.sbc.com]
>>Sent: Thursday, January 17, 2002 8:47 PM
>>To: Roy, Radhika R, ALASO; Gary Kenward; Loughney John (NRC/Helsinki);
>>brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
>>dick.rr.knight@bt.com
>>Cc: nsis@ietf.org
>>Subject: RE: [NSIS] Two kinds of requirements
>>
>>
>>Hi Roy,
>>
>>Can you please define what you mean by "End-to-End Application Layer QOS
>>Signaling". Thanks.
>>
>>[RRR] Suppose an user is initiation a SIP call to another user with audio,
>>video, and data. The use needs to express the needs of QOS for audio,
>>
> video,
> 
>>and data to another user. 
>>
>>[RRR] The signaling mechanism that allows to express the QOS parameters of
>>audio, video, and data is termed as the "End-to-End Application Layer QOS
>>Signaling."
>>
>>Marco Schneider
>>
>>_______________________________________________
>>nsis mailing list
>>nsis@ietf.org
>>https://www1.ietf.org/mailman/listinfo/nsis
>>
>>
> 
> 


-- 
| Paulo Mendes
| www.cs.columbia.edu/~mendes


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



From daemon@ns.ietf.org  Thu Jan 24 16:15: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 QAA06141
	for <nsis-archive@odin.ietf.org>; Thu, 24 Jan 2002 16:15:23 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id QAA23814
	for nsis-archive@odin.ietf.org; Thu, 24 Jan 2002 16:15: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 QAA23264;
	Thu, 24 Jan 2002 16:06: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 QAA23213
	for <nsis@ns.ietf.org>; Thu, 24 Jan 2002 16:06:16 -0500 (EST)
Received: from sierra.seas.upenn.edu (root@sierra.seas.upenn.edu [158.130.64.180])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05898
	for <nsis@ietf.org>; Thu, 24 Jan 2002 16:06:12 -0500 (EST)
Received: from cs.columbia.edu (DHCP64-23.SEAS.UPENN.EDU [158.130.64.102])
	by sierra.seas.upenn.edu (8.9.3/8.9.3) with ESMTP id QAA17800;
	Thu, 24 Jan 2002 16:06:08 -0500 (EST)
Message-ID: <3C507744.4070208@cs.columbia.edu>
Date: Thu, 24 Jan 2002 16:06:12 -0500
From: Paulo Mendes <mendes@cs.columbia.edu>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1
X-Accept-Language: en-us
MIME-Version: 1.0
To: "Roy, Radhika R, ALASO" <rrroy@att.com>
CC: john.loughney@nokia.com, Ruediger.Geib@t-systems.com, nsis@ietf.org
Subject: Re: [NSIS] Support needed for Throughput Adaptive QoS in wireless
References: <62DA45D4963FA747BA1B253E266760F90126D047@OCCLUST04EVS1.ugd.att.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



Roy, Radhika R, ALASO wrote:

> Inline [RRR]
> 
> -----Original Message-----
> From: Paulo Mendes [mailto:mendes@cs.columbia.edu]
> Sent: Tuesday, January 22, 2002 9:17 PM
> To: Roy, Radhika R, ALASO
> Cc: john.loughney@nokia.com; Ruediger.Geib@t-systems.com; nsis@ietf.org
> Subject: Re: [NSIS] Support needed for Throughput Adaptive QoS in
> wireless
> 
> 
> There are references in this thread to adaptive applications and 
> applications that require re-negotiation of QoS parameters. However 
> these are two different type of applications.
> I agree with you that re-negotiation require extra signalling from NSIS. 
> However this extra burden don't exist with adaptive applications, which 
> I think only require to be notified by NSIS about the available network 
> quality... So the requirements imposed to NSIS by these two types of 
> applications are different.
> 
> [RRR] Not really. We do not know what is the definition of adaptive application (can you cite an example that is being used?). If we assume that an adaptive application is able to adapt the QOS in accordance to the needs of the lower layer QOS, even then NSIS QOS will be able to satisfy its needs. Because the adaptive application, as I understand from your term with limited knowledge, will not use all capabilities of the NSIS QOS. It will rather will use a sub-set of the NSIS QOS capability.
 

[PM] By adaptive applications I mean applications that have the 
capability to adjust the rate they are using depending upon the 
available network resources. For this they need to be notified by the 
network about the quality level they are entitle to during the session.
As an example of an adaptive mechanism I can mention RLM from Steve 
McCanne as receiver-driven and MLDA from Dorgham Sisalem as 
source-driven. I can also mention an application that allows 
receiver-driven adaptation since receivers can adjust the video quality 
adjusting the number of video layers they receive: Rendez-Vous 
(http://www.gaia-interactive.com/rv/)
Therefore, I think adaptive applications support should be considered in 
  the NSIS Framework, as was proposed by David Partain.


> [RRR] It is also not clear how an adaptive application will behave when QOS needs to be agreed upon between the two parties. Can you please provide some examples to know their behavior?


[PM] During setup I think they might behave exactly as the other 
applications, i.e., they will try to negotiate a quality level with the 
network. I only meant that during the session, adaptive applications 
differ from applications that require re-negotiation since the latter 
will require extra signalling.

Cheers
Paulo


> Roy, Radhika R, ALASO wrote:
> 
> 
>>Hi, John:
>>
>>I agree with you and like to add a little more [RRR].
>>
>>Best regards,
>>Radhika
>>
>>


-- 
| Paulo Mendes
| www.cs.columbia.edu/~mendes


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



From daemon@ns.ietf.org  Thu Jan 24 16:31: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 QAA06590
	for <nsis-archive@odin.ietf.org>; Thu, 24 Jan 2002 16:31:03 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id QAA25150
	for nsis-archive@odin.ietf.org; Thu, 24 Jan 2002 16:31: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 QAA24154;
	Thu, 24 Jan 2002 16:21: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 QAA24123
	for <nsis@ns.ietf.org>; Thu, 24 Jan 2002 16:21:34 -0500 (EST)
Received: from sierra.seas.upenn.edu (root@sierra.seas.upenn.edu [158.130.64.180])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06268
	for <nsis@ietf.org>; Thu, 24 Jan 2002 16:21:29 -0500 (EST)
Received: from cs.columbia.edu (DHCP64-23.SEAS.UPENN.EDU [158.130.64.102])
	by sierra.seas.upenn.edu (8.9.3/8.9.3) with ESMTP id QAA20060;
	Thu, 24 Jan 2002 16:21:28 -0500 (EST)
Message-ID: <3C507ADB.2080804@cs.columbia.edu>
Date: Thu, 24 Jan 2002 16:21:31 -0500
From: Paulo Mendes <mendes@cs.columbia.edu>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1
X-Accept-Language: en-us
MIME-Version: 1.0
To: "Schneider, Marco" <schneider@tri.sbc.com>
CC: "'Gabor.Fodor@era-t.ericsson.se'" <Gabor.Fodor@era-t.ericsson.se>,
        nsis@ietf.org
Subject: Re: [NSIS] Support needed for Throughput Adaptive QoS in wireless
References: <905A1C4ABF353F4C8CC16FA9F53DD0D638B9AE@TRIMAIL2.ad.tri.sbc.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

Hi Marco

I agree with you. Probably NSIS could have a notification functionality 
retrieving information only from domain borders, where per-flow 
information is (edge-to-edge behaviour).

Paulo

Schneider, Marco wrote:

> Hi Gabor, All
> 
> This type of functionality concerns me. The network segment you speak of
> could be employing any number of mechanisms to help achieve its part of the
> end-to-end QOS. If we are to consider such notification is must be done in a
> manner that is independent of mechanism. 
> 
> Marco
> 
> -----Original Message-----
> From: Gabor.Fodor@era-t.ericsson.se
> [mailto:Gabor.Fodor@era-t.ericsson.se]
> Sent: Wednesday, January 23, 2002 4:51 AM
> To: mendes@cs.columbia.edu
> Cc: nsis@ietf.org
> Subject: Re: [NSIS] Support needed for Throughput Adaptive QoS in
> wireless
> 
> 
> 
> Paulo,
> 
> Paulo Mendes wrote :
> 
> 
>>Considering all the references to RSVP in this thread, the amount of 
>>resources reserved in the network can be the information to supply 
>>applications with. However this information is only useful if the 
>>network has per-flow reservation end-to-end, which isn't always true. If 
>>some kind of data aggregation in used in (part of) the network, e.g. 
>>DiffServ, the information that applications require from NSIS if not the 
>>amount of resources reserved to the DiffServ class/service they are 
>>using, but the amount of those resources that are allocated to their 
>>session.
>>
>>
> 
> [GF]
> In my view it can also be useful if the NSIS protocol allows a certain
> network segment to notify the host about the available resources either
> at call setup time or during the call even there is aggregation in
> some part(s) of the network. 
> 
> That is, the support of re-negotiation and adaptivity can be a 
> useful feature even if there is no per-flow resource reservation end-to-end.
> 
> An example of such a situation is a wireless access link that has
> its own wireless reosurce manager that can notify the application 
> about the wireless link status. Since the application runs over IP,
> the wireless link manager needs to communicate with the IP level 
> signaling entity in order to do this notification. 
> [GF]
> 
> /Gabor
> 
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis
> 


-- 
| Paulo Mendes
| www.cs.columbia.edu/~mendes


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



From daemon@ns.ietf.org  Thu Jan 24 16:38: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 QAA06699
	for <nsis-archive@odin.ietf.org>; Thu, 24 Jan 2002 16:38:13 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id QAA25458
	for nsis-archive@odin.ietf.org; Thu, 24 Jan 2002 16: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 QAA24659;
	Thu, 24 Jan 2002 16:28: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 QAA24630
	for <nsis@ns.ietf.org>; Thu, 24 Jan 2002 16:28:19 -0500 (EST)
Received: from kcmso1.proxy.att.com (kcmso1.att.com [192.128.133.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06457
	for <nsis@ietf.org>; Thu, 24 Jan 2002 16:28:12 -0500 (EST)
Received: from attrh1i.attrh.att.com ([135.71.62.10])
	by kcmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id g0OLRVn22360
	for <nsis@ietf.org>; Thu, 24 Jan 2002 16:27:42 -0500 (EST)
Received: from occlust04evs1.ugd.att.com (135.71.164.12) by attrh1i.attrh.att.com (5.5.029)
        id 3C0BA3A50028101A; Thu, 24 Jan 2002 16:26:44 -0500
content-class: urn:content-classes:message
Subject: RE: [NSIS] Support needed for Throughput Adaptive QoS in wireless
Date: Thu, 24 Jan 2002 16:26:44 -0500
Message-ID: <62DA45D4963FA747BA1B253E266760F9012EBF29@OCCLUST04EVS1.ugd.att.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Thread-Topic: [NSIS] Support needed for Throughput Adaptive QoS in wireless
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
Thread-Index: AcGlGvPzW5J3GBELEdaSygAAwCUaDwAAOimQ
From: "Roy, Radhika R, ALASO" <rrroy@att.com>
To: "Paulo Mendes" <mendes@cs.columbia.edu>
Cc: <john.loughney@nokia.com>, <Ruediger.Geib@t-systems.com>, <nsis@ietf.org>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id QAA24631
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

Agreed. More inputs inline [RRR].

-----Original Message-----
From: Paulo Mendes [mailto:mendes@cs.columbia.edu]
Sent: Thursday, January 24, 2002 4:06 PM
To: Roy, Radhika R, ALASO
Cc: john.loughney@nokia.com; Ruediger.Geib@t-systems.com; nsis@ietf.org
Subject: Re: [NSIS] Support needed for Throughput Adaptive QoS in
wireless




Roy, Radhika R, ALASO wrote:

> Inline [RRR]
> 
> -----Original Message-----
> From: Paulo Mendes [mailto:mendes@cs.columbia.edu]
> Sent: Tuesday, January 22, 2002 9:17 PM
> To: Roy, Radhika R, ALASO
> Cc: john.loughney@nokia.com; Ruediger.Geib@t-systems.com; nsis@ietf.org
> Subject: Re: [NSIS] Support needed for Throughput Adaptive QoS in
> wireless
> 
> 
> There are references in this thread to adaptive applications and 
> applications that require re-negotiation of QoS parameters. However 
> these are two different type of applications.
> I agree with you that re-negotiation require extra signalling from NSIS. 
> However this extra burden don't exist with adaptive applications, which 
> I think only require to be notified by NSIS about the available network 
> quality... So the requirements imposed to NSIS by these two types of 
> applications are different.
> 
> [RRR] Not really. We do not know what is the definition of adaptive application (can you cite an example that is being used?). If we assume that an adaptive application is able to adapt the QOS in accordance to the needs of the lower layer QOS, even then NSIS QOS will be able to satisfy its needs. Because the adaptive application, as I understand from your term with limited knowledge, will not use all capabilities of the NSIS QOS. It will rather will use a sub-set of the NSIS QOS capability.
 

[PM] By adaptive applications I mean applications that have the 
capability to adjust the rate they are using depending upon the 
available network resources. For this they need to be notified by the 
network about the quality level they are entitle to during the session.
As an example of an adaptive mechanism I can mention RLM from Steve 
McCanne as receiver-driven and MLDA from Dorgham Sisalem as 
source-driven. I can also mention an application that allows 
receiver-driven adaptation since receivers can adjust the video quality 
adjusting the number of video layers they receive: Rendez-Vous 
(http://www.gaia-interactive.com/rv/)
Therefore, I think adaptive applications support should be considered in 
  the NSIS Framework, as was proposed by David Partain.

[RRR] Yes, it is quite possible even in the simple codecs in multimedia conferencing even without layer coding. For example, codecs can send signals among themselves to measure delay for synchronization or flow control signal (e.g., buffer overflow etc.). This kind of signaling among the codecs will also allow to predict what rate/bandwidth is available in the lower layer (or even in the presentation [codec] layer) and codec's rate/flow needs to be adjusted accordingly (as if a kind of flow control mechanism used similar to the TCP layer).


> [RRR] It is also not clear how an adaptive application will behave when QOS needs to be agreed upon between the two parties. Can you please provide some examples to know their behavior?


[PM] During setup I think they might behave exactly as the other 
applications, i.e., they will try to negotiate a quality level with the 
network. I only meant that during the session, adaptive applications 
differ from applications that require re-negotiation since the latter 
will require extra signalling.

[RRR] So, it is a simplistic case because there is an implicit agreement between the users that if the network signals to them whatever rate/bandwidth available after the session setup will be OK for them and they do not need to re-negotiate. Consequently, NSIS doe not need to send any extra signaling for negotiations. Users applications will have to a hook to do so and no new works are needed in NSIS QOS.

Cheers
Paulo


> Roy, Radhika R, ALASO wrote:
> 
> 
>>Hi, John:
>>
>>I agree with you and like to add a little more [RRR].
>>
>>Best regards,
>>Radhika
>>
>>


-- 
| Paulo Mendes
| www.cs.columbia.edu/~mendes

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



From daemon@ns.ietf.org  Thu Jan 24 17:07: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 RAA07690
	for <nsis-archive@odin.ietf.org>; Thu, 24 Jan 2002 17:07:23 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id RAA27352
	for nsis-archive@odin.ietf.org; Thu, 24 Jan 2002 17:07: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 QAA26315;
	Thu, 24 Jan 2002 16:56: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 QAA26282
	for <nsis@ns.ietf.org>; Thu, 24 Jan 2002 16:56:20 -0500 (EST)
Received: from sierra.seas.upenn.edu (root@sierra.seas.upenn.edu [158.130.64.180])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07350
	for <nsis@ietf.org>; Thu, 24 Jan 2002 16:56:15 -0500 (EST)
Received: from cs.columbia.edu (DHCP64-23.SEAS.UPENN.EDU [158.130.64.102])
	by sierra.seas.upenn.edu (8.9.3/8.9.3) with ESMTP id QAA24753;
	Thu, 24 Jan 2002 16:56:13 -0500 (EST)
Message-ID: <3C508301.7040206@cs.columbia.edu>
Date: Thu, 24 Jan 2002 16:56:17 -0500
From: Paulo Mendes <mendes@cs.columbia.edu>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1
X-Accept-Language: en-us
MIME-Version: 1.0
To: Ping Pan <pingpan@juniper.net>
CC: fu@ee.tu-berlin.de, David.Partain@ericsson.com, NSIS <nsis@ietf.org>
Subject: Re: [NSIS] Framework & requirements part of the "Two kinds of  requirements" thread
References: <0GQD001M6YBEYP@mbb1.ericsson.se> <3C4EF853.B10F8796@ee.tu-berlin.de> <3C4F0560.20508@juniper.net>
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 Ping

Comments below [PM]

Ping Pan wrote:

> Xiaoming Fu wrote:
> 
>> Hi David,
>>
>> A great work to summarize these up-to-date discussions!
>>
>>
>>> The big issue there is what part of this we should solve here.
>>> Should we concentrate specifically on the application/host
>>> to network signalling?  I think not and others have agreed.
>>> Should we try to design something that goes end to end?  If we
>>> do that, do we have a "chicken and egg" problem of needing to
>>> have the technology everywhere for things to work?
>>>
>>
>> IMO end to end is more desired in NSIS. To attain this we may allow 
>> signaling from host to edge, from edge to edge, from hop to hop, etc. 
>> As for the "chicken and egg" problem, I believe
>> some kind of "migration" may also be developed later, e.g., "NSIS 
>> tunnel" for non-NSIS clouds depending on the needs.
>>
> 
> 
> Before we define end-to-end, edge-to-edge and domain-to-domain, ask the 
> following:
> 
> - why do we signal in the first place?
> - where do we need to signal?
> - will signaling work in provider's networks?
> 
> We signal because there is no QoS when we are using some inter-active 
> real-time applications. Since most of the Internet traffic is not within 
> the scope of this "inter-active" and "real-time", let's not consider a 
> kitchen-sink signaling protocol.


[PM] Probably an approach "one solution fits all problems" isn't the 
best one. And I don't think (if I'm wrong, please correct me) that NSIS 
wants to signal all kind of traffic. That's why this discussion about 
requirements is needed.

 
> Also, let's be careful with adaptive applications. They look very nice 
> on paper, but when you see what type of switches are used interfacing 
> between voice networks and the Internet, you gotta be kidding me to 
> insist on adaptiveness for your traffic....


[PM] I don't know about others, but when I speak about adaptive 
applications I'm thinking of 100% IP networks.


> Currently, most of the backbone networks are over-provisioned, so no 
> serious signaling is required yet. End-to-end signaling is very 
> attractive to the end users, but the providers will not allow the users 
> to tell the routers how much to reserve. In fact, I doubt the providers 
> will listen to anything that end-user are throwing at them. So other 
> than some end-to-end measurement-based approach, I don't see e2e 
> signaling will fly in the present network.


[PM] Allow me to disagree... Are you mentioning US over-provided 
networks, or networks in other geographic locations? And even if you're 
only thinking in an US Internet, can you tell me how can this 
over-provision take place?
I agree that network providers can't engineer their network to satisfy 
every single client reclamation. That's why clients (receivers) with 
adaptive applications are useful to network providers. The network 
notify about their capabilities and the clients deal with it (adapt, 
leave session, ...).
However network providers should listen to the market (let's say content 
providers) besides measuring their clients traffic, if they want to grab 
more clients.


> The place where we need signaling is inside the access networks. This is 
> the place where the providers have no incentive to over-provision (to 
> flat-rate users? please), and this is the place where we may see 
> resource shortage.


[PM] Probably we also need signalling between providers network 
(edge-to-edge?), since congestion probably will also take place there. I 
don't work for a network provider, so this is only a guess.


> Finally, the providers are motivated by money to provide any additional 
> service. Unless the traffic that they are carrying worth something, they 
> will never deploy some extra "stuff" inside the network. So what's worth 
> money? ....


[PM] Okey.. But if network providers don't develop new services how can 
they expect clients to use them, if they don't exist?


> - voice traffic! I am not only talking about VoIP; I am talking all the 
> voice traffic that use the Internet infrastructure.
> 
> - wireless traffic: users packets are not landed inside the backbone, so 
> the access network needs to do more to those flows.
> 
> - VPN (an over-used term :-)): but some users want to have QoS 
> reservation even though they are sending any traffic. Not for any 
> technical reason, it's a business reason. Have you seen the amount of 
> traffic in a SNA network, and how much they have been charged? :-)
> 
> In conclusion, IMHO, NSIS should
> 
> 1. focus on edge-to-edge signaling;


> 2. focus on a small set of applications to deal with;


> 3. focus on the relevant provider impact;

Network or content providers?


> 4. don't do a kitchen-sink blahblah that lasts for years.

Cheers
Paulo


> 3 cents,
> 
> - Ping Pan
> 
> 
> 
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis


-- 
| Paulo Mendes
| www.cs.columbia.edu/~mendes


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



From daemon@ns.ietf.org  Thu Jan 24 17:45:26 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08661
	for <nsis-archive@odin.ietf.org>; Thu, 24 Jan 2002 17:45:26 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id RAA29667
	for nsis-archive@odin.ietf.org; Thu, 24 Jan 2002 17:45:30 -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 RAA29189;
	Thu, 24 Jan 2002 17:35: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 RAA29112
	for <nsis@ns.ietf.org>; Thu, 24 Jan 2002 17:35:02 -0500 (EST)
Received: from sierra.seas.upenn.edu (root@sierra.seas.upenn.edu [158.130.64.180])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08471
	for <nsis@ietf.org>; Thu, 24 Jan 2002 17:34:57 -0500 (EST)
Received: from cs.columbia.edu (DHCP64-23.SEAS.UPENN.EDU [158.130.64.102])
	by sierra.seas.upenn.edu (8.9.3/8.9.3) with ESMTP id RAA29875;
	Thu, 24 Jan 2002 17:34:57 -0500 (EST)
Message-ID: <3C508C15.4050002@cs.columbia.edu>
Date: Thu, 24 Jan 2002 17:35:01 -0500
From: Paulo Mendes <mendes@cs.columbia.edu>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1
X-Accept-Language: en-us
MIME-Version: 1.0
To: "Allen, Keith" <kallen@tri.sbc.com>
CC: nsis@ietf.org
Subject: Re: [NSIS] Two kinds of requirements
References: <905A1C4ABF353F4C8CC16FA9F53DD0D62A7016@TRIMAIL2.ad.tri.sbc.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

I agree with Keith. When I mentioned one-to-many applications I wasn't 
trying to complicate things and delay deliverables. However completely 
neglect other type of applications except one-to-one, probably we're 
restricting NSIS to IP telephony.

I was seeing NSIS to be used by multimedia applications, which require 
more then best effort quality. From this group I think video 
applications will be more one-to-many than one-to-one.

So, we should make clear in this phase what type of traffic NSIS will 
deal with.

If NSIS establish a sender-receiver negotiation for sessions setup, I 
don't see how can we use other applications beside one-to-one.
I think that a more flexible setup should be used. The approach mention 
by Keith seems more flexible and not very complicated. In the end it 
divides the source-receiver negotiation in:
a) a source-network negotiation, where the content provider can 
negotiate the minimum quality he wants to sell his service with.
b) a receiver-network "negotiation" where the receiver joins the session 
and:
   b.1) accepts the quality level of the session or tries to negotiate 
a quality increase during the setup, if it is intolerant to quality 
oscillations;
   b.2) accepts the quality level and adapt to posterior quality 
oscillations during the session, if it is tolerant to quality oscillations.

Cheers
Paulo

Allen, Keith wrote:

> Hi Paulo,
> 
> 
>>What happens with one-to-many applications like video-on-demand or 
>>InternetTV? In this case you can't establish a session level QoS 
>>agreement between provider and clients before the session 
>>starts (and so before the reservation of resources) because you would 
>>not know all your clients at that time.
>>
> 
> Currently, I do not see this as a major part of NSIS.  I think this
> should be held for later consideration.  I do not see that VOD or
> Internet TV as burning issues.  I'm hoping we focus on one-to-one
> signaling.
> 
> John
> 
> 
> Actually, I would like to see NSIS address this issue.  I don't see all the
> clients have to be known at the beginning of the session, though.  The
> content provider can merely instantiate the session, and others can join or
> drop as they wish (or be added and dropped by the content provider, if
> that's how we decide we want it to work).  As far as determining what the
> QoS of the session will be, that would be up to the content provider.
> 
> Keith Allen
> SBC Technology Resources
> 9505 Arboretum Blvd.
> Austin, TX 78759
> (512) 372-5741
> kallen@tri.sbc.com
> 
>  -----Original Message-----
> From: 	john.loughney@nokia.com [mailto:john.loughney@nokia.com] 
> Sent:	Thursday, January 24, 2002 10:52 AM
> To:	mendes@cs.columbia.edu
> Cc:	nsis@ietf.org
> Subject:	RE: [NSIS] Two kinds of requirements
> 
> Hi Paulo,
> 
> 
>>What happens with one-to-many applications like video-on-demand or 
>>InternetTV? In this case you can't establish a session level QoS 
>>agreement between provider and clients before the session 
>>starts (and so before the reservation of resources) because you would 
>>not know all your clients at that time.
>>
> 
> Currently, I do not see this as a major part of NSIS.  I think this
> should be held for later consideration.  I do not see that VOD or
> Internet TV as burning issues.  I'm hoping we focus on one-to-one
> signaling.
> 
> 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
> 


-- 
| Paulo Mendes
| www.cs.columbia.edu/~mendes


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



From daemon@ns.ietf.org  Thu Jan 24 17:55: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 RAA08889
	for <nsis-archive@odin.ietf.org>; Thu, 24 Jan 2002 17:55:34 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id RAA00095
	for nsis-archive@odin.ietf.org; Thu, 24 Jan 2002 17:55: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 RAA29713;
	Thu, 24 Jan 2002 17:46: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 RAA29681
	for <nsis@ns.ietf.org>; Thu, 24 Jan 2002 17:46: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 RAA08680
	for <nsis@ietf.org>; Thu, 24 Jan 2002 17:46:00 -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 g0OMm9T20917;
	Thu, 24 Jan 2002 16:48:09 -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 g0OMjSY07458;
	Thu, 24 Jan 2002 16:45:29 -0600 (CST)
Received: by TRIMAIL2.ad.tri.sbc.com with Internet Mail Service (5.5.2653.19)
	id <ZND3JFLF>; Thu, 24 Jan 2002 16:45:56 -0600
Message-ID: <905A1C4ABF353F4C8CC16FA9F53DD0D638B9B2@TRIMAIL2.ad.tri.sbc.com>
From: "Schneider, Marco" <schneider@tri.sbc.com>
To: "'Georgios Karagiannis (ELN)'" <Georgios.Karagiannis@eln.ericsson.se>,
        "Chen, Weijing" <wchen@tri.sbc.com>
Cc: NSIS Mailing List <nsis@ietf.org>
Subject: RE: [NSIS] Framework & requirements part of the "Two kinds of req
	 uirements" thread
Date: Thu, 24 Jan 2002 16:45:54 -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 Georgios,

Please see my comments inline.

> -----Original Message-----
> From: Georgios Karagiannis (ELN)
> [mailto:Georgios.Karagiannis@eln.ericsson.se]
> Sent: Thursday, January 24, 2002 3:33 AM
> To: Chen, Weijing
> Cc: NSIS Mailing List
> Subject: RE: [NSIS] Framework & requirements part of the "Two kinds of
> req uirements" thread
> 
> 
> Hi Weijing
> 
> Please see my comments in line.
> 
> [WC]>> 1. David's proposal of working requirement within so 
> [WC]>> called "framework" is putting the cart before the horse. 
> [WC]>> Because we think one framework is cool,
> [WC]>> we confine our requirements and use cases within 
> [WC]>> that framework. It is totally unacceptable.
> 
> In principle I agree with you. The framework should not be used
> to  define the NSIS requirements. The NSIS requirements should be
> produced based on different QoS needs of certain application types.

[MS] So we are in agreement in principle. 

> However, the mentioned framework can be used to decompose a 
> complex QoS problem into certain simpler QoS problems.

> 
> [WC]>> 2. Figure
> [WC]>>  In above picture, [host] has to assemble and process 
> [WC]>>  the [ehop], [eedge] in addition to [ehost] part. How will 
> [WC]>>  the [host] correctly assemble and process
> [WC]>> the [ehop] and [eedge] pieces? It implies that [host] has 
> [WC]>> global view of [ehop] and [eedge] in every domains. 
> [WC]>> to happen, there must be another protocol to exchange network 
> [WC]>> information and pass whole network view
> [WC]>> to [host]. 
> 
> No it is not required that the "host" has a global view 
> of the domains. The way of how this NSIS protocol finds the edges
> and the hops is similar with the way the RSVPv1 protocol does it.

[MS] So going back to my comments in a previous email, the "framework" does
have an implementation/solution in mind along the lines of RSVP and imposes
this on the host. Not only is this getting the cart before the horse, but I
am not even sure I like what's in the cart. Or is there something that has
still not been clarified? 

> 
> [WC] >> Now what about "glue"? Shall NSIS do it? Part of me 
> [WC] >> says yes, another says
> [WC] >> no. I am 50/50.
> 
> Please note that the NSIS charter mentions that a "framework" 
> draft should be specified by March 2002.

[MS] To the extent that the "framework" draft will include possible
approaches to solving the problem we can include yours for comparison. I
think that is where it may fit in.

> 
> Best regards,
> Georgios
> 
> 
> -----Original Message-----
> From: Chen, Weijing [mailto:wchen@tri.sbc.com]
> Sent: donderdag 24 januari 2002 9:43
> To: David.Partain@ericsson.com
> Cc: NSIS Mailing List
> Subject: RE: [NSIS] Framework & requirements part of the "Two kinds of
> req uirements" thread
> 
> 
> 
> I have fundamental disagreement with David's point.
> 
> 1. David's proposal of working requirement within so called 
> "framework" is
> putting the cart before the horse. Because we think one 
> framework is cool,
> we confine our requirements and use cases within that framework. It is
> totally unacceptable.
> 
> 2. 
> 
> |-----|                                                  |-----|
> |ehost|<------------------------------------------------>|ehost|
> |-----|                                                  |-----|
> |     |                                                  |     |
> |-----|            |-----|            |-----|            |-----|
> |eedge|<---------->|eedge|<---------->|eedge|<---------->|eedge|
> |-----|            |-----|            |-----|            |-----|
> |     |            |     |            |     |            |     |
> |-----|   |----|   |-----|   |----|   |-----|   |----|   |-----|
> |ehop |<->|ehop|<->|ehop |<->|ehop|<->|ehop |<->|ehop|<->|ehop |
> |-----|   |----|   |-----|   |----|   |-----|   |----|   |-----|
>  host    interior   edge    interior   edge     interior  host
>          w/in domain       w/in domain        w/in domain
> 
> In above picture, [host] has to assemble and process the 
> [ehop], [eedge] in
> addition to [ehost] part. How will the [host] correctly 
> assemble and process
> the [ehop] and [eedge] pieces? It implies that [host] has 
> global view of
> [ehop] and [eedge] in every domains. For this to happen, there must be
> another protocol to exchange network information and pass 
> whole network view
> to [host]. So on, and so on, and sooner we know that we 
> revive an ultimate
> engineer dream: a protocol for all and do all. Be there, done 
> that, and
> failed. Otherwise we wouldn't be here to debate about what 
> NSIS should be.
> 
> The right picture should be (if you insist talking about the framework
> before requirement):
> 
>                    |-----|   |----|   |-----|  
>                    |ehop |<->|ehop|<->|ehop |   
>                    |-----|   |----|   |-----| 
>                    |     |            |     |
>                    |-----|            |-----|
>                    |glue |            |glue |
>                    |-----|            |-----|
>                    |     |            |     |
> |-----|            |-----|            |-----|            |-----|
> |ehost|<---------->|ehost|<---------->|ehost|<---------->|ehost|
> |-----|            |-----|            |-----|            |-----|
>  host                edge     hop      edge                host
>            domain            domains             domain
>                              (inter and
>                               intra)
>            NSIS                                   NSIS
> 
> Now what about "glue"? Shall NSIS do it? Part of me says yes, 
> another says
> no. I am 50/50.
> 
> --
> Weijing Chen
> SBC Technology Resources
> 9505 Arboretum Blvd.
> Austin, TX 78759
> 512 372 5710
> wchen@tri.sbc.com
> 
> 
> 
> -----Original Message-----
> From: David Partain [mailto:David.Partain@ericsson.com] 
> Sent: Wednesday, January 23, 2002 3:58 AM
> To: NSIS Mailing List
> Subject: [NSIS] Framework & requirements part of the "Two kinds of
> requirements" thread
> 
> Greetings all,
> 
> I'd like to offer my take on part of the thread "Two kinds
> of requirements" to see if we can collectively reach any sort
> of conclusion based on what's been written.  I doubt I'll say
> anything new, but perhaps it'll help summarize a bit.
> 
> To cut to the chase, the conclusion of this mail is that
> I think:
> 
>  - we should use the "framework" below as the starting point of
>    framework discussions
>  - the requirements should grow from use cases of particular
>    applications that will use the network
> 
> The original mail postulated that people are wanting to work
> on two kinds of requirements here:
> 
>  - end-host to end-host, or application to application
>    signalling
> 
>  - transport level signalling
> 
> From that point, there has been a hearty debate about whether
> this indeed is true, as well as a host of other issues.
> 
> I think the following points have been made, amongst others:
> 
>  - It should support the use of throughput adaptive applications
>    and the ability for a traffic flow to express its QoS
>    preferences with regard to the throughput values which it
>    may be allocated.
> 
>  - One part of the thread was about whether RSVP and related
>    work (e.g., RFC 2998), or perhaps SDPng, are suitable
>    solutions.  While it's obvious that we need to learn from
>    and perhaps start from one of these efforts in working on
>    NSIS, it also seems clear that we shouldn't start working
>    on that until the requirements are done.
> 
>  - There's no chance we'll create a single one-size-fits-all
>    application-related signalling protocol that will be used
>    by everyone.  That seems very clear.
> 
>  - There's a need for something transport independent that can
>    help signal QoS needs across multiple domains in order
>    to help the application-related signalling protocols do
>    their thing.
> 
> The big issue there is what part of this we should solve here.
> Should we concentrate specifically on the application/host
> to network signalling?  I think not and others have agreed.
> Should we try to design something that goes end to end?  If we
> do that, do we have a "chicken and egg" problem of needing to
> have the technology everywhere for things to work?
> 
> A case has been made that the goal should be to create a
> signalling protocol that has different kinds of components
> appropriate to different parts of the problem.  Georgios K.
> proposed the following figure, which I like quite a lot and
> which others have said is good, as a way of looking at it:
> 
> |-----|                                                  |-----|
> |ehost|<------------------------------------------------>|ehost|
> |-----|                                                  |-----|
> |     |                                                  |     |
> |-----|            |-----|            |-----|            |-----|
> |eedge|<---------->|eedge|<---------->|eedge|<---------->|eedge|
> |-----|            |-----|            |-----|            |-----|
> |     |            |     |            |     |            |     |
> |-----|   |----|   |-----|   |----|   |-----|   |----|   |-----|
> |ehop |<->|ehop|<->|ehop |<->|ehop|<->|ehop |<->|ehop|<->|ehop |
> |-----|   |----|   |-----|   |----|   |-----|   |----|   |-----|
>  host    interior   edge    interior   edge     interior  host
>          w/in domain       w/in domain        w/in domain
> 
>    ehost = everyhost
>    eedge = everyedge
>    ehop  = everyhop
> 
> NSIS protocol decomposition:
> 
>  * A "host" could be an end host or a proxy.  It can process
>    and use the "everyhost", "everyedge", and "everyhop"
>    protocol components.
> 
>  * An "edge" can be a Diffserv edge, MPLS edge, etc.  It can
>    process and use the "everyedge", and "everyhop" protocol
>    components. The "everyhost" protocol component is not
>    processed (used or checked) but is carried onward.
> 
>  * An "interior within domain" can be any router within
>    a domain.  It can process and use only the "everyhop"
>    protocol component.  The "everyhost" and "everyedge"
>    protocol components are not processed (used or checked)
>    but are carried onward.
> 
> The everyhop bit within a domain provides signalling facilities
> for that particular domain and is very likely to differ from
> the everyhop bit used in the next boarding domain.
> 
> The point of all of this is to get a concatenation of results.
> Each domain is responsible for taking its own decisions in its
> own domain-specific ways.  The concatenation of the everyhop
> decisions within a domain provides the domain's answer.
> The concatenation of the domains' results gives and end to
> end answer that can be used by the everyhost bit.
> 
> I think that having this overall framework -- for lack of a
> better term -- in mind is very helpful.
> 
> If we can agree that this is a reasonable framework to use as
> the basis of discussion, I think that what we need to do is
> to produce a set of requirements for different "applications"
> that will use these networks/this framework.  Indeed, I believe
> this matches Keith Allen's request that requirements be based on
> use cases.  If we know we're going to use the NSIS protocol on
> a cellular wireless network (just to pull an example out of the
> air :-)), then that "use case" implies a set of requirements.
> A different scenario (e.g., the core of the network) implies
> another set of requirements.
> 
> I personally think this is the right way forward and would
> like to see this group move in this direction.
> 
> Georgios added some more thoughts on this topic
> which addressed the applicability and prioritization
> of work.  That can be found in the archive at
> http://www1.ietf.org/mail-archive/working-groups/nsis/current/
msg00418.html

I realize that I haven't covered everyone's particular topic
in this thread, but perhaps it'll help focus on one part of
the discussion.  If someone wants to summarize some other
sub-thread, that would be great...

Cheers,

dlp

ps. I think it would be very useful if Subject lines could more
accurately reflect the topic covered in the mail.  Long threads
with the same subject and covering a multitude of topics is
difficult to follow...

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

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

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

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



From daemon@ns.ietf.org  Thu Jan 24 18:20: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 SAA09464
	for <nsis-archive@odin.ietf.org>; Thu, 24 Jan 2002 18:20:18 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id SAA01411
	for nsis-archive@odin.ietf.org; Thu, 24 Jan 2002 18:20: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 SAA01120;
	Thu, 24 Jan 2002 18:11: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 SAA01090
	for <nsis@ns.ietf.org>; Thu, 24 Jan 2002 18:11:04 -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 SAA09257
	for <nsis@ietf.org>; Thu, 24 Jan 2002 18:11:00 -0500 (EST)
Received: from juniper.net (panther.juniper.net [172.17.12.226])
	by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g0ON9Y652401;
	Thu, 24 Jan 2002 15:09:34 -0800 (PST)
	(envelope-from pingpan@juniper.net)
Message-ID: <3C50942E.3080104@juniper.net>
Date: Thu, 24 Jan 2002 15:09:34 -0800
From: Ping Pan <pingpan@juniper.net>
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: Paulo Mendes <mendes@cs.columbia.edu>
CC: fu@ee.tu-berlin.de, David.Partain@ericsson.com, NSIS <nsis@ietf.org>
Subject: Re: [NSIS] Framework & requirements part of the "Two kinds of  requirements" thread
References: <0GQD001M6YBEYP@mbb1.ericsson.se> <3C4EF853.B10F8796@ee.tu-berlin.de> <3C4F0560.20508@juniper.net> <3C508301.7040206@cs.columbia.edu>
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

Paulo,

How are you!

Paulo Mendes wrote:

>> Also, let's be careful with adaptive applications. They look very nice 
>> on paper, but when you see what type of switches are used interfacing 
>> between voice networks and the Internet, you gotta be kidding me to 
>> insist on adaptiveness for your traffic....
> 
> 
> 
> [PM] I don't know about others, but when I speak about adaptive 
> applications I'm thinking of 100% IP networks.
> 


The problem is that much of the voice traffic flowing over the Internet 
has nothing to do with the native Internet applications. Many providers 
setup tunnels through their backbones and transport non-IP packets. The 
access points are not pure IP boxes. They may be some ancient and 
expensive Luent switches. If you ask the switches to run some fancy 
adaptive schemes to all the traffic, they may crash.

> 
>> Currently, most of the backbone networks are over-provisioned, so no 
>> serious signaling is required yet. End-to-end signaling is very 
>> attractive to the end users, but the providers will not allow the 
>> users to tell the routers how much to reserve. In fact, I doubt the 
>> providers will listen to anything that end-user are throwing at them. 
>> So other than some end-to-end measurement-based approach, I don't see 
>> e2e signaling will fly in the present network.
> 
> 
> 
> [PM] Allow me to disagree... Are you mentioning US over-provided 
> networks, or networks in other geographic locations? And even if you're 
> only thinking in an US Internet, can you tell me how can this 
> over-provision take place?


(I thought I wrote a paper on this in my past life....:-)) Yes, all 
backbones have "hot" spots, and have congestion. But the backbone 
problems can be (or have been) addressed via RSVP-TE. Yes, we have 
short-time outage in the backbone due to frequent upgrade and router 
crash. That's why we have worked very hard on backbone traffic 
redundency (fast reroute, graceful restart.....) issues. So far, I have 
a pretty good feeling on resource management within the backbone. The 
focus is now on the edge and the access. I am hoping NSIS is the place 
to do it.


> I agree that network providers can't engineer their network to satisfy 
> every single client reclamation. That's why clients (receivers) with 
> adaptive applications are useful to network providers. The network 
> notify about their capabilities and the clients deal with it (adapt, 
> leave session, ...).


The "receivers" can be some monitoring boxes arranged by the providers 
to monitor the traffic in/out of the network. If things are not OK, 
these boxes may play some rotuing tricks to redirect traffic from the 
edge. I am not sure they are regular users.


> 
>> Finally, the providers are motivated by money to provide any 
>> additional service. Unless the traffic that they are carrying worth 
>> something, they will never deploy some extra "stuff" inside the 
>> network. So what's worth money? ....
> 
> 

> 
> [PM] Okey.. But if network providers don't develop new services how can 
> they expect clients to use them, if they don't exist?
> 


I have just listed some of the services below. IMHO, the current state 
of the Internet is not about "new" services, or "new" economy to that 
matter. The Internet is a new media to transport traffic, like we have 
been doing via post office, SNA, phone networks, Frame/ATM networks.... 
The trick is to send the same old information efficiently.... Plus the 
Internet needs to evolve itself to carry traffic some future 
applications when they come..


> 
>> - voice traffic! I am not only talking about VoIP; I am talking all 
>> the voice traffic that use the Internet infrastructure.
>>
>> - wireless traffic: users packets are not landed inside the backbone, 
>> so the access network needs to do more to those flows.
>>
>> - VPN (an over-used term :-)): but some users want to have QoS 
>> reservation even though they are sending any traffic. Not for any 
>> technical reason, it's a business reason. Have you seen the amount of 
>> traffic in a SNA network, and how much they have been charged? :-)
>>

- Ping


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



From daemon@optimus.ietf.org  Thu Jan 24 23:10: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 XAA15503
	for <nsis-archive@odin.ietf.org>; Thu, 24 Jan 2002 23:10:42 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id XAA13069
	for nsis-archive@odin.ietf.org; Thu, 24 Jan 2002 23:10: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 WAA12376;
	Thu, 24 Jan 2002 22:58: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 WAA12305
	for <nsis@optimus.ietf.org>; Thu, 24 Jan 2002 22:58:49 -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 WAA15368
	for <nsis@ietf.org>; Thu, 24 Jan 2002 22:58:45 -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 g0P40tT21621;
	Thu, 24 Jan 2002 22:00:55 -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 g0P3wEH18817;
	Thu, 24 Jan 2002 21:58:15 -0600 (CST)
Received: by TRIMAIL2.ad.tri.sbc.com with Internet Mail Service (5.5.2653.19)
	id <ZND3JGFX>; Thu, 24 Jan 2002 21:58:41 -0600
Message-ID: <905A1C4ABF353F4C8CC16FA9F53DD0D6322446@TRIMAIL2.ad.tri.sbc.com>
From: "Chen, Weijing" <wchen@tri.sbc.com>
To: "'Georgios Karagiannis (ELN)'" <Georgios.Karagiannis@eln.ericsson.se>
Cc: NSIS Mailing List <nsis@ietf.org>
Subject: RE: [NSIS] Framework & requirements part of the "Two kinds of req
	 uirements" thread
Date: Thu, 24 Jan 2002 21:58:41 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: nsis-admin@ietf.org
Errors-To: nsis-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Next Steps in Signaling <nsis.ietf.org>
X-BeenThere: nsis@ietf.org

Georgios,

>>In principle I agree with you. The framework should not be used
>>to  define the NSIS requirements. The NSIS requirements should be
>>produced based on different QoS needs of certain application types.

Thank you.

>>No it is not required that the "host" has a global view 
>>of the domains. The way of how this NSIS protocol finds the edges
>>and the hops is similar with the way the RSVPv1 protocol does it.

So we still expose the network interior to host. Then what is the benefit of
this for host? Compare the following stacks that the host has to handle:

|-----|
|ehost|
|-----|
|     |
|-----|
|eedge|
|-----|
|     |
|-----|
|ehop |
|-----|
 host    

vs.

|-----|
|ehost|
|-----|
 host                

Cleary the latter one is much simpler.

Now let's take a look what is the typical sequence of end-to-end QoS service
delivery chain:

[src ehost]->hello, edge, I want so and so [original QoS] to so and so
place.
[incoming eedge]->ok, host, just a millisecond.
       [background] glueing the [original QoS] to [ehop QoS] in first
[ehop], 
                    [ehop] passes [ehop QoS] and [original QoS] to next
                    [ehop], on and on to outgoing [eedge].
[outgoing eedge]->hello, ehost, here is [original QoS] request from
                  [src ehost], will you take it?
[dest ehost]->ok, accept.
[outgoing eedge]-->[ehop]-->[incoming eedge]...
[incoming eedge]->host, you are ready to go.
[src ehost]->ok...

In the above sequence, [ehost] only deals with [eedge] directly, not [ehop].
So why do we want to force [ehop] information (i.e. network internal
information) to [ehost]? If we are doing so, [ehost] would say "Ooo, I am
stuffed, choked, ok, I am giving up. I don't want QoS." Which is exactly
where we are today.

So please don't stuff the poor [ehost] with anything else except he
absoultly need for [ehost] to [eedge] request and response. Thank you very
much.

--
Weijing Chen
SBC Technology Resources
9505 Arboretum Blvd.
Austin, TX 78759
512 372 5710
wchen@tri.sbc.com


-----Original Message-----
From: Georgios Karagiannis (ELN)
[mailto:Georgios.Karagiannis@eln.ericsson.se] 
Sent: Thursday, January 24, 2002 3:33 AM
To: Chen, Weijing
Cc: NSIS Mailing List
Subject: RE: [NSIS] Framework & requirements part of the "Two kinds of req
uirements" thread

Hi Weijing

Please see my comments in line.

[WC]>> 1. David's proposal of working requirement within so 
[WC]>> called "framework" is putting the cart before the horse. 
[WC]>> Because we think one framework is cool,
[WC]>> we confine our requirements and use cases within 
[WC]>> that framework. It is totally unacceptable.

In principle I agree with you. The framework should not be used
to  define the NSIS requirements. The NSIS requirements should be
produced based on different QoS needs of certain application types.
However, the mentioned framework can be used to decompose a 
complex QoS problem into certain simpler QoS problems.

[WC]>> 2. Figure
[WC]>>  In above picture, [host] has to assemble and process 
[WC]>>  the [ehop], [eedge] in addition to [ehost] part. How will 
[WC]>>  the [host] correctly assemble and process
[WC]>> the [ehop] and [eedge] pieces? It implies that [host] has 
[WC]>> global view of [ehop] and [eedge] in every domains. 
[WC]>> to happen, there must be another protocol to exchange network 
[WC]>> information and pass whole network view
[WC]>> to [host]. 

No it is not required that the "host" has a global view 
of the domains. The way of how this NSIS protocol finds the edges
and the hops is similar with the way the RSVPv1 protocol does it.

[WC] >> Now what about "glue"? Shall NSIS do it? Part of me 
[WC] >> says yes, another says
[WC] >> no. I am 50/50.

Please note that the NSIS charter mentions that a "framework" 
draft should be specified by March 2002.

Best regards,
Georgios


-----Original Message-----
From: Chen, Weijing [mailto:wchen@tri.sbc.com]
Sent: donderdag 24 januari 2002 9:43
To: David.Partain@ericsson.com
Cc: NSIS Mailing List
Subject: RE: [NSIS] Framework & requirements part of the "Two kinds of
req uirements" thread



I have fundamental disagreement with David's point.

1. David's proposal of working requirement within so called "framework" is
putting the cart before the horse. Because we think one framework is cool,
we confine our requirements and use cases within that framework. It is
totally unacceptable.

2. 

|-----|                                                  |-----|
|ehost|<------------------------------------------------>|ehost|
|-----|                                                  |-----|
|     |                                                  |     |
|-----|            |-----|            |-----|            |-----|
|eedge|<---------->|eedge|<---------->|eedge|<---------->|eedge|
|-----|            |-----|            |-----|            |-----|
|     |            |     |            |     |            |     |
|-----|   |----|   |-----|   |----|   |-----|   |----|   |-----|
|ehop |<->|ehop|<->|ehop |<->|ehop|<->|ehop |<->|ehop|<->|ehop |
|-----|   |----|   |-----|   |----|   |-----|   |----|   |-----|
 host    interior   edge    interior   edge     interior  host
         w/in domain       w/in domain        w/in domain

In above picture, [host] has to assemble and process the [ehop], [eedge] in
addition to [ehost] part. How will the [host] correctly assemble and process
the [ehop] and [eedge] pieces? It implies that [host] has global view of
[ehop] and [eedge] in every domains. For this to happen, there must be
another protocol to exchange network information and pass whole network view
to [host]. So on, and so on, and sooner we know that we revive an ultimate
engineer dream: a protocol for all and do all. Be there, done that, and
failed. Otherwise we wouldn't be here to debate about what NSIS should be.

The right picture should be (if you insist talking about the framework
before requirement):

                   |-----|   |----|   |-----|  
                   |ehop |<->|ehop|<->|ehop |   
                   |-----|   |----|   |-----| 
                   |     |            |     |
                   |-----|            |-----|
                   |glue |            |glue |
                   |-----|            |-----|
                   |     |            |     |
|-----|            |-----|            |-----|            |-----|
|ehost|<---------->|ehost|<---------->|ehost|<---------->|ehost|
|-----|            |-----|            |-----|            |-----|
 host                edge     hop      edge                host
           domain            domains             domain
                             (inter and
                              intra)
           NSIS                                   NSIS

Now what about "glue"? Shall NSIS do it? Part of me says yes, another says
no. I am 50/50.

--
Weijing Chen
SBC Technology Resources
9505 Arboretum Blvd.
Austin, TX 78759
512 372 5710
wchen@tri.sbc.com



-----Original Message-----
From: David Partain [mailto:David.Partain@ericsson.com] 
Sent: Wednesday, January 23, 2002 3:58 AM
To: NSIS Mailing List
Subject: [NSIS] Framework & requirements part of the "Two kinds of
requirements" thread

Greetings all,

I'd like to offer my take on part of the thread "Two kinds
of requirements" to see if we can collectively reach any sort
of conclusion based on what's been written.  I doubt I'll say
anything new, but perhaps it'll help summarize a bit.

To cut to the chase, the conclusion of this mail is that
I think:

 - we should use the "framework" below as the starting point of
   framework discussions
 - the requirements should grow from use cases of particular
   applications that will use the network

The original mail postulated that people are wanting to work
on two kinds of requirements here:

 - end-host to end-host, or application to application
   signalling

 - transport level signalling

From that point, there has been a hearty debate about whether
this indeed is true, as well as a host of other issues.

I think the following points have been made, amongst others:

 - It should support the use of throughput adaptive applications
   and the ability for a traffic flow to express its QoS
   preferences with regard to the throughput values which it
   may be allocated.

 - One part of the thread was about whether RSVP and related
   work (e.g., RFC 2998), or perhaps SDPng, are suitable
   solutions.  While it's obvious that we need to learn from
   and perhaps start from one of these efforts in working on
   NSIS, it also seems clear that we shouldn't start working
   on that until the requirements are done.

 - There's no chance we'll create a single one-size-fits-all
   application-related signalling protocol that will be used
   by everyone.  That seems very clear.

 - There's a need for something transport independent that can
   help signal QoS needs across multiple domains in order
   to help the application-related signalling protocols do
   their thing.

The big issue there is what part of this we should solve here.
Should we concentrate specifically on the application/host
to network signalling?  I think not and others have agreed.
Should we try to design something that goes end to end?  If we
do that, do we have a "chicken and egg" problem of needing to
have the technology everywhere for things to work?

A case has been made that the goal should be to create a
signalling protocol that has different kinds of components
appropriate to different parts of the problem.  Georgios K.
proposed the following figure, which I like quite a lot and
which others have said is good, as a way of looking at it:

|-----|                                                  |-----|
|ehost|<------------------------------------------------>|ehost|
|-----|                                                  |-----|
|     |                                                  |     |
|-----|            |-----|            |-----|            |-----|
|eedge|<---------->|eedge|<---------->|eedge|<---------->|eedge|
|-----|            |-----|            |-----|            |-----|
|     |            |     |            |     |            |     |
|-----|   |----|   |-----|   |----|   |-----|   |----|   |-----|
|ehop |<->|ehop|<->|ehop |<->|ehop|<->|ehop |<->|ehop|<->|ehop |
|-----|   |----|   |-----|   |----|   |-----|   |----|   |-----|
 host    interior   edge    interior   edge     interior  host
         w/in domain       w/in domain        w/in domain

   ehost = everyhost
   eedge = everyedge
   ehop  = everyhop

NSIS protocol decomposition:

 * A "host" could be an end host or a proxy.  It can process
   and use the "everyhost", "everyedge", and "everyhop"
   protocol components.

 * An "edge" can be a Diffserv edge, MPLS edge, etc.  It can
   process and use the "everyedge", and "everyhop" protocol
   components. The "everyhost" protocol component is not
   processed (used or checked) but is carried onward.

 * An "interior within domain" can be any router within
   a domain.  It can process and use only the "everyhop"
   protocol component.  The "everyhost" and "everyedge"
   protocol components are not processed (used or checked)
   but are carried onward.

The everyhop bit within a domain provides signalling facilities
for that particular domain and is very likely to differ from
the everyhop bit used in the next boarding domain.

The point of all of this is to get a concatenation of results.
Each domain is responsible for taking its own decisions in its
own domain-specific ways.  The concatenation of the everyhop
decisions within a domain provides the domain's answer.
The concatenation of the domains' results gives and end to
end answer that can be used by the everyhost bit.

I think that having this overall framework -- for lack of a
better term -- in mind is very helpful.

If we can agree that this is a reasonable framework to use as
the basis of discussion, I think that what we need to do is
to produce a set of requirements for different "applications"
that will use these networks/this framework.  Indeed, I believe
this matches Keith Allen's request that requirements be based on
use cases.  If we know we're going to use the NSIS protocol on
a cellular wireless network (just to pull an example out of the
air :-)), then that "use case" implies a set of requirements.
A different scenario (e.g., the core of the network) implies
another set of requirements.

I personally think this is the right way forward and would
like to see this group move in this direction.

Georgios added some more thoughts on this topic
which addressed the applicability and prioritization
of work.  That can be found in the archive at
http://www1.ietf.org/mail-archive/working-groups/nsis/current/msg00418.html

I realize that I haven't covered everyone's particular topic
in this thread, but perhaps it'll help focus on one part of
the discussion.  If someone wants to summarize some other
sub-thread, that would be great...

Cheers,

dlp

ps. I think it would be very useful if Subject lines could more
accurately reflect the topic covered in the mail.  Long threads
with the same subject and covering a multitude of topics is
difficult to follow...

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

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

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



From daemon@optimus.ietf.org  Fri Jan 25 04:06: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 EAA27391
	for <nsis-archive@odin.ietf.org>; Fri, 25 Jan 2002 04:06:51 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id EAA04064
	for nsis-archive@odin.ietf.org; Fri, 25 Jan 2002 04:06: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 EAA03915;
	Fri, 25 Jan 2002 04:02: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 EAA03886
	for <nsis@optimus.ietf.org>; Fri, 25 Jan 2002 04:02:36 -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 EAA27372
	for <nsis@ietf.org>; Fri, 25 Jan 2002 04:02:32 -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 g0P92Ww10378
	for <nsis@ietf.org>; Fri, 25 Jan 2002 10:02:32 +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 <0GQH00J4KL468F@mbb1.ericsson.se> for nsis@ietf.org; Fri,
 25 Jan 2002 10:02:32 +0100 (MET)
Date: Fri, 25 Jan 2002 10:03:04 +0100
From: David Partain <David.Partain@ericsson.com>
Subject: Re: [NSIS] Framework & requirements part of
 the"Two kinds of  requirements" thread
In-reply-to: <0C1353ABB1DEB74DB067ADFF749C4EEF5D9459@esebe004.NOE.Nokia.com>
To: NSIS Mailing List <nsis@ietf.org>
Reply-to: David.Partain@ericsson.com
Message-id: <0GQH00J4QL478F@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: <0C1353ABB1DEB74DB067ADFF749C4EEF5D9459@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 wrote:
dp> If we try to throw every possible problem area into the NSIS
dp> work, this working group will still be talking when we're rolling
dp> out 8th generation mobile telephony :-)

John Loughney responded:
jl> Hopefully, we are thinking of more than just mobile telephony ;)

Is there anything else?  :-)

jl> Please note that we are looking to solve practical problems, while
jl> ensure an open structure / framework for future extensibility.
jl> The reason for the short timeline on the deliverables is to help us
jl> focus on the task at hand.  I do not think we should through every
jl> possible problem at NSIS.

I wholeheartedly and emphatically support this approach.

Cheers,

dlp

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



From daemon@optimus.ietf.org  Fri Jan 25 06:56: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 GAA29593
	for <nsis-archive@odin.ietf.org>; Fri, 25 Jan 2002 06:55:59 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id GAA10210
	for nsis-archive@odin.ietf.org; Fri, 25 Jan 2002 06:56: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 GAA09640;
	Fri, 25 Jan 2002 06:45: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 GAA09611
	for <nsis@optimus.ietf.org>; Fri, 25 Jan 2002 06:45: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 GAA29062
	for <nsis@ietf.org>; Fri, 25 Jan 2002 06:45:14 -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 g0PBjD8n024476
	for <nsis@ietf.org>; Fri, 25 Jan 2002 12:45:13 +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 <0GQH008EKSN9BR@mbb1.ericsson.se> for nsis@ietf.org; Fri,
 25 Jan 2002 12:45:11 +0100 (MET)
Date: Fri, 25 Jan 2002 12:45:42 +0100
From: David Partain <David.Partain@ericsson.com>
Subject: Re: [NSIS] Georgios' framework decomposition (was Two kinds of
 requirements)
In-reply-to: <905A1C4ABF353F4C8CC16FA9F53DD0D638B9AF@TRIMAIL2.ad.tri.sbc.com>
To: NSIS Mailing List <nsis@ietf.org>
Reply-to: David.Partain@ericsson.com
Message-id: <0GQH008ELSNABR@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: <905A1C4ABF353F4C8CC16FA9F53DD0D638B9AF@TRIMAIL2.ad.tri.sbc.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

Greetings Marco,

I've put things in chronological order since I'm a serial kind o'
guy.

Regarding the discussion of the "framework" figure, Marco
Schneider wrote:

> First of all, I support the goal of modular extensible protocol.

Excellent!

> The framework appears to make a some presuppositions about the
> solution that impose unnecessary and undesireable constraints
> on the solution.  Perhaps it is simply a matter of clarifying
> the framework.

First of all, I think it's obvious - but I'll say it anyway -
that this "framework" needs a great deal more discussion.
My question in the long mail yesterday was if we can use this
as a starting point.

> We need to develop requirements for an NSIS UNI that allows
> a host to request a QOS connection across the network to
> another host.

In the end, this is of course what everyone wants.

> This protocol will run across a host to network
> interface. Presumably this is between host and edge in the
> framework diagram provided.

Yes, that's what I would say.

> 1) The framework refers to an "every hop" protocol component
> which is shown in the interior of the network. This presupposes
> a hop by hop signaling protocol within the interior of the
> network. There are a wide variety of approaches to achieving
> the QOS connection.

Yes, I completely agree.  In some networks, there will be no
"everyhop" component included since that network will be
overprovisioned (or whatever the reason may be).  In some
networks, though, each hop will need to look at something
in the signalling message as it flies by and do something
based upon what it sees.  That's needed in some environments.
We just have to make sure that both things are possible.

> 2) The framework imposes this assumption (of hop by hop
> signaling) on the functionality for the NSIS UNI since
> "everyhop" is shown as part of the host functionality.

I certainly don't mean to imply hop-by-hop signalling must take
place everywhere.  As I say above, there will be domains where
this isn't done.  The key point is that a "domain-specific"
answer - however it is determined - is needed in order to build
an end-to-end answer.

> 3) Whereas hop by hop signaling within the interior of a network
> may require information on the topology of the network, our
> requirement is that the host should not be able to access any
> topology information.

A protocol that requires that end hosts/applications know
something about topology is certainly not what I have in mind.

Cheers,

dlp

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



From daemon@optimus.ietf.org  Fri Jan 25 07:05:42 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29860
	for <nsis-archive@odin.ietf.org>; Fri, 25 Jan 2002 07:05:42 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id HAA11124
	for nsis-archive@odin.ietf.org; Fri, 25 Jan 2002 07:05: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 HAA11092;
	Fri, 25 Jan 2002 07:04: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 HAA11057
	for <nsis@optimus.ietf.org>; Fri, 25 Jan 2002 07:04:40 -0500 (EST)
Received: from newish7.ericsson.com.au (newish7.ericsson.com.au [203.61.155.116])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29792
	for <nsis@ietf.org>; Fri, 25 Jan 2002 07:04:13 -0500 (EST)
Received: from brsf10.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10])
	by newish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id XAA26782;
	Fri, 25 Jan 2002 23:02:40 +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 XAA04052;
	Fri, 25 Jan 2002 23:03:49 +1100 (EST)
Received: from localhost.localdomain (MINDY [147.214.68.87]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id XRFZP04W; Fri, 25 Jan 2002 23:03:46 +1100
Subject: RE: [NSIS] Two kinds of requirements
From: Brian Williams <brian.williams@ericsson.com.au>
To: Dick Knight <dick.rr.knight@bt.com>
Cc: Marco Schneider <schneider@tri.sbc.com>,
        Gary Kenward
	 <gkenward@nortelnetworks.com>,
        Radhika Roy <rrroy@att.com>, john loughney
	 <john.loughney@nokia.com>,
        brunner@ccrle.nec.de, Yaron Kahana
	 <ykahana@comgates.co.il>,
        Ruediger Geib <Ruediger.Geib@t-systems.com>, nsis@ietf.org
In-Reply-To: <451D45016C2CD2119DA50000F8FE7F07080E5A75@mlngcbnt01.hc.bt.com>
References: <451D45016C2CD2119DA50000F8FE7F07080E5A75@mlngcbnt01.hc.bt.com>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Mailer: Evolution/1.0.1 
Date: 25 Jan 2002 22:59:22 +1100
Message-Id: <1011959969.1863.14.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 Dick.
On Fri, 2002-01-25 at 01:11, dick.rr.knight@bt.com wrote:
> Brian,
>  No, sorry I don't agree.
> 
> We ought to stay closer to the user. NSIS should carry the requested (and
> the negotiated) QoS. If we carry the actual QoS parameters specific to the
> L2 mechanism, then we have only repeated the same information in different
> envelopes.
We actually do agree with each other. I do not say at any point that the
information shall be the same as the layer 2 signalling mechanisms
needs. 

My concern is that there must be sufficient information of some type to
allow the derivation of what is required for the layer 2. However, the
typical set of parameters currently in Intserv is not sufficient to
allow a spectrum efficient bearer, and more information is needed.
However I would not expect the additional information to be UMTS
parameters for example.
/brian
 
> Dick
> 
> -----Original Message-----
> From: Brian Williams [mailto:brian.williams@ericsson.com.au]
> Sent: 24 January 2002 09:20
> To: Marco Schneider
> Cc: Gary Kenward; Radhika Roy; john loughney; brunner@ccrle.nec.de;
> Yaron Kahana; Ruediger Geib; Dick Knight; nsis@ietf.org
> Subject: RE: [NSIS] Two kinds of requirements
> 
> 
> Hi Marco.
> 
> On Thu, 2002-01-24 at 05:03, Schneider, Marco wrote:
> > Brian,
> > 
> > Thanks for your discussion. So if I understand your comments correctly,
> you
> > are concerned with NSIS QOS mapping to layer 2 QOS. Is there any way in
> > which these requirements would impact the actual signaling protocol?
> The comments highlighting the different network architectures was of
> course simply to identify that the solution must allow for different
> layering of communication in different networks. This is only to ensure
> that limited views of networks and QoS layering don't lead to solutions
> only tailored to one type.
> 
> The other aspect which I think you are actually questioning is whether
> the layer 2 QoS mechanism shall impact the signalling protocol. My
> position here is the actual signalling mechanism should be independent
> of the lower layers, but the data carried to express the traffic and QoS
> requirements can vary. 
> /brian
> 
>  
> > Marco
> > 
> > -----Original Message-----
> > From: Brian Williams [mailto:brian.williams@ericsson.com.au]
> > Sent: Wednesday, January 23, 2002 4:32 AM
> > To: Schneider, Marco
> > Cc: 'Gary Kenward'; 'Roy, Radhika R, ALASO'; Loughney "John
> > (NRC/Helsinki); brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
> > dick.rr.knight@bt.com; nsis@ietf.org
> > Subject: RE: [NSIS] Two kinds of requirements
> > 
> > 
> > Hi Marco.
> > On Wed, 2002-01-23 at 09:48, Schneider, Marco wrote:
> > > Garry,
> > >  
> > > >From an architectural/software perspective there is a session layer
> that
> > > is logically built on top of the transport capability. From a protocol
> > > stack perspective the session signaling is not layered on top of the
> > > transport signaling in the framework I described. 
> > >  
> > > Aside: The following scenario is conceivable but not desireable.
> > > Consider an ADSL customer that is logically connected to an edge router
> > > via a DSLAM and an edge switch. Thus the layer 3 hop is realized by
> > > multiple hops at layer 2. 
> > A similar but slightly different situation exists also with cellular
> > wireless networks. The layer 3 hop runs over one layer 2 hop, but this
> > layer 2 hop is actually overlayed on top of multiple underlying layer 2
> > hops. 
> > 
> > > Existing deployments that I am aware of use a
> > > preprovisioned PVC for this. Now imagine that the customer does session
> > > signaling resulting in NSIS signaling at layer 3. This could result in
> > > the need for a new layer 2 connection because the existing PVC will not
> > > do the job. 
> > Certanly the case for cellular that a new lasyer 2 connection coule be
> > required.
> > 
> > > Thus ATM UNI signaling might be initiated from the ADSL
> > > Customer to allocate the resources for the layer 3 logical link. Yuck!
> > > Obviously it is better to avoid this by pre-provisioning the access
> > > network appropriately. Nevertheless, there may be other circumstances
> > > where this type of situation will occur and one could imagine promoting
> > > the layer 2 devices to be aware of NSIS so as to avoid multiple levels
> > > of signaling. 
> > For the cellular case, the end host is the device that sets up the layer
> > 2 connection. This connection must use separate signalling to allow
> > separate development of the layer 2 capabilities (ie dependent on
> > cellular technology). The host though must be able to relate the QoS
> > requirements signalled by NSIS to the layer 2 signalling. We are in the
> > process of producing a draft to clarify these requirements based on
> > typical layer 2 characteristics of cellular networks.
> > /brian
> >   
> > > Marco
> > >  
> > > -----Original Message-----
> > > From: Gary Kenward [mailto:gkenward@nortelnetworks.com]
> > > Sent: Tuesday, January 22, 2002 3:34 PM
> > > To: Schneider, Marco; 'Roy, Radhika R, ALASO'; Loughney John
> > > (NRC/Helsinki); brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
> > > dick.rr.knight@bt.com
> > > Cc: nsis@ietf.org
> > > Subject: RE: [NSIS] Two kinds of requirements
> > > 
> > > 
> > > 
> > > Marco:
> > >  
> > >    Good question: what do I mean by layering. I assume you are familiar
> > > with protocol layers and their
> > > properties. My major concern would be in the replication of information
> > > exchanges at each layer, resulting
> > > in greater overhead/delay. The end systems must to be involved in
> > > establishing the necessary QoS, including
> > > negotiation if viable, but the number of bits that are transported
> > > through the network to set up this QoS
> > > end to end must be kept to a minimum. Thus, I cringe at the possibility
> > > of an end-to-end application exchange
> > > triggering an RSVP request, triggering . . . in telephony terms, the
> > > analogy is the call setup delay, which has
> > > to be acceptable to the user, and, for wireless, has to be bandwidth
> > > efficient.
> > >  
> > >   I hope I have explained my concern.
> > >  
> > > Cheers,
> > > Gary
> > >  
> > >  
> > > 
> > > -----Original Message-----
> > > From: Schneider, Marco [mailto:schneider@tri.sbc.com]
> > > Sent: January 22, 2002 15:35
> > > To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Roy, Radhika R, ALASO'; Loughney
> > > John (NRC/Helsinki); brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
> > > dick.rr.knight@bt.com
> > > Cc: nsis@ietf.org
> > > Subject: RE: [NSIS] Two kinds of requirements
> > > 
> > > 
> > > Gary,
> > > 
> > > -----Original Message-----
> > > From: Gary Kenward [mailto:gkenward@nortelnetworks.com]
> > > Sent: Tuesday, January 22, 2002 9:02 AM
> > > To: Schneider, Marco; 'Roy, Radhika R, ALASO'; Loughney John
> > > (NRC/Helsinki); brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
> > > dick.rr.knight@bt.com
> > > Cc: nsis@ietf.org
> > > Subject: RE: [NSIS] Two kinds of requirements
> > > 
> > > 
> > > 
> > > Marco: 
> > > 
> > > -----Original Message----- 
> > > > [MS]  Yes, exactly. 
> > > >   I don't believe you are proposing a "layering" of signalling
> > > protocols, 
> > > > one for session establishment, then one for transport, etc. 
> > > > [MS]  This is exactly what has been proposed in RAP and SIP working
> > > groups to the best 
> > > > of my understanding. Because there does not exist a proxy signaling
> > > capability that 
> > > > allows a session to setup a connection on the users behalf, the
> > > session forwards a 
> > > > token to the end-system and then the end-system includes that token in
> > > the RSVP path 
> > > > message so that the reservation will go through. In this manner the
> > > session layer does 
> > > > not need to communicate directly with the transport layer. 
> > > 
> > > [gwk] I do not understand what "the session" represents in the above. It
> > > would seem 
> > > to me that you must have a session level entity, and that to "forward a
> > > token to the 
> > > end-system", it must have an interface/api to the "end-system". If this
> > > "end-system" 
> > > is including tokens in RSVP, then it is the entity setting up the
> > > transport QoS (although 
> > > it is not necessarly a transport layer entity, but rather a signalling
> > > entity. If these 
> > > two entites are co-located, then you do not have layered signalling
> > > protocols. 
> > > 
> > > Have I missed something? 
> > > 
> > > [Schneider, Marco] I don't think you have missed anything. I may not
> > > have understood what you meant by a layering of signaling protocols.
> > > Please define this.
> > > 
> > > BTW: for many links, particularly wireless, layered signalling is not a
> > > good idea. 
> > > And, in general, layered signalling will always be slower then a single
> > > signalling protocol. 
> > > > So, the question, 
> > > > becomes, how are the QoS transport mechanisms established? In the
> > > internet 
> > > > model there is only one end-to-end transport session (e.g. TCP, RTP,
> > > UDP), 
> > > > but underneath the transport is a series of inter-connected networks,
> > > each 
> > > > with potentially different characteristics. 
> > > >   This is end-to-end QoS support structure has to be set up and
> > > maintained 
> > > > in order for the end to end session QoS to be realized. The solution
> > > may be 
> > > > a single protocol that travels from host to host, such as RSVP, or it
> > > may 
> > > > be a collection of protocols that are optimized for each portion of
> > > the 
> > > > end-to-end path: e.g. host to access network, access to core network, 
> > > > core to core network, etc. 
> > > >   It is too early to determine which approach is best, but in either
> > > case, 
> > > > do we not need to understand the end-to-end requirements for this
> > > signalling 
> > > > capability? 
> > > > [MS]  So by end-to-end you are referring to both the end-systems and
> > > the devices in 
> > > > between. As a point of clarification, I asked Roy what he meant by
> > > "End-to-End 
> > > > Application Layer QOS Signaling" and his answer implied user
> > > (end-system) to user (end- 
> > > > system).  We have been using the term end-to-end in different ways
> > > (contexts). The way 
> > > > I normally use the term "end-to-end" is to include everything in
> > > between (all the 
> > > > hops). 
> > > 
> > > [gwk] I see the difference. I would say that I tend towards your
> > > definition, in the 
> > > following sense: the only QoS that matters is what the end-user sees, so
> > > as a service 
> > > characteristic, it must be provided between the two end systems / hosts.
> > > In order to do 
> > > this, however, some level of support is required at each hop along the
> > > path. 
> > > For me the term end-to-end (for example end-to-end call flow) includes
> > > the components within the network that must come together to make it
> > > work. The term end-to-end application level signaling seems like an
> > > oxymoron since this signaling occurs with no involvement of the network
> > > except to transfer the data packets but perhaps there is something I am
> > > missing. 
> > > 
> > >  So, establishing QoS between the end systems requires a peer-to-peer
> > > agreement between 
> > > the end systems, a host-to-cloud agreement for the transport of the
> > > packets, and 
> > > some mechanism within the cloud to ensure that the agreed upon QoS is
> > > provided. 
> > > Depending upon the complexity of the cloud, the latter could imply all
> > > sorts of QoS 
> > > agreements between networks and even nodes, for packet forwarding. 
> > > 
> > >   Note that I have purposely NOT stated that any of these agreements are
> > > negotiated or 
> > > require a signalling protocol. My opinion is that it is better in the
> > > long term to 
> > > support negotiated services using signalling, as it provides more
> > > flexibility. However, 
> > > this can be overdone, say, as a silly example, by having the end-system
> > > negotiate with 
> > > every node in the network. So, the compromise is that some of the QoS
> > > agreements will 
> > > be incorporated into the network design (e.g. Diff Serv), some will be
> > > configured by 
> > > the operator(s) (e.g. through traffic engineering and policy
> > > management), and others 
> > > will be signalled. NSIS seems to be about determining where signalling
> > > is appropriate, 
> > > and what are the signalling peers, and what is the best protocol
> > > solution or solutions. 
> > > The catch is that the first two approaches actually encompass a wide
> > > variety of technologies 
> > > and scenarios. 
> > > [Schneider, Marco]  I think you have articulated this very well and I am
> > > in general agreement. 
> > > 
> > >   Sorry for stating the obvious. There is clearly some concern over the
> > > use, for example, 
> > > of RSVP, and I suspect that some people are concerned that "end-to-end
> > > signalling" also 
> > > means "hop-by-hop" ala RSVP. It could, but it does not have to. 
> > > [Schneider, Marco] I think this is a very important distinction. I think
> > > that the reverse is true as well in that some people are assuming a hop
> > > by hop linear signaling model wherein the signaling takes place in order
> > > along the path that the data will follow. The transport signaling that
> > > is going to occur within the core of our network will be at a different
> > > timescale than UNI signaling and there are a variety of solutions for
> > > this including RSVP-te and CR-LDP which were developed for the purpose
> > > of allocating traffic trunks.
> > > 
> > >   So, my view is that NSIS needs to ensure that the end-to-end QoS is
> > > provided for, and 
> > > develope the protocols where they are needed (but not where they are
> > > not). At this point, 
> > > that would seem to be host to edge, edge to edge, and at the very least,
> > > with enough 
> > > end to end semantics to ensure that the complete path supports QoS. I am
> > > concerned about 
> > > node to node signalling, as there are so many different approaches to
> > > supporting node-to-node 
> > > QoS. At the very least, I would like to see a framework, and the edge
> > > solutions defined 
> > > before we delve into "intra-network" issues. 
> > > [Schneider, Marco] I think it all begins with the fact that a user must
> > > be able to request a QOS/COS connection/flow to another user. If we
> > > can't do that then everything else would appear to be pointless. The
> > > next question is whether we want to develop protocols that assist the
> > > network portion in delivering this capability and in what context(s).
> > > 
> > > 
> > > BTW: in writing this, it dawned upon me that it might be best to write a
> > > series of 
> > > requirements rather then just one - i.e. tackle the problem piece by
> > > piece. This approach 
> > > does have drawbacks, but working groups seem to work better when they
> > > focus on contained 
> > > problem domains. A strawman framework might be useful in keeping the
> > > incremental solutions 
> > > coherent. 
> > > [Schneider, Marco] I agree with the idea of tackling the requirements by
> > > breaking the problem up. There is a catch 22 in that in order to breakup
> > > it up we must to some degree presuppose a solution. 
> > > 
> > > 
> > > > [MS] I think our basic requirement is that an end-system be able to
> > > request (and 
> > > > receive) a QOS connection to some other end-system (NSIS UNI). The
> > > request part entails 
> > > > an NSIS UNI. As you say the realization of this request can be
> > > achieved in a number of 
> > > > different ways. Now one solution is to invent an NSIS NNI that runs
> > > between domains. If 
> > > > we develop requirements for such an NSIS UNI then we have already
> > > preproposed a 
> > > > solution ahead of requirements. 
> > > 
> > > [gwk] We have to be extremely careful not to become pre-occupied with
> > > requirements 
> > > definition. All productive requirements definition efforts begin with
> > > assumptions 
> > > concerning the solution. In my view, requirements specifications are a
> > > balance between 
> > > presumption and prediction, particularly when dealing with "soft"
> > > techologies such as 
> > > protocols. The issue really is not whether a requirement is a "MAY" or a
> > > "SHOULD" or 
> > > whatever, the issue is whether a requirement actually helps us define
> > > the solution 
> > > (there are lot's of examples of "SHOULD" requirements that do not bring
> > > value to the 
> > > design process). 
> > > [Schneider, Marco] I think there is a danger in implicit assumptions
> > > that may not lead to the best solution. With respect to network support
> > > of a QOS request, there are many different solutions and I am afraid
> > > that some participants have presupposed a hop by hop signaling solution.
> > > 
> > > 
> > > Given my observation above about writing a series of requirements, I
> > > would recommend 
> > > that we roughly map out the solution(some would call this a
> > > "framework"). This map would 
> > > form the preliminary list of deliverables for the wg charter, and then
> > > pick a focussed 
> > > problem area to begin with requirements. This is not "top down" design,
> > > but "top down" 
> > > processes seldom work. If this seems too abstract, what I am saying is
> > > that I have no 
> > > problem identifying that there are N problem areas to be addressed -
> > > e.g. host to edge, 
> > > edge to edge, node to node, etc. - and picking anyone for the first
> > > design attempt. Of 
> > > course, the challenge would be to keep an eye on the "big picture" or
> > > end-to-end 
> > > requirements in the process. 
> > > [Schneider, Marco] I think that the network context for supporting NSIS
> > > UNI is a quagmire, albeit a very fun one. The problems we need to
> > > address depend upon what end-to-end architectures we wish to support.
> > > There are a number of capabilities already being developed for network
> > > QOS and there may be a number of ways to "glue" these together.
> > > 
> > > Deludedly yours,
> > > 
> > > Marco
> > > 
> > > Just my deluded point of view. 
> > > Cheers, 
> > > Gary 
> > > 
> > > [Schneider, Marco]  
> > > *snip* 
> > > 
> > 
> > 
> > 
> > _______________________________________________
> > nsis mailing list
> > nsis@ietf.org
> > https://www1.ietf.org/mailman/listinfo/nsis
> > 
> > _______________________________________________
> > nsis mailing list
> > nsis@ietf.org
> > https://www1.ietf.org/mailman/listinfo/nsis



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



From daemon@optimus.ietf.org  Fri Jan 25 07:46: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 HAA00688
	for <nsis-archive@odin.ietf.org>; Fri, 25 Jan 2002 07:46:12 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id HAA12498
	for nsis-archive@odin.ietf.org; Fri, 25 Jan 2002 07:46: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 HAA12226;
	Fri, 25 Jan 2002 07:35: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 HAA12187
	for <nsis@optimus.ietf.org>; Fri, 25 Jan 2002 07:35:25 -0500 (EST)
Received: from Morgana.Elet.PoliMi.IT (bianchi@morgana.elet.polimi.it [131.175.120.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00421
	for <nsis@ietf.org>; Fri, 25 Jan 2002 07:35:21 -0500 (EST)
Received: from host localhost and sender bianchi@localhost;
	by mail relay Morgana.Elet.PoliMi.IT (Sendmail Ver. 8.x.x / 2 Nov. 1998);
	with protocol ESMTP and identifier NAA00408;
	on date and time Fri, 25 Jan 2002 13:35:14 +0100 (MET).
Date: Fri, 25 Jan 2002 13:35:14 +0100 (MET)
From: Giuseppe Bianchi <bianchi@morgana.elet.polimi.it>
To: john.loughney@nokia.com
cc: pingpan@juniper.net, <nsis@ietf.org>
Subject: RE: [NSIS] Framework & requirements part of the "Two kinds of 
 requirements" thread
In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEF5D945B@esebe004.NOE.Nokia.com>
Message-ID: <Pine.OSF.4.44.0201251250560.30574-100000@morgana.elet.polimi.it>
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



> > - why do we signal in the first place?
> > - where do we need to signal?
> > - will signaling work in provider's networks?
> >
> > We signal because there is no QoS when we are using some inter-active
> > real-time applications. Since most of the Internet traffic is
> > not within the scope of this "inter-active" and "real-time", let's not
> > consider a kitchen-sink signaling protocol.

I'd not focus JUST on the user view, i.e. an admission control function is
not just a way for the user to throw in the network a set of requirements
that need to be satisfied. From the provider's perspective, it is a
fundamental way to control that its planned QoS (or utilization) target is
persistently met. And, most important, regardless of what this specific
target is.

In this (perhaps extreme, for someone) view, signalling does not even need
to carry user requirements, but is a tool in the hands of the provider to
allow it to maintain its level of QoS provisioned (decided by the
provider, but not imposed by a standard). Requirements come back into play
when the provider is able to support different levels. Isn't this scenario
very appealing for providers, and a strong motivation for supporting
signalling?

Indeed, as sugested by Dick, the user can have an active role if he is
made able to specify, during call setup, how much its QoS requirements can
be downgraded.

Just my 1 c.

Giuseppe



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



From daemon@optimus.ietf.org  Fri Jan 25 08:12: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 IAA01328
	for <nsis-archive@odin.ietf.org>; Fri, 25 Jan 2002 08:12:59 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id IAA13685
	for nsis-archive@odin.ietf.org; Fri, 25 Jan 2002 08:13: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 IAA13655;
	Fri, 25 Jan 2002 08:11: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 IAA13588
	for <nsis@optimus.ietf.org>; Fri, 25 Jan 2002 08:11:48 -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 IAA01237
	for <nsis@ietf.org>; Fri, 25 Jan 2002 08:11:43 -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 g0PDBg129907
	for <nsis@ietf.org>; Fri, 25 Jan 2002 14:11:42 +0100 (MET)
Received: FROM esealnt747.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Fri Jan 25 14:10:38 2002 +0100
Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <YHKTL7GR>; Fri, 25 Jan 2002 14:10:55 +0100
Message-ID: <E244E44D6AB85E40AEEF7EAABE3545FA8233BC@enleent104.nl.eu.ericsson.se>
From: "Georgios Karagiannis (ELN)" <Georgios.Karagiannis@eln.ericsson.se>
To: "'Chen, Weijing'" <wchen@tri.sbc.com>,
        "'Schneider, Marco'"
	 <schneider@tri.sbc.com>
Cc: NSIS Mailing List <nsis@ietf.org>
Subject: RE: [NSIS] Framework & requirements part of the "Two kinds of req
	 uirements" thread
Date: Fri, 25 Jan 2002 14:10:37 +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 Weijing and Marco

I will just repeat some text from the proposed framework:

 * A "host" could be an end host or a proxy.  It can process
   and use the "everyhost", "everyedge", and "everyhop"
   protocol components
 * An "edge" can be a Diffserv edge, MPLS edge, etc.  It can
   process and use the "everyedge", and "everyhop" protocol
   components. The "everyhost" protocol component is not
   processed (used or checked) but is carried onward.

 * An "interior within domain" can be any router within
   a domain.  It can process and use only the "everyhop"
   protocol component.  The "everyhost" and "everyedge"
   protocol components are not processed (used or checked)
   but are carried onward.

Example _1: Suppose that a network provider is managing an overprovisioned 
network and is willing to provide to its end users applications that 
require end to end QoS support (e.g., telephony).
This provider may choose to use the (NSIS) protocol 
on an "end host to end host" basis. In this case 
the "host" will not use (activate) the "everyedge" 
and "everyhop" components, since they are not required.
Therefore, all edges and hops in the network will not process this 
type of NSIS protocol. Thus the NSIS message will only be processed 
by the end hosts. This is identical to the ("simple") example used
by Weijing.

Example_2: Now suppose that the network consists of overprovisioned 
access networks (managed by one provider) and by many concatenated 
QoS domains that are overprovisioned
but they are managed by different network providers.

Assume that the end user will like to use the "end host 
to end host" type of NSIS protocol for this purpose.
In this case the "host" will only activate the [everyedge] 
component, which will include 
QoS information that is needed by an edge of a domain. 
The [everyhop] component will not be activated, and therefore,
it will not be processed by any router located within the 
overprovisioned access network. Thus, the interior nodes 
located within the overprovisioned access network will not use 
the NSIS message.

The first edge node of a domain that will receive the NSIS message
will only use the [everyedge] information. Please note
that the edge node may change (replace) the [everyedge]
information.  If within this domain 
none existing QoS mechanism, e.g., Intserv/MPLS/overprovisioning,
are used, then the edge (of course this depends on the 
policy of the provider of the domain) will activate and include 
information into the [everyhop] component. Every hop within this 
domain will only use the [everyhop] component included in 
the NSIS message.

The same principles could be applied to all other domains 
wherein the NSIS message will pass through in its way to the 
receiving end host.

This example shows that by using the proposed framework
the NSIS protocol will be used (and checked) only (and only) by the 
nodes that need to use it. In this way the protocol can be 
processed fast and at the same time provide a reasonable level 
of QoS signaling functionality.


Best Regards,
Georgios






-----Original Message-----
From: Chen, Weijing [mailto:wchen@tri.sbc.com]
Sent: vrijdag 25 januari 2002 4:59
To: 'Georgios Karagiannis (ELN)'
Cc: NSIS Mailing List
Subject: RE: [NSIS] Framework & requirements part of the "Two kinds of
req uirements" thread


Georgios,

>>In principle I agree with you. The framework should not be used
>>to  define the NSIS requirements. The NSIS requirements should be
>>produced based on different QoS needs of certain application types.

Thank you.

>>No it is not required that the "host" has a global view 
>>of the domains. The way of how this NSIS protocol finds the edges
>>and the hops is similar with the way the RSVPv1 protocol does it.

So we still expose the network interior to host. Then what is the benefit of
this for host? Compare the following stacks that the host has to handle:

|-----|
|ehost|
|-----|
|     |
|-----|
|eedge|
|-----|
|     |
|-----|
|ehop |
|-----|
 host    

vs.

|-----|
|ehost|
|-----|
 host                

Cleary the latter one is much simpler.

Now let's take a look what is the typical sequence of end-to-end QoS service
delivery chain:

[src ehost]->hello, edge, I want so and so [original QoS] to so and so
place.
[incoming eedge]->ok, host, just a millisecond.
       [background] glueing the [original QoS] to [ehop QoS] in first
[ehop], 
                    [ehop] passes [ehop QoS] and [original QoS] to next
                    [ehop], on and on to outgoing [eedge].
[outgoing eedge]->hello, ehost, here is [original QoS] request from
                  [src ehost], will you take it?
[dest ehost]->ok, accept.
[outgoing eedge]-->[ehop]-->[incoming eedge]...
[incoming eedge]->host, you are ready to go.
[src ehost]->ok...

In the above sequence, [ehost] only deals with [eedge] directly, not [ehop].
So why do we want to force [ehop] information (i.e. network internal
information) to [ehost]? If we are doing so, [ehost] would say "Ooo, I am
stuffed, choked, ok, I am giving up. I don't want QoS." Which is exactly
where we are today.

So please don't stuff the poor [ehost] with anything else except he
absoultly need for [ehost] to [eedge] request and response. Thank you very
much.

--
Weijing Chen
SBC Technology Resources
9505 Arboretum Blvd.
Austin, TX 78759
512 372 5710
wchen@tri.sbc.com


-----Original Message-----
From: Georgios Karagiannis (ELN)
[mailto:Georgios.Karagiannis@eln.ericsson.se] 
Sent: Thursday, January 24, 2002 3:33 AM
To: Chen, Weijing
Cc: NSIS Mailing List
Subject: RE: [NSIS] Framework & requirements part of the "Two kinds of req
uirements" thread

Hi Weijing

Please see my comments in line.

[WC]>> 1. David's proposal of working requirement within so 
[WC]>> called "framework" is putting the cart before the horse. 
[WC]>> Because we think one framework is cool,
[WC]>> we confine our requirements and use cases within 
[WC]>> that framework. It is totally unacceptable.

In principle I agree with you. The framework should not be used
to  define the NSIS requirements. The NSIS requirements should be
produced based on different QoS needs of certain application types.
However, the mentioned framework can be used to decompose a 
complex QoS problem into certain simpler QoS problems.

[WC]>> 2. Figure
[WC]>>  In above picture, [host] has to assemble and process 
[WC]>>  the [ehop], [eedge] in addition to [ehost] part. How will 
[WC]>>  the [host] correctly assemble and process
[WC]>> the [ehop] and [eedge] pieces? It implies that [host] has 
[WC]>> global view of [ehop] and [eedge] in every domains. 
[WC]>> to happen, there must be another protocol to exchange network 
[WC]>> information and pass whole network view
[WC]>> to [host]. 

No it is not required that the "host" has a global view 
of the domains. The way of how this NSIS protocol finds the edges
and the hops is similar with the way the RSVPv1 protocol does it.

[WC] >> Now what about "glue"? Shall NSIS do it? Part of me 
[WC] >> says yes, another says
[WC] >> no. I am 50/50.

Please note that the NSIS charter mentions that a "framework" 
draft should be specified by March 2002.

Best regards,
Georgios


-----Original Message-----
From: Chen, Weijing [mailto:wchen@tri.sbc.com]
Sent: donderdag 24 januari 2002 9:43
To: David.Partain@ericsson.com
Cc: NSIS Mailing List
Subject: RE: [NSIS] Framework & requirements part of the "Two kinds of
req uirements" thread



I have fundamental disagreement with David's point.

1. David's proposal of working requirement within so called "framework" is
putting the cart before the horse. Because we think one framework is cool,
we confine our requirements and use cases within that framework. It is
totally unacceptable.

2. 

|-----|                                                  |-----|
|ehost|<------------------------------------------------>|ehost|
|-----|                                                  |-----|
|     |                                                  |     |
|-----|            |-----|            |-----|            |-----|
|eedge|<---------->|eedge|<---------->|eedge|<---------->|eedge|
|-----|            |-----|            |-----|            |-----|
|     |            |     |            |     |            |     |
|-----|   |----|   |-----|   |----|   |-----|   |----|   |-----|
|ehop |<->|ehop|<->|ehop |<->|ehop|<->|ehop |<->|ehop|<->|ehop |
|-----|   |----|   |-----|   |----|   |-----|   |----|   |-----|
 host    interior   edge    interior   edge     interior  host
         w/in domain       w/in domain        w/in domain

In above picture, [host] has to assemble and process the [ehop], [eedge] in
addition to [ehost] part. How will the [host] correctly assemble and process
the [ehop] and [eedge] pieces? It implies that [host] has global view of
[ehop] and [eedge] in every domains. For this to happen, there must be
another protocol to exchange network information and pass whole network view
to [host]. So on, and so on, and sooner we know that we revive an ultimate
engineer dream: a protocol for all and do all. Be there, done that, and
failed. Otherwise we wouldn't be here to debate about what NSIS should be.

The right picture should be (if you insist talking about the framework
before requirement):

                   |-----|   |----|   |-----|  
                   |ehop |<->|ehop|<->|ehop |   
                   |-----|   |----|   |-----| 
                   |     |            |     |
                   |-----|            |-----|
                   |glue |            |glue |
                   |-----|            |-----|
                   |     |            |     |
|-----|            |-----|            |-----|            |-----|
|ehost|<---------->|ehost|<---------->|ehost|<---------->|ehost|
|-----|            |-----|            |-----|            |-----|
 host                edge     hop      edge                host
           domain            domains             domain
                             (inter and
                              intra)
           NSIS                                   NSIS

Now what about "glue"? Shall NSIS do it? Part of me says yes, another says
no. I am 50/50.

--
Weijing Chen
SBC Technology Resources
9505 Arboretum Blvd.
Austin, TX 78759
512 372 5710
wchen@tri.sbc.com



-----Original Message-----
From: David Partain [mailto:David.Partain@ericsson.com] 
Sent: Wednesday, January 23, 2002 3:58 AM
To: NSIS Mailing List
Subject: [NSIS] Framework & requirements part of the "Two kinds of
requirements" thread

Greetings all,

I'd like to offer my take on part of the thread "Two kinds
of requirements" to see if we can collectively reach any sort
of conclusion based on what's been written.  I doubt I'll say
anything new, but perhaps it'll help summarize a bit.

To cut to the chase, the conclusion of this mail is that
I think:

 - we should use the "framework" below as the starting point of
   framework discussions
 - the requirements should grow from use cases of particular
   applications that will use the network

The original mail postulated that people are wanting to work
on two kinds of requirements here:

 - end-host to end-host, or application to application
   signalling

 - transport level signalling

From that point, there has been a hearty debate about whether
this indeed is true, as well as a host of other issues.

I think the following points have been made, amongst others:

 - It should support the use of throughput adaptive applications
   and the ability for a traffic flow to express its QoS
   preferences with regard to the throughput values which it
   may be allocated.

 - One part of the thread was about whether RSVP and related
   work (e.g., RFC 2998), or perhaps SDPng, are suitable
   solutions.  While it's obvious that we need to learn from
   and perhaps start from one of these efforts in working on
   NSIS, it also seems clear that we shouldn't start working
   on that until the requirements are done.

 - There's no chance we'll create a single one-size-fits-all
   application-related signalling protocol that will be used
   by everyone.  That seems very clear.

 - There's a need for something transport independent that can
   help signal QoS needs across multiple domains in order
   to help the application-related signalling protocols do
   their thing.

The big issue there is what part of this we should solve here.
Should we concentrate specifically on the application/host
to network signalling?  I think not and others have agreed.
Should we try to design something that goes end to end?  If we
do that, do we have a "chicken and egg" problem of needing to
have the technology everywhere for things to work?

A case has been made that the goal should be to create a
signalling protocol that has different kinds of components
appropriate to different parts of the problem.  Georgios K.
proposed the following figure, which I like quite a lot and
which others have said is good, as a way of looking at it:

|-----|                                                  |-----|
|ehost|<------------------------------------------------>|ehost|
|-----|                                                  |-----|
|     |                                                  |     |
|-----|            |-----|            |-----|            |-----|
|eedge|<---------->|eedge|<---------->|eedge|<---------->|eedge|
|-----|            |-----|            |-----|            |-----|
|     |            |     |            |     |            |     |
|-----|   |----|   |-----|   |----|   |-----|   |----|   |-----|
|ehop |<->|ehop|<->|ehop |<->|ehop|<->|ehop |<->|ehop|<->|ehop |
|-----|   |----|   |-----|   |----|   |-----|   |----|   |-----|
 host    interior   edge    interior   edge     interior  host
         w/in domain       w/in domain        w/in domain

   ehost = everyhost
   eedge = everyedge
   ehop  = everyhop

NSIS protocol decomposition:

 * A "host" could be an end host or a proxy.  It can process
   and use the "everyhost", "everyedge", and "everyhop"
   protocol components.

 * An "edge" can be a Diffserv edge, MPLS edge, etc.  It can
   process and use the "everyedge", and "everyhop" protocol
   components. The "everyhost" protocol component is not
   processed (used or checked) but is carried onward.

 * An "interior within domain" can be any router within
   a domain.  It can process and use only the "everyhop"
   protocol component.  The "everyhost" and "everyedge"
   protocol components are not processed (used or checked)
   but are carried onward.

The everyhop bit within a domain provides signalling facilities
for that particular domain and is very likely to differ from
the everyhop bit used in the next boarding domain.

The point of all of this is to get a concatenation of results.
Each domain is responsible for taking its own decisions in its
own domain-specific ways.  The concatenation of the everyhop
decisions within a domain provides the domain's answer.
The concatenation of the domains' results gives and end to
end answer that can be used by the everyhost bit.

I think that having this overall framework -- for lack of a
better term -- in mind is very helpful.

If we can agree that this is a reasonable framework to use as
the basis of discussion, I think that what we need to do is
to produce a set of requirements for different "applications"
that will use these networks/this framework.  Indeed, I believe
this matches Keith Allen's request that requirements be based on
use cases.  If we know we're going to use the NSIS protocol on
a cellular wireless network (just to pull an example out of the
air :-)), then that "use case" implies a set of requirements.
A different scenario (e.g., the core of the network) implies
another set of requirements.

I personally think this is the right way forward and would
like to see this group move in this direction.

Georgios added some more thoughts on this topic
which addressed the applicability and prioritization
of work.  That can be found in the archive at
http://www1.ietf.org/mail-archive/working-groups/nsis/current/msg00418.html

I realize that I haven't covered everyone's particular topic
in this thread, but perhaps it'll help focus on one part of
the discussion.  If someone wants to summarize some other
sub-thread, that would be great...

Cheers,

dlp

ps. I think it would be very useful if Subject lines could more
accurately reflect the topic covered in the mail.  Long threads
with the same subject and covering a multitude of topics is
difficult to follow...

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

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

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



From daemon@optimus.ietf.org  Fri Jan 25 09:36: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 JAA03773
	for <nsis-archive@odin.ietf.org>; Fri, 25 Jan 2002 09:36:02 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id JAA17396
	for nsis-archive@odin.ietf.org; Fri, 25 Jan 2002 09:36: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 JAA16597;
	Fri, 25 Jan 2002 09:26: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 JAA16565
	for <nsis@optimus.ietf.org>; Fri, 25 Jan 2002 09:26:00 -0500 (EST)
Received: from howler.tri.sbc.com (howler.tri.sbc.com [205.173.58.4])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03455
	for <nsis@ietf.org>; Fri, 25 Jan 2002 09:25:54 -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 g0PES3T22287;
	Fri, 25 Jan 2002 08:28:03 -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 g0PEPMA29860;
	Fri, 25 Jan 2002 08:25:22 -0600 (CST)
Received: by TRIMAIL2.ad.tri.sbc.com with Internet Mail Service (5.5.2653.19)
	id <ZND3JHFF>; Fri, 25 Jan 2002 08:25:49 -0600
Message-ID: <905A1C4ABF353F4C8CC16FA9F53DD0D6322448@TRIMAIL2.ad.tri.sbc.com>
From: "Chen, Weijing" <wchen@tri.sbc.com>
To: "'David.Partain@ericsson.com'" <David.Partain@ericsson.com>,
        NSIS Mailing List <nsis@ietf.org>
Subject: RE: [NSIS] Framework & requirements part of the"Two kinds of  req
	uirements" thread
Date: Fri, 25 Jan 2002 08:25:43 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: nsis-admin@ietf.org
Errors-To: nsis-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Next Steps in Signaling <nsis.ietf.org>
X-BeenThere: nsis@ietf.org

>>David Partain: 

>>John Loughney responded:
>>jl> Hopefully, we are thinking of more than just mobile telephony ;)

>>Is there anything else?  :-)

Yes. There are much more: DSL, Ethernet, Fixed wireless, on and on, all kind
of fixed wireline and wireless access technology. Mobile is just one of
access technology.


--
Weijing Chen
SBC Technology Resources
9505 Arboretum Blvd.
Austin, TX 78759
512 372 5710
wchen@tri.sbc.com


-----Original Message-----
From: David Partain [mailto:David.Partain@ericsson.com] 
Sent: Friday, January 25, 2002 3:03 AM
To: NSIS Mailing List
Subject: Re: [NSIS] Framework & requirements part of the"Two kinds of
requirements" thread

Hi all,

I wrote:
dp> If we try to throw every possible problem area into the NSIS
dp> work, this working group will still be talking when we're rolling
dp> out 8th generation mobile telephony :-)

John Loughney responded:
jl> Hopefully, we are thinking of more than just mobile telephony ;)

Is there anything else?  :-)

jl> Please note that we are looking to solve practical problems, while
jl> ensure an open structure / framework for future extensibility.
jl> The reason for the short timeline on the deliverables is to help us
jl> focus on the task at hand.  I do not think we should through every
jl> possible problem at NSIS.

I wholeheartedly and emphatically support this approach.

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  Fri Jan 25 09:47: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 JAA03961
	for <nsis-archive@odin.ietf.org>; Fri, 25 Jan 2002 09:47:45 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id JAA17672
	for nsis-archive@odin.ietf.org; Fri, 25 Jan 2002 09:47: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 JAA17657;
	Fri, 25 Jan 2002 09:46: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 JAA17624
	for <nsis@optimus.ietf.org>; Fri, 25 Jan 2002 09:46:45 -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 JAA03938
	for <nsis@ietf.org>; Fri, 25 Jan 2002 09:46:40 -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 g0PEkkt11982
	for <nsis@ietf.org>; Fri, 25 Jan 2002 16:46:46 +0200 (EET)
Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T58aaf36c10ac158f23077@esvir03nok.nokia.com>;
 Fri, 25 Jan 2002 16:46:41 +0200
Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779);
	 Fri, 25 Jan 2002 16:46:41 +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] Two kinds of requirements
Date: Fri, 25 Jan 2002 16:46:40 +0200
Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF5D94A5@esebe004.NOE.Nokia.com>
Thread-Topic: [NSIS] Two kinds of requirements
Thread-Index: AcGlmI/wtAq5TP0qTre0uL/PerQT4wAFhsuA
To: <brian.williams@ericsson.com.au>
Cc: <nsis@ietf.org>
X-OriginalArrivalTime: 25 Jan 2002 14:46:41.0587 (UTC) FILETIME=[19EC7030:01C1A5AF]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id JAA17625
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

Brian,

> My concern is that there must be sufficient information of some type to
> allow the derivation of what is required for the layer 2. However, the
> typical set of parameters currently in Intserv is not sufficient to
> allow a spectrum efficient bearer, and more information is needed.

I'd be very interested in know what kind of parameters you mean.
Is there a reason why the layer 2 technology cannot handle the
specifics for setting up of layer 2?  Are applications sitting over
layer 3 so demanding / fussy that the need very precise details?

My feeling is that we should generalize the layer 3 needs, and
that layer 2 (or the service provider) can interpret them to
its needs.  

John

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



From daemon@optimus.ietf.org  Fri Jan 25 10: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 KAA04491
	for <nsis-archive@odin.ietf.org>; Fri, 25 Jan 2002 10:05:36 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id KAA18823
	for nsis-archive@odin.ietf.org; Fri, 25 Jan 2002 10:05: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 JAA17812;
	Fri, 25 Jan 2002 09:49: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 JAA17783
	for <nsis@optimus.ietf.org>; Fri, 25 Jan 2002 09:49:44 -0500 (EST)
Received: from cbibipnt03.HC.BT.COM (saturn.bt.com [193.113.57.20])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04037
	for <nsis@ietf.org>; Fri, 25 Jan 2002 09:49:39 -0500 (EST)
From: dick.rr.knight@bt.com
Received: by cbibipnt03.hc.bt.com with Internet Mail Service (5.5.2652.35)
	id <DQ1X32XC>; Fri, 25 Jan 2002 14:47:20 -0000
Message-ID: <451D45016C2CD2119DA50000F8FE7F07080E5A88@mlngcbnt01.hc.bt.com>
To: mendes@cs.columbia.edu, dick.rr.knight@bt.com
Cc: rrroy@att.com, schneider@tri.sbc.com, gkenward@nortelnetworks.com,
        john.loughney@nokia.com, brunner@ccrle.nec.de, ykahana@comgates.co.il,
        Ruediger.Geib@t-systems.com, nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements (one-many applications)
Date: Fri, 25 Jan 2002 14:46:59 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
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

See my comment below:

-----Original Message-----
From: Paulo Mendes [mailto:mendes@cs.columbia.edu]
Sent: 24 January 2002 20:24
To: dick.rr.knight@bt.com
Cc: rrroy@att.com; schneider@tri.sbc.com; gkenward@nortelnetworks.com;
john.loughney@nokia.com; brunner@ccrle.nec.de; ykahana@comgates.co.il;
Ruediger.Geib@t-systems.com; nsis@ietf.org
Subject: Re: [NSIS] Two kinds of requirements




dick.rr.knight@bt.com wrote:

> Nice one. I was waiting for this.
> 
> So .. another new requirement. To support one-to-many applications.


Yeap.. I say this is another requirement. I think that if we don't keep 
in mind one-to-many applications we'll specialize NSIS functionality to 
one-to-one cases, and then it would be hard to use NSIS with other type 
of applications...

Probably one-to-one requirements could be seen as a sub-group of one-to-many
requirements.


> There are two aspects to this:
> 1. The easy case. In internet TV, a provider (source of the TV) is
> available. The first client uses NSIS to negotiate QoS with the network
and
> the source. Assuming the negotiation is successful a "connection" is
> established. The second client then attepts to receive the TV. On
initiating
> the NSIS negotiation of QoS, they get a "take it or leave it" result of
the
> first client's negotiation. Anything else is not scalable.
> 2. A business conference will be established, with a known (limited)
number
> of clients. The provider can initiate the negotiation with the clients to
> achieve the best possible QoS using the least resources.
> 
> The first case is no extra requirements above an IP telephony call. The
> second requires multiparty negotiation at establishment.



I don't think this "take it of leave it" approach is the best one. For 
example, if the first client has a low quality requirement all the other 
clients can refuse join the session if they have a high quality expectation.
I think that a more flexible approach is needed. For example, the 
content provider should negotiate with the network provider a minimum 
quality level for the session, since he doesn't want to provide services 
with lower quality than that. After this, every client that joins the 
session can accept that level of quality or they can try to re-negotiate 
   with the network an increase of quality.

Cheers
Paulo

[Dick Knight]: Think of an extreme example. The president of the USA makes a
press release that he is going to make an important announcement concerning
[war; peace; world finances; aliens landing - something that almost
*everyone* in the world would like to hear about]. The announcement will
take place at 2pm EST, and of course will be multicast with to the NSIS
QoS-enabled internet. If the signalling sets up a QoS connection, in advance
of anyone connecting, where does it get set-up to? Suppose we wait for the
first client, use their QoS requirements (assuming they are above the White
House's minimum and below the whitehouse's maximum). Then the next client
was a bit better quality, and I am suggesting that is only achievable if the
White House sends the information in the appropriate format to the quality
requested. Now what happens if *every* client does that. Looks awfully
similar to a DOS attack?

If this example is too extreme (we handle only less clients) - then what is
the limit - 10 clients? 100? 1000? How do we decide how many?

> 
> Dick
> 
> -----Original Message-----
> From: Paulo Mendes [mailto:mendes@cs.columbia.edu]
> Sent: 23 January 2002 01:21
> To: Roy, Radhika R, ALASO
> Cc: Schneider, Marco; Gary Kenward; Loughney John (NRC/Helsinki);
> brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
> dick.rr.knight@bt.com; nsis@ietf.org
> Subject: Re: [NSIS] Two kinds of requirements
> 
> 
> If I understood correctly NSIS should be a QoS signalling protocol 
> useful to all applications, right?
> 
> However it seems that this division between Application Layer QoS 
> signalling (NSIS QoS) and posterior reservation request to the network 
> for the necessary QoS agreed to at the session level only works for 
> one-to-one applications, like IP telephony.
> 
> What happens with one-to-many applications like video-on-demand or 
> InternetTV? In this case you can't establish a session level QoS 
> agreement between provider and clients before the session starts (and so 
> before the reservation of resources) because you would not know all your 
> clients at that time.
> 
> Paulo Mendes
> 
> 
> 
> 
> Roy, Radhika R, ALASO wrote:
> 
> 
>>Hi, Marco:
>>
>>Let me try to clarify from your point of view.
>>
>>It seems to agree that there needs to be a session level QOS agreement.
>>
> Let us analyze what is this. To make an agreement, we need to send some
> messages between the end points. This may be termed as "signaling."
> 
>>A session expresses its QOS for its "application" that may consist of
>>
> media: audio, video, and/or data.
> 
>>In general, the above two items can be expressed as "Application Layer QOS
>>
> signaling."
> 
>>I think that we are agreeing on technical points.
>>
>>Best regards,
>>Radhika R. Roy
>>
>>-----Original Message-----
>>From: Schneider, Marco [mailto:schneider@tri.sbc.com]
>>Sent: Friday, January 18, 2002 3:10 PM
>>To: Roy, Radhika R, ALASO; Gary Kenward; Loughney John (NRC/Helsinki);
>>brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
>>dick.rr.knight@bt.com
>>Cc: nsis@ietf.org
>>Subject: RE: [NSIS] Two kinds of requirements
>>
>>
>>Hi Roy,
>>
>>Below is the original text from your reponse to Gary Kenward. Hopefully
>>
> the
> 
>>context is clear.
>>
>>"[Roy, Radhika R, ALARC]  I would say that it is the QOS needs of the
>>application (e.g., SIP-based VoIP) that the user likes to express (as
>>opposed to "service"). Similarly, instead of network services, we would
>>
> say
> 
>>network layer QOS services (e.g., RSVP, DiffServ, MPLS). We would develop
>>the end-to-end (application layer) QOS signaling protocol (say, NSIS QOS).
>>Now, there needs to have some kinds of standards how NSIS QOS will be
>>
> mapped
> 
>>over RSVP, DiffServ, MPLS, etc."
>>
>>So by End-to-End you mean between directly between two "users". This is
>>session level signaling and I don't believe the signaling part is within
>>
> the
> 
>>scope of this working group. An application level QOS specification may
>>
> be. 
> 
>>After a session level agreement on QOS, the host/client/customer will need
>>to signal an actual reservation request to the network for the necessary
>>
> QOS
> 
>>agreed to at the session level. This is the protocol that we need to work
>>on. 
>>
>>This approach is discussed in the SIP draft "SIP Extensions for Media
>>Authorization" (draft-ietf-sip-call-auth-03.txt) and the RAP draft
>>"Framework for session set-up with media authorization"
>>(draft-ietf-rap-session-auth-02.txt).
>>
>>Marco Schneider
>>
>>-----Original Message-----
>>From: Roy, Radhika R, ALASO [mailto:rrroy@att.com]
>>Sent: Friday, January 18, 2002 9:18 AM
>>To: Schneider, Marco; Gary Kenward; Loughney John (NRC/Helsinki);
>>brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
>>dick.rr.knight@bt.com
>>Cc: nsis@ietf.org
>>Subject: RE: [NSIS] Two kinds of requirements
>>
>>
>>Defined below [RRR]
>>
>>-----Original Message-----
>>From: Schneider, Marco [mailto:schneider@tri.sbc.com]
>>Sent: Thursday, January 17, 2002 8:47 PM
>>To: Roy, Radhika R, ALASO; Gary Kenward; Loughney John (NRC/Helsinki);
>>brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
>>dick.rr.knight@bt.com
>>Cc: nsis@ietf.org
>>Subject: RE: [NSIS] Two kinds of requirements
>>
>>
>>Hi Roy,
>>
>>Can you please define what you mean by "End-to-End Application Layer QOS
>>Signaling". Thanks.
>>
>>[RRR] Suppose an user is initiation a SIP call to another user with audio,
>>video, and data. The use needs to express the needs of QOS for audio,
>>
> video,
> 
>>and data to another user. 
>>
>>[RRR] The signaling mechanism that allows to express the QOS parameters of
>>audio, video, and data is termed as the "End-to-End Application Layer QOS
>>Signaling."
>>
>>Marco Schneider
>>
>>_______________________________________________
>>nsis mailing list
>>nsis@ietf.org
>>https://www1.ietf.org/mailman/listinfo/nsis
>>
>>
> 
> 


-- 
| Paulo Mendes
| www.cs.columbia.edu/~mendes

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



From daemon@optimus.ietf.org  Fri Jan 25 10:15: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 KAA04739
	for <nsis-archive@odin.ietf.org>; Fri, 25 Jan 2002 10:15:20 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id KAA19390
	for nsis-archive@odin.ietf.org; Fri, 25 Jan 2002 10:15: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 KAA18863;
	Fri, 25 Jan 2002 10:05: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 KAA18835
	for <nsis@optimus.ietf.org>; Fri, 25 Jan 2002 10:05:51 -0500 (EST)
Received: from cbibipnt03.HC.BT.COM (saturn.bt.com [193.113.57.20])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04504
	for <nsis@ietf.org>; Fri, 25 Jan 2002 10:05:46 -0500 (EST)
From: dick.rr.knight@bt.com
Received: by cbibipnt03.hc.bt.com with Internet Mail Service (5.5.2652.35)
	id <DQ1X3J55>; Fri, 25 Jan 2002 15:02:30 -0000
Message-ID: <451D45016C2CD2119DA50000F8FE7F07080E5A8A@mlngcbnt01.hc.bt.com>
To: nsis@ietf.org
Date: Fri, 25 Jan 2002 15:02:06 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [NSIS] Requirements for NSIS
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


First of all, I must apologise if any of this is already covered, I have
"skimmed" the last two days emails.
 
We have had some very nice chats. Now we need to move forward.

Here are some observations against some recent posts:

john.loughney@nokia.com wrote (in reply to pingpan@juniper.net)
Hi Ping,

> Before we define end-to-end, edge-to-edge and 
> domain-to-domain, ask the 
> following:
> 
> - why do we signal in the first place?
> - where do we need to signal?
> - will signaling work in provider's networks?
> 
> We signal because there is no QoS when we are using some inter-active 
> real-time applications. Since most of the Internet traffic is 
> not within the scope of this "inter-active" and "real-time", let's not 
> consider a kitchen-sink signaling protocol.

I agree.  You are asking very good questions and these are
the items we should focus on.

John
--------------

Dick Knight:
Good questions. But then, why is Internet Traffic not within scope? Why are
only "inter-active" and "real-time" within scope?

Businesses will pay money for "IP VPN" between geographical locations, using
service provider networks.
They want the same sort of responsiveness they get on their LAN. So wouldn't
QoS enable IP VPN sell?
Why have a different solution for that?

REQUIREMENT: NSIS should support QoS signalling requests from the end-user
REGARDLESS of the application.
--
ADAPTIVE Applications.
(too much discussion to extract)
We all agree that:
	The wireless part of the mobile access network needs adaptive
solutions. These are application, network and sceanrio dependent. Much
needed, but not part of NSIS.
HOWEVER, NSIS should support adaptive applications, and I think the
consensus is moving to ... by the support for negotiation and
re-negotiation. It is still the application that controls the negotiation in
NSIS, but (one example) triggered by a network congestion indication in the
application flow packets (e.g. RTCP packets).

If we carry on with the adaptive thread we will re-invent TCP throttling,
ISUP ACC, and Q.2931 GFC (or even ^S ^Q interactions in RS232).
--

john.loughney@nokia.com wrote (in reply to mendes@cs.columbia.edu):
>What happens with one-to-many applications like video-on-demand or 
>> InternetTV? In this case you can't establish a session level QoS 
>> agreement between provider and clients before the session 
>> starts (and so before the reservation of resources) because you would 
>> not know all your clients at that time.
>
>Currently, I do not see this as a major part of NSIS.  I think this
>should be held for later consideration.  I do not see that VOD or
>Internet TV as burning issues.  I'm hoping we focus on one-to-one
>signaling.

Dick Knight:
	VoD may or may not be muticast, it is undefined. Internet TV (and
radio) is.
The problem is that support for multicast/multi-enduser cannot be added
later. It is like
security (and even QoS!) these things are easier designed in in the first
place.
So we ought to have multicast at the back of our minds and at aleast put
some "hooks for the future" in.

REQUIREMENT: NSIS needs to be extensible to multicast applications and
"connections" (streams?).
--

More basic requirements that have not been addressed:
NSIS signalling shall be .... Robust, reliable, secure, simple.
NSIS signalling shall be ... able to request the Establishment, Negotiation,
Maintenance, Modification and Release of communications streams (or
connections?) between two or more end-users. Such requests shall be acted
upon by all end-users and networks supporting the NSIS signalling, as
depicted in the framework document ....


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



From daemon@optimus.ietf.org  Fri Jan 25 10:47: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 KAA05475
	for <nsis-archive@odin.ietf.org>; Fri, 25 Jan 2002 10:47:21 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id KAA21172
	for nsis-archive@odin.ietf.org; Fri, 25 Jan 2002 10:47: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 KAA21095;
	Fri, 25 Jan 2002 10:46: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 KAA21051
	for <nsis@optimus.ietf.org>; Fri, 25 Jan 2002 10:46:02 -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 KAA05442
	for <nsis@ietf.org>; Fri, 25 Jan 2002 10:45:56 -0500 (EST)
Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56])
	by zcars0m9.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g0PFjQX27447;
	Fri, 25 Jan 2002 10:45:26 -0500 (EST)
Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7])
	by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g0PFjN400808;
	Fri, 25 Jan 2002 10:45:24 -0500 (EST)
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19)
	id <C8PZ6LN7>; Fri, 25 Jan 2002 10:45:26 -0500
Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA47B8@zcard031.ca.nortel.com>
From: "Gary Kenward"<gkenward@nortelnetworks.com>
To: "'David.Partain@ericsson.com'" <David.Partain@ericsson.com>,
        NSIS Mailing List <nsis@ietf.org>
Subject: RE: [NSIS] Framework & requirements part of the"Two kinds of  req
	uirements" thread
Date: Fri, 25 Jan 2002 10:45:27 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C1A5B7.4F9445C0"
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_01C1A5B7.4F9445C0
Content-Type: text/plain;
	charset="ISO-8859-1"

Yes. There is wireless internet access to a variety of old and
new, mobile enabled applications. 

I know you were responding tongue firmly planted in cheek, but
a) you do not need IP for wireless voice, indeed, there is, IMHO,
little value in adopting IP for wirless voice; b) wireless Internet
access does not exist, and the reasons are very similar to the issues
around providing QoS in the wired network; c) not all QoS IP flows
are voice, nor are is all QoS simply real time related.

Cheers,
Gary

> -----Original Message-----
> From: David Partain [mailto:David.Partain@ericsson.com]
> Sent: January 25, 2002 04:03
> To: NSIS Mailing List
> Subject: Re: [NSIS] Framework & requirements part of the"Two kinds of
> requirements" thread
> 
> 
> Hi all,
> 
> I wrote:
> dp> If we try to throw every possible problem area into the NSIS
> dp> work, this working group will still be talking when we're rolling
> dp> out 8th generation mobile telephony :-)
> 
> John Loughney responded:
> jl> Hopefully, we are thinking of more than just mobile telephony ;)
> 
> Is there anything else?  :-)
> 
> jl> Please note that we are looking to solve practical problems, while
> jl> ensure an open structure / framework for future extensibility.
> jl> The reason for the short timeline on the deliverables is 
> to help us
> jl> focus on the task at hand.  I do not think we should through every
> jl> possible problem at NSIS.
> 
> I wholeheartedly and emphatically support this approach.
> 
> Cheers,
> 
> dlp
> 
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis
> 

------_=_NextPart_001_01C1A5B7.4F9445C0
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] Framework &amp; requirements part of the&quot;Two =
kinds of  requirements&quot; thread</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Yes. There is wireless internet access to a variety =
of old and</FONT>
<BR><FONT SIZE=3D2>new, mobile enabled applications. </FONT>
</P>

<P><FONT SIZE=3D2>I know you were responding tongue firmly planted in =
cheek, but</FONT>
<BR><FONT SIZE=3D2>a) you do not need IP for wireless voice, indeed, =
there is, IMHO,</FONT>
<BR><FONT SIZE=3D2>little value in adopting IP for wirless voice; b) =
wireless Internet</FONT>
<BR><FONT SIZE=3D2>access does not exist, and the reasons are very =
similar to the issues</FONT>
<BR><FONT SIZE=3D2>around providing QoS in the wired network; c) not =
all QoS IP flows</FONT>
<BR><FONT SIZE=3D2>are voice, nor are is all QoS simply real time =
related.</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: David Partain [<A =
HREF=3D"mailto:David.Partain@ericsson.com">mailto:David.Partain@ericsson=
.com</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: January 25, 2002 04:03</FONT>
<BR><FONT SIZE=3D2>&gt; To: NSIS Mailing List</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: Re: [NSIS] Framework &amp; =
requirements part of the&quot;Two kinds of</FONT>
<BR><FONT SIZE=3D2>&gt; requirements&quot; thread</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; I wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; dp&gt; If we try to throw every possible =
problem area into the NSIS</FONT>
<BR><FONT SIZE=3D2>&gt; dp&gt; work, this working group will still be =
talking when we're rolling</FONT>
<BR><FONT SIZE=3D2>&gt; dp&gt; out 8th generation mobile telephony =
:-)</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; John Loughney responded:</FONT>
<BR><FONT SIZE=3D2>&gt; jl&gt; Hopefully, we are thinking of more than =
just mobile telephony ;)</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Is there anything else?&nbsp; :-)</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; jl&gt; Please note that we are looking to solve =
practical problems, while</FONT>
<BR><FONT SIZE=3D2>&gt; jl&gt; ensure an open structure / framework for =
future extensibility.</FONT>
<BR><FONT SIZE=3D2>&gt; jl&gt; The reason for the short timeline on the =
deliverables is </FONT>
<BR><FONT SIZE=3D2>&gt; to help us</FONT>
<BR><FONT SIZE=3D2>&gt; jl&gt; focus on the task at hand.&nbsp; I do =
not think we should through every</FONT>
<BR><FONT SIZE=3D2>&gt; jl&gt; possible problem at NSIS.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I wholeheartedly and emphatically support this =
approach.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Cheers,</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; dlp</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_01C1A5B7.4F9445C0--

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



From daemon@optimus.ietf.org  Fri Jan 25 10:51:31 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05550
	for <nsis-archive@odin.ietf.org>; Fri, 25 Jan 2002 10:51:26 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id KAA21583
	for nsis-archive@odin.ietf.org; Fri, 25 Jan 2002 10:51: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 KAA20873;
	Fri, 25 Jan 2002 10:41: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 KAA20838
	for <nsis@optimus.ietf.org>; Fri, 25 Jan 2002 10:41:39 -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 KAA05272
	for <nsis@ietf.org>; Fri, 25 Jan 2002 10:41:33 -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 g0PFfY8n012427
	for <nsis@ietf.org>; Fri, 25 Jan 2002 16:41:34 +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 <0GQI0013R3L8OU@mbb1.ericsson.se> for nsis@ietf.org; Fri,
 25 Jan 2002 16:41:34 +0100 (MET)
Date: Fri, 25 Jan 2002 16:42:07 +0100
From: David Partain <David.Partain@ericsson.com>
Subject: Re: [NSIS] Framework & requirements part of the
 "Two kinds of  requirements" thread
In-reply-to: <9FBD322B7824D511B36900508BF93C9C01AA47B2@zcard031.ca.nortel.com>
To: "'NSIS Mailing List'" <nsis@ietf.org>
Reply-to: David.Partain@ericsson.com
Message-id: <0GQI0013S3LAOU@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: <9FBD322B7824D511B36900508BF93C9C01AA47B2@zcard031.ca.nortel.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

Greetings all,

> On Thursday 24 January 2002 17:17, Gary Kenward wrote:
> I don't believe that anyone has proposed "kitchen sink" or
> signalling that is not needed.

Perhaps that is the case.  I guess my wariness grows out
of seeing folks in many contexts try to solve everything
in this rather complex problem area all at once.  Seen
individually, most of the ideas are likely a Good Thing, but
seen collectively, it's just too much.  I guess Ping is just
raising a red flag and I think that's useful.

> I believe that there are a number of very important problem
> areas that need to be addressed. At the moment, the prevalent
> thread is whether all or many of these signalling needs can be
> resolved with one protocol. There is a great risk in attacking
> the problem in a piecemeal fashion: the result may not hold
> solve enough of the problem to be useful.

I certainly agree and wouldn't advocate piecemeal.  I just
_know_ that we won't solve everything now, even if we try.
As such, we need to solve what is most acute and put something
in place that makes solving later problems easier.

> Some specific comments:
> 
>   - if there is a need for a protocol to run end-to-end at the
>     application layer without interacting with the network,
>     then this can be resolved in two ways: a separate protocol
>     that is designed *only* for this purpose; a protocol
>     that can interact with a network, if the network is able
>     and willing (i.e. has the functional and policy support).
>     the first solution fulfils only one of the needs stated so
>     far on this list, and implies a requirement for multiple
>     signalling protocols to set up the end to end *and* network
>     QoS; on the plus side, it is a self contained problem
>     (by definition), independent upon network architecture.
> 
>     the second solution is tougher because it requires
>     a definition of a generic framework that will allow
>     interaction between the end-to- end and entities within
>     the network; on the plus side, it is likely to be more
>     efficient then the first solution.

I'm not sure that I've got all the implications of what you
write, but based on what I think I get, we need to work on the
latter of the two.

>   - implicit in Ping Pan's proposal is the idea that a useful
>     signalling protocol will emerge out of the sequential
>     development of hop-by-hop signalling (i.e. host to edge,
>     node to node, edge to edge, etc.); this is somewhat like
>     trying to build a jet engine one piece at a time, it will
>     not work unless you have an idea where the pieces fit
>     ahead of time.

No doubt about it.  We need the overall plan as well.

>   - while I'm not entirely sure what Ping Pan means by an
>     "application" (i.e. a usage scenario coupled with network
>     services, a piece of software) basing the design on a
>     subset of applications may be the fastest way of generating
>     a solution, but no likely the most useful in the long term.

As long as we can avoid doing something Fatally Dumb in terms
of extensibilty, it might be both the fastest way and useful
in the long term.

> Finally, I support the idea of tackling a specific problem
> are first: my preference being host to edge, but I strongly
> recommend that we make an attempt to define a strawman
> framework first. I emphasize "strawman" - the term implies
> that the framework will be evolve significantly.

Yep.  This is one of our tasks.

> I do not support the idea of using a subset of applications
> to design a protocol.  I like the idea of using use cases,
> as long as they are acceptable to the IESG, and as long as
> they go beyond "user/end system interaction".

Perhaps I'm just missing something, but I see the applications
as use cases.  If I take the "application" of cellular mobile
telephony (only as one of the possible applications, folks :-)),
that provides a good use case for what we're defining.

Cheers,

dlp

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



From daemon@optimus.ietf.org  Fri Jan 25 11:00: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 KAA05796
	for <nsis-archive@odin.ietf.org>; Fri, 25 Jan 2002 10:59:59 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id LAA22114
	for nsis-archive@odin.ietf.org; Fri, 25 Jan 2002 11:00: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 KAA21993;
	Fri, 25 Jan 2002 10:58: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 KAA21960
	for <nsis@optimus.ietf.org>; Fri, 25 Jan 2002 10:58:13 -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 KAA05758
	for <nsis@ietf.org>; Fri, 25 Jan 2002 10:58:10 -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 g0PFwEj13743;
	Fri, 25 Jan 2002 16:58:14 +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 94699C05B; Fri, 25 Jan 2002 16:57:38 +0100 (CET)
Date: Fri, 25 Jan 2002 17:09:28 +0100
From: Marcus Brunner <brunner@ccrle.nec.de>
Reply-To: brunner@ccrle.nec.de
To: "Georgios Karagiannis (ELN)" <Georgios.Karagiannis@eln.ericsson.se>,
        "'Schneider, Marco'" <schneider@tri.sbc.com>
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements
Message-ID: <23701871.1011978568@[192.168.102.79]>
In-Reply-To: <E244E44D6AB85E40AEEF7EAABE3545FA82338D@enleent104.nl.eu.ericsson.se>
References:  <E244E44D6AB85E40AEEF7EAABE3545FA82338D@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

Looks nice for fixed network. However, as soon as mobility is involved it 
gets more difficult. That was the reason that in our framewrok we talk 
about QoS initiator and QoS controller, instead of teh componenets where 
the componenets are sitting (which we find not really relevant)

Marcus

--On Tuesday, January 22, 2002 10:39 AM +0100 "Georgios Karagiannis (ELN)" 
<Georgios.Karagiannis@eln.ericsson.se> wrote:

> Hi Marco
>
> The possible NSIS protocol components that can be
> used on the different NSIS protocol types are the following:
>
>  * used components in "end host to end host" NSIS scenario:
>       [everyhost], [everyedge], [everyhop]
>
>  * used components in "end host to proxy" NSIS scenario:
>       [everyhost], [everyedge], [everyhop]
>
>  * used components in "end host to edge" NSIS scenario:
>       [everyedge], [everyhop]
>
>  * used components in "edge to edge" NSIS scenario:
>       [everyedge], [everyhop]
>
> Regarding the priority, we should decide it after the requirements,
> architecture and framework drafts are done!
>
> Best regards,
> Georgios
>
> -----Original Message-----
> From: Schneider, Marco [mailto:schneider@tri.sbc.com]
> Sent: dinsdag 22 januari 2002 1:03
> To: 'Georgios Karagiannis (ELN)'; 'dick.rr.knight@bt.com'
> Cc: nsis@ietf.org
> Subject: RE: [NSIS] Two kinds of requirements
>
>
> Hi Georgios, All
>
> If by x -- y you mean a protocol that runs directly between x and y (e.g.
> end host -- end host, end host -- proxy...) then strictly speaking we are
> discussing four  functionally distinct interfaces and thus four
> functionally distinct protocols(possibly three if we group end host --
> proxy and  end host -- edge together). In my opinion: First we need to
> decide which of these interfaces are in scope. Second we need to decide
> which one(s) we will address first. Third we need to define the
> requirements for each for each of the interfaces independently.
>
> With respect to scope and priority, I think we need to address in order:
> 1) end host -- edge/proxy
> 2) domain edge -- domain edge
>
>
> Marco
>
>
> -----Original Message-----
> From: Georgios Karagiannis (ELN)
> [mailto:Georgios.Karagiannis@eln.ericsson.se]
> Sent: Monday, January 21, 2002 4:30 AM
> To: 'dick.rr.knight@bt.com'
> Cc: nsis@ietf.org
> Subject: RE: [NSIS] Two kinds of requirements
>
>
>
> Hi Dick
>
> Please see my comment in line:
> [DK]>> I do agree that it need not be processed on a per hop basis as it
> can [DK]>> transverse a domain with a single QoS mechanism. That
> mechanism, be it
> [DK]>> diffserv or intserv, PNNI, RSVP, or even over-provisioning, takes
> care of
> [DK]>> the policing and the "path" establishment within the domain.
>
> Please note that at the moment there are scenarios that will need to
> process the [everyhop] component. Some of these scenarios are the Radio
> Access
> Network and Mobile IP,..
> Therefore, the [everyhop] component should be supported by the NSIS
> protocol.
> However a "host" or a "edge" should be able to activated or not.
>
> Furthermore, in my opinion the NSIS protocol should be:
> end host - end host: the NSIS protocol is terminated at end hosts;
> end host - proxy: the NSIS protocol is terminated at end host and proxy;
> end host - edge: the NSIS protocol is terminated at end end host and edge;
> edge - edge: the NSIS protocol is terminated at egdes of one/multiple
> domains;
>
>
> Best regards,
> Georgios
>
>
> -----Original Message-----
> From: Schneider, Marco [mailto:schneider@tri.sbc.com]
> Sent: 18 January 2002 20:10
> To: 'Roy, Radhika R, ALASO'; Gary Kenward; Loughney John (NRC/Helsinki);
> brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
> dick.rr.knight@bt.com
> Cc: nsis@ietf.org
> Subject: RE: [NSIS] Two kinds of requirements
>
>
> Hi Roy,
>
> Below is the original text from your reponse to Gary Kenward. Hopefully
> the context is clear.
>
> "[Roy, Radhika R, ALARC]  I would say that it is the QOS needs of the
> application (e.g., SIP-based VoIP) that the user likes to express (as
> opposed to "service"). Similarly, instead of network services, we would
> say network layer QOS services (e.g., RSVP, DiffServ, MPLS). We would
> develop the end-to-end (application layer) QOS signaling protocol (say,
> NSIS QOS). Now, there needs to have some kinds of standards how NSIS QOS
> will be mapped over RSVP, DiffServ, MPLS, etc."
>
> So by End-to-End you mean between directly between two "users". This is
> session level signaling and I don't believe the signaling part is within
> the scope of this working group. An application level QOS specification
> may be.
>
> After a session level agreement on QOS, the host/client/customer will need
> to signal an actual reservation request to the network for the necessary
> QOS agreed to at the session level. This is the protocol that we need to
> work on.
>
> This approach is discussed in the SIP draft "SIP Extensions for Media
> Authorization" (draft-ietf-sip-call-auth-03.txt) and the RAP draft
> "Framework for session set-up with media authorization"
> (draft-ietf-rap-session-auth-02.txt).
>
> Marco Schneider
>
> -----Original Message-----
> From: Roy, Radhika R, ALASO [mailto:rrroy@att.com]
> Sent: Friday, January 18, 2002 9:18 AM
> To: Schneider, Marco; Gary Kenward; Loughney John (NRC/Helsinki);
> brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
> dick.rr.knight@bt.com
> Cc: nsis@ietf.org
> Subject: RE: [NSIS] Two kinds of requirements
>
>
> Defined below [RRR]
>
> -----Original Message-----
> From: Schneider, Marco [mailto:schneider@tri.sbc.com]
> Sent: Thursday, January 17, 2002 8:47 PM
> To: Roy, Radhika R, ALASO; Gary Kenward; Loughney John (NRC/Helsinki);
> brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
> dick.rr.knight@bt.com
> Cc: nsis@ietf.org
> Subject: RE: [NSIS] Two kinds of requirements
>
>
> Hi Roy,
>
> Can you please define what you mean by "End-to-End Application Layer QOS
> Signaling". Thanks.
>
> [RRR] Suppose an user is initiation a SIP call to another user with audio,
> video, and data. The use needs to express the needs of QOS for audio,
> video, and data to another user.
>
> [RRR] The signaling mechanism that allows to express the QOS parameters of
> audio, video, and data is termed as the "End-to-End Application Layer QOS
> Signaling."
>
> Marco Schneider
>
> _______________________________________________
> 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
>



--------------------------------------
Dr. Marcus Brunner
Network Laboratories
NEC Europe Ltd.

E-Mail: brunner@ccrle.nec.de
WWW:    http://www.ccrle.nec.de/
personal home page: http://www.brubers.org/marcus



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



From daemon@optimus.ietf.org  Fri Jan 25 11:00: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 LAA05844
	for <nsis-archive@odin.ietf.org>; Fri, 25 Jan 2002 11:00:20 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id LAA22261
	for nsis-archive@odin.ietf.org; Fri, 25 Jan 2002 11:00: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 KAA21517;
	Fri, 25 Jan 2002 10:50: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 KAA21450
	for <nsis@optimus.ietf.org>; Fri, 25 Jan 2002 10:50:26 -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 KAA05533
	for <nsis@ietf.org>; Fri, 25 Jan 2002 10:50:23 -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 g0PFoPj13727;
	Fri, 25 Jan 2002 16:50:25 +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 8A797C05B; Fri, 25 Jan 2002 16:49:41 +0100 (CET)
Date: Fri, 25 Jan 2002 17:01:31 +0100
From: Marcus Brunner <brunner@ccrle.nec.de>
Reply-To: brunner@ccrle.nec.de
To: "Allen, Keith" <kallen@tri.sbc.com>, nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements
Message-ID: <23224795.1011978091@[192.168.102.79]>
In-Reply-To: <905A1C4ABF353F4C8CC16FA9F53DD0D62A6FF8@TRIMAIL2.ad.tri.sbc.com>
References:  <905A1C4ABF353F4C8CC16FA9F53DD0D62A6FF8@TRIMAIL2.ad.tri.sbc.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

Keith,

In http://search.ietf.org/internet-drafts/draft-brunner-nsis-req-00.txt we 
have 4 different scenarios.
1) A user reqests QoS -> moves to a different access router (mobility 
scenario)
2) A user has a running session with defined QoS negotiated move the 
session to a different terminal (different IP address) (session mobility)
3) A access network provider requests QoS from a backbone provider (I think 
this what people call access to core signalling)
4) A backbone provider requests QoS from another backbone provider 
(inter-domain)

Is this what you mean by use cases? I have to admit that the simplest case 
(the one used before 1 and 2 can happen has been forgotten (the user 
requests QoS)

Marcus

--On Monday, January 21, 2002 1:07 PM -0600 "Allen, Keith" 
<kallen@tri.sbc.com> wrote:

> All,
>
> Along the lines of my earlier reference to Use Cases, what do you think
> about beginning to document the requirements the protocol should meet as a
> set of use cases describing how network users (or actually their network
> devices) use the protocol-to-be to access the QoS capabilities of the
> network.  For example, one use case could show a voice over IP caller,
> another a network administrator setting up an Ethernet VPN, etc.  If the
> protocol has to support mobile handoffs, we would have a use case showing
> that.  It would give us a focal point instead of just e-mail.
>
>
> Keith Allen
> SBC Technology Resources
> 9505 Arboretum Blvd.
> Austin, TX 78759
> (512) 372-5741
> kallen@tri.sbc.com
>
>  -----Original Message-----
> From: 	Allen, Keith
> Sent:	Monday, January 21, 2002 11:37 AM
> To:	nsis@ietf.org
> Subject:	RE: [NSIS] Two kinds of requirements
>
> Should the design of the protocol be driven by the needs of the user or
> the currently implemented network?  If we choose the latter we will end
> up with a protocol that will be obsolete when the next new network
> innovation takes place, and it may not meet the basic needs of the
> subscriber.
>
> The Object-Oriented software world has turned to user-centric requirements
> (in the form of Use Cases) as the basis for analysis and design.  They are
> getting good results with this process.  We should also focus on what the
> user wants to do.  The user sends a request to the network, then he
> doesn't care what the network has to do to meet it.  If it turns out that
> RSVP can't meet the needs of the subscriber it will have to evolve or be
> replaced. Unfortunately, though, we don't even know if RSVP will suffice
> because we haven't captured what the user can do.
>
> Form follows function.  The function of this protocol should be to enable
> subscribers to utilize the guaranteed QoS capabilities of the network on
> demand.
>
>
> Keith Allen
> SBC Technology Resources
> 9505 Arboretum Blvd.
> Austin, TX 78759
> (512) 372-5741
> kallen@tri.sbc.com
>
>  -----Original Message-----
> From: 	dick.rr.knight@bt.com [mailto:dick.rr.knight@bt.com]
> Sent:	Monday, January 21, 2002 11:15 AM
> To:	Chen, Weijing; Georgios.Karagiannis@eln.ericsson.se
> Cc:	nsis@ietf.org
> Subject:	RE: [NSIS] Two kinds of requirements
>
> Weijing,
>
> I can understand your desire to concentrate on the user-network problem
> space.
>
> However - I am concerned that the result will be an agreed and working
> solution
> in this problem space that is then not supported at the network-network
> interface
> (interdomain in IP speak, NNI in PSTN jargon).
>
> If the user-network interface is one protocol and then the next hop is
> RSVP with intserv,
> then the next is MPLS with LSP and so on, will you see anything at the far
> and distant end
> that looks anything like the original user-network request?
>
> Dick
>
> -----Original Message-----
> From: Chen, Weijing [mailto:wchen@tri.sbc.com]
> Sent: 21 January 2002 16:20
> To: 'Georgios Karagiannis (ELN)'
> Cc: 'nsis@ietf.org'
> Subject: RE: [NSIS] Two kinds of requirements
>
>
> I am afraid that we are creating a Utopian solution here.
>
>>> Therefore, the [everyhop] component should be supported by the NSIS
> protocol.
>>> However a "host" or a "edge" should be able to activated or not.
>
> It is not question of who activate it. It is the question of who initiate
> it. Who is going to stuff the [everyhop] component into signaling message?
> Don't expect it from [end host].
>
>>> Furthermore, in my opinion the NSIS protocol should be:
>>> end host - end host: the NSIS protocol is terminated at end hosts;
>>> end host - proxy: the NSIS protocol is terminated at end host and proxy;
>
>>> end host - edge: the NSIS protocol is terminated at end end host and
>>> edge;
> This should be our focus now.
>
>>> edge - edge: the NSIS protocol is terminated at egdes of one/multiple
> domains;
>
> Yes, a universal protocol used by different segments is very nice. But can
> it be agreed on and implementable? The missing piece in today's protocol
> soup is user-to-network signaling, sort of DTMF in data world. Let's solve
> it first here in NSIS. Later on we can engage on a more ambition mission.
>
> --
> Weijing Chen
> SBC Technology Resources
> 9505 Arboretum Blvd.
> Austin, TX 78759
> 512 372 5710
> wchen@tri.sbc.com
>
> -----Original Message-----
> From: 	Georgios Karagiannis (ELN)
> [mailto:Georgios.Karagiannis@eln.ericsson.se]
> Sent:	Monday, January 21, 2002 4:30 AM
> To:	'dick.rr.knight@bt.com'
> Cc:	nsis@ietf.org
> Subject:	RE: [NSIS] Two kinds of requirements
>
>
> Hi Dick
>
> Please see my comment in line:
> [DK]>> I do agree that it need not be processed on a per hop basis as it
> can [DK]>> transverse a domain with a single QoS mechanism. That
> mechanism, be it
> [DK]>> diffserv or intserv, PNNI, RSVP, or even over-provisioning, takes
> care of
> [DK]>> the policing and the "path" establishment within the domain.
>
> Please note that at the moment there are scenarios that will need to
> process the [everyhop] component. Some of these scenarios are the Radio
> Access
> Network and Mobile IP,..
> Therefore, the [everyhop] component should be supported by the NSIS
> protocol.
> However a "host" or a "edge" should be able to activated or not.
>
> Furthermore, in my opinion the NSIS protocol should be:
> end host - end host: the NSIS protocol is terminated at end hosts;
> end host - proxy: the NSIS protocol is terminated at end host and proxy;
> end host - edge: the NSIS protocol is terminated at end end host and edge;
> edge - edge: the NSIS protocol is terminated at egdes of one/multiple
> domains;
>
>
> Best regards,
> Georgios
>
>
> -----Original Message-----
> From: Schneider, Marco [mailto:schneider@tri.sbc.com]
> Sent: 18 January 2002 20:10
> To: 'Roy, Radhika R, ALASO'; Gary Kenward; Loughney John (NRC/Helsinki);
> brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
> dick.rr.knight@bt.com
> Cc: nsis@ietf.org
> Subject: RE: [NSIS] Two kinds of requirements
>
>
> Hi Roy,
>
> Below is the original text from your reponse to Gary Kenward. Hopefully
> the context is clear.
>
> "[Roy, Radhika R, ALARC]  I would say that it is the QOS needs of the
> application (e.g., SIP-based VoIP) that the user likes to express (as
> opposed to "service"). Similarly, instead of network services, we would
> say network layer QOS services (e.g., RSVP, DiffServ, MPLS). We would
> develop the end-to-end (application layer) QOS signaling protocol (say,
> NSIS QOS). Now, there needs to have some kinds of standards how NSIS QOS
> will be mapped over RSVP, DiffServ, MPLS, etc."
>
> So by End-to-End you mean between directly between two "users". This is
> session level signaling and I don't believe the signaling part is within
> the scope of this working group. An application level QOS specification
> may be.
>
> After a session level agreement on QOS, the host/client/customer will need
> to signal an actual reservation request to the network for the necessary
> QOS agreed to at the session level. This is the protocol that we need to
> work on.
>
> This approach is discussed in the SIP draft "SIP Extensions for Media
> Authorization" (draft-ietf-sip-call-auth-03.txt) and the RAP draft
> "Framework for session set-up with media authorization"
> (draft-ietf-rap-session-auth-02.txt).
>
> Marco Schneider
>
> -----Original Message-----
> From: Roy, Radhika R, ALASO [mailto:rrroy@att.com]
> Sent: Friday, January 18, 2002 9:18 AM
> To: Schneider, Marco; Gary Kenward; Loughney John (NRC/Helsinki);
> brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
> dick.rr.knight@bt.com
> Cc: nsis@ietf.org
> Subject: RE: [NSIS] Two kinds of requirements
>
>
> Defined below [RRR]
>
> -----Original Message-----
> From: Schneider, Marco [mailto:schneider@tri.sbc.com]
> Sent: Thursday, January 17, 2002 8:47 PM
> To: Roy, Radhika R, ALASO; Gary Kenward; Loughney John (NRC/Helsinki);
> brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
> dick.rr.knight@bt.com
> Cc: nsis@ietf.org
> Subject: RE: [NSIS] Two kinds of requirements
>
>
> Hi Roy,
>
> Can you please define what you mean by "End-to-End Application Layer QOS
> Signaling". Thanks.
>
> [RRR] Suppose an user is initiation a SIP call to another user with audio,
> video, and data. The use needs to express the needs of QOS for audio,
> video, and data to another user.
>
> [RRR] The signaling mechanism that allows to express the QOS parameters of
> audio, video, and data is termed as the "End-to-End Application Layer QOS
> Signaling."
>
> Marco Schneider
>
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis
>
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis
>
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis
>
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis
>
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis
>
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis
>



--------------------------------------
Dr. Marcus Brunner
Network Laboratories
NEC Europe Ltd.

E-Mail: brunner@ccrle.nec.de
WWW:    http://www.ccrle.nec.de/
personal home page: http://www.brubers.org/marcus



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



From daemon@optimus.ietf.org  Fri Jan 25 11:09: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 LAA06195
	for <nsis-archive@odin.ietf.org>; Fri, 25 Jan 2002 11:09:47 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id LAA23229
	for nsis-archive@odin.ietf.org; Fri, 25 Jan 2002 11:09: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 LAA22975;
	Fri, 25 Jan 2002 11:06: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 LAA22932
	for <nsis@optimus.ietf.org>; Fri, 25 Jan 2002 11:06:32 -0500 (EST)
Received: from yamato.ccrle.nec.de (yamato.ccrle.nec.de [195.37.70.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06077
	for <nsis@ietf.org>; Fri, 25 Jan 2002 11:06:29 -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 g0PG5Fj13794;
	Fri, 25 Jan 2002 17:05:18 +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 143F3C05B; Fri, 25 Jan 2002 17:04:39 +0100 (CET)
Date: Fri, 25 Jan 2002 17:16:29 +0100
From: Marcus Brunner <brunner@ccrle.nec.de>
Reply-To: brunner@ccrle.nec.de
To: dick.rr.knight@bt.com, mendes@cs.columbia.edu, rrroy@att.com
Cc: schneider@tri.sbc.com, gkenward@nortelnetworks.com,
        john.loughney@nokia.com, ykahana@comgates.co.il,
        Ruediger.Geib@t-systems.com, nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements
Message-ID: <24122406.1011978989@[192.168.102.79]>
In-Reply-To: <451D45016C2CD2119DA50000F8FE7F07080E5A60@mlngcbnt01.hc.bt.com>
References:  <451D45016C2CD2119DA50000F8FE7F07080E5A60@mlngcbnt01.hc.bt.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

And I was hoping to get rid of one-to-many on the transport layer.
Marcus

--On Wednesday, January 23, 2002 9:27 AM +0000 dick.rr.knight@bt.com wrote:

> Nice one. I was waiting for this.
>
> So .. another new requirement. To support one-to-many applications.
>
> There are two aspects to this:
> 1. The easy case. In internet TV, a provider (source of the TV) is
> available. The first client uses NSIS to negotiate QoS with the network
> and the source. Assuming the negotiation is successful a "connection" is
> established. The second client then attepts to receive the TV. On
> initiating the NSIS negotiation of QoS, they get a "take it or leave it"
> result of the first client's negotiation. Anything else is not scalable.
> 2. A business conference will be established, with a known (limited)
> number of clients. The provider can initiate the negotiation with the
> clients to achieve the best possible QoS using the least resources.
>
> The first case is no extra requirements above an IP telephony call. The
> second requires multiparty negotiation at establishment.
>
> Dick
>
> -----Original Message-----
> From: Paulo Mendes [mailto:mendes@cs.columbia.edu]
> Sent: 23 January 2002 01:21
> To: Roy, Radhika R, ALASO
> Cc: Schneider, Marco; Gary Kenward; Loughney John (NRC/Helsinki);
> brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
> dick.rr.knight@bt.com; nsis@ietf.org
> Subject: Re: [NSIS] Two kinds of requirements
>
>
> If I understood correctly NSIS should be a QoS signalling protocol
> useful to all applications, right?
>
> However it seems that this division between Application Layer QoS
> signalling (NSIS QoS) and posterior reservation request to the network
> for the necessary QoS agreed to at the session level only works for
> one-to-one applications, like IP telephony.
>
> What happens with one-to-many applications like video-on-demand or
> InternetTV? In this case you can't establish a session level QoS
> agreement between provider and clients before the session starts (and so
> before the reservation of resources) because you would not know all your
> clients at that time.
>
> Paulo Mendes
>
>
>
>
> Roy, Radhika R, ALASO wrote:
>
>> Hi, Marco:
>>
>> Let me try to clarify from your point of view.
>>
>> It seems to agree that there needs to be a session level QOS agreement.
> Let us analyze what is this. To make an agreement, we need to send some
> messages between the end points. This may be termed as "signaling."
>>
>> A session expresses its QOS for its "application" that may consist of
> media: audio, video, and/or data.
>>
>> In general, the above two items can be expressed as "Application Layer
>> QOS
> signaling."
>>
>> I think that we are agreeing on technical points.
>>
>> Best regards,
>> Radhika R. Roy
>>
>> -----Original Message-----
>> From: Schneider, Marco [mailto:schneider@tri.sbc.com]
>> Sent: Friday, January 18, 2002 3:10 PM
>> To: Roy, Radhika R, ALASO; Gary Kenward; Loughney John (NRC/Helsinki);
>> brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
>> dick.rr.knight@bt.com
>> Cc: nsis@ietf.org
>> Subject: RE: [NSIS] Two kinds of requirements
>>
>>
>> Hi Roy,
>>
>> Below is the original text from your reponse to Gary Kenward. Hopefully
> the
>> context is clear.
>>
>> "[Roy, Radhika R, ALARC]  I would say that it is the QOS needs of the
>> application (e.g., SIP-based VoIP) that the user likes to express (as
>> opposed to "service"). Similarly, instead of network services, we would
> say
>> network layer QOS services (e.g., RSVP, DiffServ, MPLS). We would develop
>> the end-to-end (application layer) QOS signaling protocol (say, NSIS
>> QOS). Now, there needs to have some kinds of standards how NSIS QOS will
>> be
> mapped
>> over RSVP, DiffServ, MPLS, etc."
>>
>> So by End-to-End you mean between directly between two "users". This is
>> session level signaling and I don't believe the signaling part is within
> the
>> scope of this working group. An application level QOS specification may
> be.
>>
>> After a session level agreement on QOS, the host/client/customer will
>> need to signal an actual reservation request to the network for the
>> necessary
> QOS
>> agreed to at the session level. This is the protocol that we need to work
>> on.
>>
>> This approach is discussed in the SIP draft "SIP Extensions for Media
>> Authorization" (draft-ietf-sip-call-auth-03.txt) and the RAP draft
>> "Framework for session set-up with media authorization"
>> (draft-ietf-rap-session-auth-02.txt).
>>
>> Marco Schneider
>>
>> -----Original Message-----
>> From: Roy, Radhika R, ALASO [mailto:rrroy@att.com]
>> Sent: Friday, January 18, 2002 9:18 AM
>> To: Schneider, Marco; Gary Kenward; Loughney John (NRC/Helsinki);
>> brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
>> dick.rr.knight@bt.com
>> Cc: nsis@ietf.org
>> Subject: RE: [NSIS] Two kinds of requirements
>>
>>
>> Defined below [RRR]
>>
>> -----Original Message-----
>> From: Schneider, Marco [mailto:schneider@tri.sbc.com]
>> Sent: Thursday, January 17, 2002 8:47 PM
>> To: Roy, Radhika R, ALASO; Gary Kenward; Loughney John (NRC/Helsinki);
>> brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
>> dick.rr.knight@bt.com
>> Cc: nsis@ietf.org
>> Subject: RE: [NSIS] Two kinds of requirements
>>
>>
>> Hi Roy,
>>
>> Can you please define what you mean by "End-to-End Application Layer QOS
>> Signaling". Thanks.
>>
>> [RRR] Suppose an user is initiation a SIP call to another user with
>> audio, video, and data. The use needs to express the needs of QOS for
>> audio,
> video,
>> and data to another user.
>>
>> [RRR] The signaling mechanism that allows to express the QOS parameters
>> of audio, video, and data is termed as the "End-to-End Application Layer
>> QOS Signaling."
>>
>> Marco Schneider
>>
>> _______________________________________________
>> nsis mailing list
>> nsis@ietf.org
>> https://www1.ietf.org/mailman/listinfo/nsis
>>
>
>
> --
>| Paulo Mendes
>| www.cs.columbia.edu/~mendes
>
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis
>



--------------------------------------
Dr. Marcus Brunner
Network Laboratories
NEC Europe Ltd.

E-Mail: brunner@ccrle.nec.de
WWW:    http://www.ccrle.nec.de/
personal home page: http://www.brubers.org/marcus



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



From daemon@optimus.ietf.org  Fri Jan 25 11:14: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 LAA06307
	for <nsis-archive@odin.ietf.org>; Fri, 25 Jan 2002 11:14:35 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id LAA23648
	for nsis-archive@odin.ietf.org; Fri, 25 Jan 2002 11:14: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 LAA23551;
	Fri, 25 Jan 2002 11:13: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 LAA23520
	for <nsis@optimus.ietf.org>; Fri, 25 Jan 2002 11:13:26 -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 LAA06265
	for <nsis@ietf.org>; Fri, 25 Jan 2002 11:13:22 -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 g0PGDPj13841;
	Fri, 25 Jan 2002 17:13:25 +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 53246C05B; Fri, 25 Jan 2002 17:12:44 +0100 (CET)
Date: Fri, 25 Jan 2002 17:24:34 +0100
From: Marcus Brunner <brunner@ccrle.nec.de>
Reply-To: brunner@ccrle.nec.de
To: dick.rr.knight@bt.com, schneider@tri.sbc.com,
        Georgios.Karagiannis@eln.ericsson.se
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements (priority on the boundary
 be	tween a customer and the network)
Message-ID: <24607643.1011979474@[192.168.102.79]>
In-Reply-To: <451D45016C2CD2119DA50000F8FE7F07080E5A33@mlngcbnt01.hc.bt.com>
References:  <451D45016C2CD2119DA50000F8FE7F07080E5A33@mlngcbnt01.hc.bt.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

Dick,

There are other means for inter-domain setup. E.g., on a management 
interface, contacting for traffic trunks etc.

Marcus

--On Friday, January 18, 2002 11:12 AM +0000 dick.rr.knight@bt.com wrote:

>
> I do not agree.
>
> What is the point of completing the work enabling the customer to signal
> to the network, if the network cannot signal between domains? The network
> can never satisfy the request.
>
> Dick
>
> -----Original Message-----
> From: Schneider, Marco [mailto:schneider@tri.sbc.com]
> Sent: 18 January 2002 01:44
> To: 'Georgios Karagiannis (ELN)'; 'dick.rr.knight@bt.com'
> Cc: nsis@ietf.org
> Subject: RE: [NSIS] Two kinds of requirements
>
>
> Hi Georgios,
>
> While I agree NSIS could be used to support Interior to Interior (of one
> carrier) or Edge to Core, I think that we need to prioritize on a
> signaling protocol across the boundary between a customer and the
> network. Note that the customer could be an individual, an ISP or another
> Carrier.
>
> Marco Schneider
>
> -----Original Message-----
> From: Georgios Karagiannis (ELN)
> [mailto:Georgios.Karagiannis@eln.ericsson.se]
> Sent: Thursday, January 17, 2002 3:39 AM
> To: 'dick.rr.knight@bt.com'
> Cc: nsis@ietf.org
> Subject: RE: [NSIS] Two kinds of requirements
>
>
> Hi Dick
>
> In principle I agree with your comment (see below).
>
> [DK] >> To be more precise, I am suggesting a new protocol that is
> [DK] >> independent of the underlying transport technology and the QoS
> [DK] >> implemented and is also independent of the session control
> protocol.
>
>
> However, a very important point here is that we need to
> specify a protocol that can be used independent of the underlying
> transport  technology, but that can satisfy the QoS requirements imposed
> by these  underlying transport technologies. Otherwise the protocol will
> not be suitable
> and useful.
>
> A way of achieving this is by first creating a modular QoS signaling
> toolkit
>
> that will contain mandatory and optional QoS requirements;
> Second, specify how the protocol functionality should be separated in
> building blocks (protocol components) and define a minimum set
> of mandatory reservation options/features that should be
> processed by any network nodes, e.g., end-hosts,
> proxies, edges and interior nodes.
> An example of such a protocol decomposition is given below!
> In this way each node will only process (check and use) the protocol
> components of interest.
>
>
>| ---------|
>| ---------|
>| everyhost|<------------------------------------------------------->|ever
>| yho
> st|
>| ---------|
>| ---------|
>|         |                                                         |
>|
>| ---------|   |---------|                             |---------|
>| ---------|
>| everyedge|<->|everyedge|<--------------------------->|everyedge|<->|ever
>| yed
> ge|
>| ---------|   |---------|                             |---------|
>| ---------|
>|         |   |         |                             |         |   |
>|
>| ---------|   |---------|   |--------|   |--------|   |---------|
>| ---------|
>| everyhop |<->|everyhop |<->|everyhop|<->|everyhop|<->|everyhop
>| <->|everyhop |
>| ---------|   |---------|   |--------|   |--------|   |---------|
>| ---------|
>     host          edge        interior    interior       edge
> host
>
>
>   NSIS protocol decomposition (building blocks):
>  *  "everyhost", "everyedge" and "everyhop" are protocol components;
>  *  host: can be an end-host or a proxy and it can process and use the
> "everyhost",
>     "everyedge", and "everyhop" protocol components;
>
>  *  edge: can be a Diffserv edge, MPLS edge, etc., and it can process and
> use
>     the "everyedge", and "everyhop" protocol components. The "everyhost"
>     protocol component is not processed (used or checked);
>
>  *  interior: can be any router within a domain and it can process and
> use      only the "everyhop" protocol component.
>     The "everyhost" and "everyedge" protocol components are not
>     processed (used or checked);
>
>
> Best Regards,
> Georgios
>
> -----Original Message-----
> From: dick.rr.knight@bt.com [mailto:dick.rr.knight@bt.com]
> Sent: woensdag 16 januari 2002 13:00
> To: brian.williams@ericsson.com.au; lieve.bos@alcatel.be
> Cc: nsis@ietf.org
> Subject: RE: [NSIS] Two kinds of requirements
>
>
> I was waiting for some reaction to Brian's comments, but as there aren't
> any, here are my thoughts on the requirements:
>
> I agree with the analysis that discussion has been based around
> application-related signalling for QoS (at session level) and QoS
> signalling protocols used to actually provision the QoS at the transport
> level. Brian is right that there will never be an enhancement to a single
> session protocol that will satisfy all applications.
> However, for similar reasons, it is never going to be possible to
> prescribe a single QoS mechanism to be used in all networks. Existing
> networks (or domains) will not be changed overnight and new networks
> already face several workable mechanisms to deploy QoS.
>
> I think that what is needed is a new protocol that can signal the
> requirements of any session and can be satisfied by any QoS mechanism,
> existing or new.
> To be more precise, I am suggesting a new protocol that is independent of
> the underlying transport technology and the QoS implemented and is also
> independent of the session control protocol. Such a new protocol would be
> generic, optionally implemented by applications that would benefit from
> end-to-end QoS, and would be complimentary to the QoS mechanisms deployed
> (and of course other mechanisms, such as the routing).
>
> I think that this implies a more abstract definition of the QoS mechanism
> and may lend itself to the signalling of pre-defined QoS classes rather
> than parameters.
>
> Dick Knight
>
> -----Original Message-----
> From: Brian Williams [mailto:brian.williams@ericsson.com.au]
> Sent: 22 December 2001 23:57
> To: lieve.bos@alcatel.be
> Cc: nsis@ietf.org
> Subject: Re: [NSIS] Two kinds of requirements
>
>
> Hi.
> While the two types of signalling may be related, I think there is a
> need to develop a QoS bearer mechanism which is independent of any
> specific session signalling, and thus can be used for any application. I
> believe many of the applications which have identified requirements to
> the working group have their own specific session layer signalling (ie
> it is not end-to-end SIP).
>
> Having the session and transport protocols developed separately of
> course does not prohibit the two being used in conjunction for a
> specific application.
> /brian
>
> On Fri, 2001-12-21 at 22:24, lieve.bos@alcatel.be wrote:
>> Hello all,
>>
>> > From the discussion in Salt Lake city and the drafts submitted, one can
>> easily see that people are suggesting improvements to QoS signalling at
>> two totally different levels (some at session level and some at
>> transport level).
>>
>> First of all, there are drafts suggesting some improvements in the
>> session setup procedures (i.e. the ability to negotiate the preferred
>> QoS level between end users during SDP negotiation in SIP, so before the
>> actual resources are being setup). The QoS information negotiated at the
>> session layer determines the QoS level both endusers have to use for
>> their local access connection. This first kind of 'session level QoS
>> negotiation' happens end-to-end between the two end-users.
>>
>> Secondly, there are drafts suggesting that we need
>> improvements/alternatives for the QoS signalling protocols (e.g. RSVP)
>> used to actually provision the QoS at the transport level between two
>> endusers. This second kind of 'transport level QoS signalling' can
>> consist of several phases: end-to-edge and edge-to-edge.
>>
>> It's important that everybody realises that, in order to give endusers
>> true end-to-end Quality of Service, we need improvements for QoS both at
>> session and transport level. Also its important to understand that they
>> are not uncorrelated. Providers want to be able to control (e.g. via
>> policy control mechanisms) that the QoS requested at the transport level
>> is not exceeding the QoS negotiated/authorised previously at session
>> level. So, what about developing in NSIS a modular framework
>> incorporating both session and transport level QoS signalling with
>> possible hooks between the two layers (e.g. for policy enforcement).
>>
>> Lieve
>>
>> _______________________________________________
>> nsis mailing list
>> nsis@ietf.org
>> https://www1.ietf.org/mailman/listinfo/nsis
>
>
>
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis
>
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis
>
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis
>
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis
>



--------------------------------------
Dr. Marcus Brunner
Network Laboratories
NEC Europe Ltd.

E-Mail: brunner@ccrle.nec.de
WWW:    http://www.ccrle.nec.de/
personal home page: http://www.brubers.org/marcus



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



From daemon@optimus.ietf.org  Fri Jan 25 11:14: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 LAA06328
	for <nsis-archive@odin.ietf.org>; Fri, 25 Jan 2002 11:14:47 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id LAA23691
	for nsis-archive@odin.ietf.org; Fri, 25 Jan 2002 11:14: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 LAA22839;
	Fri, 25 Jan 2002 11:04: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 LAA22795
	for <nsis@optimus.ietf.org>; Fri, 25 Jan 2002 11:04:54 -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 LAA06060
	for <nsis@ietf.org>; Fri, 25 Jan 2002 11:04:49 -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 g0PG4p8n022309
	for <nsis@ietf.org>; Fri, 25 Jan 2002 17:04:51 +0100 (MET)
Received: FROM esealnt747.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Fri Jan 25 17:04:50 2002 +0100
Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <YHKTL872>; Fri, 25 Jan 2002 17:04:50 +0100
Message-ID: <E244E44D6AB85E40AEEF7EAABE3545FA8233C4@enleent104.nl.eu.ericsson.se>
From: "Georgios Karagiannis (ELN)" <Georgios.Karagiannis@eln.ericsson.se>
To: "'brunner@ccrle.nec.de'" <brunner@ccrle.nec.de>
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements
Date: Fri, 25 Jan 2002 17:04:32 +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

yes, but from what I understood from your draft
you assume that the QoS initiator will have to know the 
location of the QoS controller and that the 
signaling path may follow a different path than
the user data. It seems SIP to me.

Best Regards,
Georgios


-----Original Message-----
From: Marcus Brunner [mailto:brunner@ccrle.nec.de]
Sent: vrijdag 25 januari 2002 17:09
To: Georgios Karagiannis (ELN); 'Schneider, Marco'
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements


Looks nice for fixed network. However, as soon as mobility is involved it 
gets more difficult. That was the reason that in our framewrok we talk 
about QoS initiator and QoS controller, instead of teh componenets where 
the componenets are sitting (which we find not really relevant)

Marcus

--On Tuesday, January 22, 2002 10:39 AM +0100 "Georgios Karagiannis (ELN)" 
<Georgios.Karagiannis@eln.ericsson.se> wrote:

> Hi Marco
>
> The possible NSIS protocol components that can be
> used on the different NSIS protocol types are the following:
>
>  * used components in "end host to end host" NSIS scenario:
>       [everyhost], [everyedge], [everyhop]
>
>  * used components in "end host to proxy" NSIS scenario:
>       [everyhost], [everyedge], [everyhop]
>
>  * used components in "end host to edge" NSIS scenario:
>       [everyedge], [everyhop]
>
>  * used components in "edge to edge" NSIS scenario:
>       [everyedge], [everyhop]
>
> Regarding the priority, we should decide it after the requirements,
> architecture and framework drafts are done!
>
> Best regards,
> Georgios
>
> -----Original Message-----
> From: Schneider, Marco [mailto:schneider@tri.sbc.com]
> Sent: dinsdag 22 januari 2002 1:03
> To: 'Georgios Karagiannis (ELN)'; 'dick.rr.knight@bt.com'
> Cc: nsis@ietf.org
> Subject: RE: [NSIS] Two kinds of requirements
>
>
> Hi Georgios, All
>
> If by x -- y you mean a protocol that runs directly between x and y (e.g.
> end host -- end host, end host -- proxy...) then strictly speaking we are
> discussing four  functionally distinct interfaces and thus four
> functionally distinct protocols(possibly three if we group end host --
> proxy and  end host -- edge together). In my opinion: First we need to
> decide which of these interfaces are in scope. Second we need to decide
> which one(s) we will address first. Third we need to define the
> requirements for each for each of the interfaces independently.
>
> With respect to scope and priority, I think we need to address in order:
> 1) end host -- edge/proxy
> 2) domain edge -- domain edge
>
>
> Marco
>
>
> -----Original Message-----
> From: Georgios Karagiannis (ELN)
> [mailto:Georgios.Karagiannis@eln.ericsson.se]
> Sent: Monday, January 21, 2002 4:30 AM
> To: 'dick.rr.knight@bt.com'
> Cc: nsis@ietf.org
> Subject: RE: [NSIS] Two kinds of requirements
>
>
>
> Hi Dick
>
> Please see my comment in line:
> [DK]>> I do agree that it need not be processed on a per hop basis as it
> can [DK]>> transverse a domain with a single QoS mechanism. That
> mechanism, be it
> [DK]>> diffserv or intserv, PNNI, RSVP, or even over-provisioning, takes
> care of
> [DK]>> the policing and the "path" establishment within the domain.
>
> Please note that at the moment there are scenarios that will need to
> process the [everyhop] component. Some of these scenarios are the Radio
> Access
> Network and Mobile IP,..
> Therefore, the [everyhop] component should be supported by the NSIS
> protocol.
> However a "host" or a "edge" should be able to activated or not.
>
> Furthermore, in my opinion the NSIS protocol should be:
> end host - end host: the NSIS protocol is terminated at end hosts;
> end host - proxy: the NSIS protocol is terminated at end host and proxy;
> end host - edge: the NSIS protocol is terminated at end end host and edge;
> edge - edge: the NSIS protocol is terminated at egdes of one/multiple
> domains;
>
>
> Best regards,
> Georgios
>
>
> -----Original Message-----
> From: Schneider, Marco [mailto:schneider@tri.sbc.com]
> Sent: 18 January 2002 20:10
> To: 'Roy, Radhika R, ALASO'; Gary Kenward; Loughney John (NRC/Helsinki);
> brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
> dick.rr.knight@bt.com
> Cc: nsis@ietf.org
> Subject: RE: [NSIS] Two kinds of requirements
>
>
> Hi Roy,
>
> Below is the original text from your reponse to Gary Kenward. Hopefully
> the context is clear.
>
> "[Roy, Radhika R, ALARC]  I would say that it is the QOS needs of the
> application (e.g., SIP-based VoIP) that the user likes to express (as
> opposed to "service"). Similarly, instead of network services, we would
> say network layer QOS services (e.g., RSVP, DiffServ, MPLS). We would
> develop the end-to-end (application layer) QOS signaling protocol (say,
> NSIS QOS). Now, there needs to have some kinds of standards how NSIS QOS
> will be mapped over RSVP, DiffServ, MPLS, etc."
>
> So by End-to-End you mean between directly between two "users". This is
> session level signaling and I don't believe the signaling part is within
> the scope of this working group. An application level QOS specification
> may be.
>
> After a session level agreement on QOS, the host/client/customer will need
> to signal an actual reservation request to the network for the necessary
> QOS agreed to at the session level. This is the protocol that we need to
> work on.
>
> This approach is discussed in the SIP draft "SIP Extensions for Media
> Authorization" (draft-ietf-sip-call-auth-03.txt) and the RAP draft
> "Framework for session set-up with media authorization"
> (draft-ietf-rap-session-auth-02.txt).
>
> Marco Schneider
>
> -----Original Message-----
> From: Roy, Radhika R, ALASO [mailto:rrroy@att.com]
> Sent: Friday, January 18, 2002 9:18 AM
> To: Schneider, Marco; Gary Kenward; Loughney John (NRC/Helsinki);
> brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
> dick.rr.knight@bt.com
> Cc: nsis@ietf.org
> Subject: RE: [NSIS] Two kinds of requirements
>
>
> Defined below [RRR]
>
> -----Original Message-----
> From: Schneider, Marco [mailto:schneider@tri.sbc.com]
> Sent: Thursday, January 17, 2002 8:47 PM
> To: Roy, Radhika R, ALASO; Gary Kenward; Loughney John (NRC/Helsinki);
> brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
> dick.rr.knight@bt.com
> Cc: nsis@ietf.org
> Subject: RE: [NSIS] Two kinds of requirements
>
>
> Hi Roy,
>
> Can you please define what you mean by "End-to-End Application Layer QOS
> Signaling". Thanks.
>
> [RRR] Suppose an user is initiation a SIP call to another user with audio,
> video, and data. The use needs to express the needs of QOS for audio,
> video, and data to another user.
>
> [RRR] The signaling mechanism that allows to express the QOS parameters of
> audio, video, and data is termed as the "End-to-End Application Layer QOS
> Signaling."
>
> Marco Schneider
>
> _______________________________________________
> 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
>



--------------------------------------
Dr. Marcus Brunner
Network Laboratories
NEC Europe Ltd.

E-Mail: brunner@ccrle.nec.de
WWW:    http://www.ccrle.nec.de/
personal home page: http://www.brubers.org/marcus


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



From daemon@optimus.ietf.org  Fri Jan 25 11:22: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 LAA06485
	for <nsis-archive@odin.ietf.org>; Fri, 25 Jan 2002 11:22:48 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id LAA24180
	for nsis-archive@odin.ietf.org; Fri, 25 Jan 2002 11:22: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 LAA23492;
	Fri, 25 Jan 2002 11:13: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 LAA23421
	for <nsis@optimus.ietf.org>; Fri, 25 Jan 2002 11:13:13 -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 LAA06247
	for <nsis@ietf.org>; Fri, 25 Jan 2002 11:13:09 -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 g0PGFJT22929
	for <nsis@ietf.org>; Fri, 25 Jan 2002 10:15:19 -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 g0PGCbj03998
	for <nsis@ietf.org>; Fri, 25 Jan 2002 10:12:37 -0600 (CST)
Received: by TRIMAIL2.ad.tri.sbc.com with Internet Mail Service (5.5.2653.19)
	id <ZND3JH6H>; Fri, 25 Jan 2002 10:13:04 -0600
Message-ID: <905A1C4ABF353F4C8CC16FA9F53DD0D62A701E@TRIMAIL2.ad.tri.sbc.com>
From: "Allen, Keith" <kallen@tri.sbc.com>
To: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements
Date: Fri, 25 Jan 2002 10:12:55 -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

Marcus wrote:

Keith,

In http://search.ietf.org/internet-drafts/draft-brunner-nsis-req-00.txt we 
have 4 different scenarios.
1) A user reqests QoS -> moves to a different access router (mobility 
scenario)
2) A user has a running session with defined QoS negotiated move the 
session to a different terminal (different IP address) (session mobility)
3) A access network provider requests QoS from a backbone provider (I think 
this what people call access to core signalling)
4) A backbone provider requests QoS from another backbone provider 
(inter-domain)

Is this what you mean by use cases? I have to admit that the simplest case 
(the one used before 1 and 2 can happen has been forgotten (the user 
requests QoS)

Marcus

Marcus,

Use Cases are a technique used to gather and document requirements.  Using
this technique, the requirements for a system are documented as a set of use
cases which describe the ways in which all the different users of a system
use it.  The four examples you give above would be good places to start.
They would need to be fleshed out quite a bit, with discussion about what
happens when the user's goal cannot be accomplished, etc.

Use cases divide the world into the system under design (in this case, a
network interface supporting the NSIS protocol) and "actors" that utilize or
interact with the system.  My original comment was that taking a use case
approach and simply identifying who the actors are would be a step forward.
For example, if all the actors are end-users, and there are no networks that
use the protocol, that would say that the protocol is only between user and
network, and not network to network.  If there are no use cases that
describe how a user moves from one network interface to another, it would
indicate that mobile users would not be supported.

Simply listing all the different actors that will use the protocol, and the
ways in which they are going to use it would begin to define the scope of
the protocol.  The hard part, then, comes in fleshing out all those use
cases with accurate and precise statements about what the interface does.


Keith Allen
SBC Technology Resources
9505 Arboretum Blvd.
Austin, TX 78759
(512) 372-5741
kallen@tri.sbc.com

 -----Original Message-----
From: 	Marcus Brunner [mailto:brunner@ccrle.nec.de] 
Sent:	Friday, January 25, 2002 10:02 AM
To:	Allen, Keith; nsis@ietf.org
Subject:	RE: [NSIS] Two kinds of requirements

--On Monday, January 21, 2002 1:07 PM -0600 "Allen, Keith" 
<kallen@tri.sbc.com> wrote:

> All,
>
> Along the lines of my earlier reference to Use Cases, what do you think
> about beginning to document the requirements the protocol should meet as a
> set of use cases describing how network users (or actually their network
> devices) use the protocol-to-be to access the QoS capabilities of the
> network.  For example, one use case could show a voice over IP caller,
> another a network administrator setting up an Ethernet VPN, etc.  If the
> protocol has to support mobile handoffs, we would have a use case showing
> that.  It would give us a focal point instead of just e-mail.
>
>
> Keith Allen
> SBC Technology Resources
> 9505 Arboretum Blvd.
> Austin, TX 78759
> (512) 372-5741
> kallen@tri.sbc.com
>
>  -----Original Message-----
> From: 	Allen, Keith
> Sent:	Monday, January 21, 2002 11:37 AM
> To:	nsis@ietf.org
> Subject:	RE: [NSIS] Two kinds of requirements
>
> Should the design of the protocol be driven by the needs of the user or
> the currently implemented network?  If we choose the latter we will end
> up with a protocol that will be obsolete when the next new network
> innovation takes place, and it may not meet the basic needs of the
> subscriber.
>
> The Object-Oriented software world has turned to user-centric requirements
> (in the form of Use Cases) as the basis for analysis and design.  They are
> getting good results with this process.  We should also focus on what the
> user wants to do.  The user sends a request to the network, then he
> doesn't care what the network has to do to meet it.  If it turns out that
> RSVP can't meet the needs of the subscriber it will have to evolve or be
> replaced. Unfortunately, though, we don't even know if RSVP will suffice
> because we haven't captured what the user can do.
>
> Form follows function.  The function of this protocol should be to enable
> subscribers to utilize the guaranteed QoS capabilities of the network on
> demand.
>
>
> Keith Allen
> SBC Technology Resources
> 9505 Arboretum Blvd.
> Austin, TX 78759
> (512) 372-5741
> kallen@tri.sbc.com
>
>  -----Original Message-----
> From: 	dick.rr.knight@bt.com [mailto:dick.rr.knight@bt.com]
> Sent:	Monday, January 21, 2002 11:15 AM
> To:	Chen, Weijing; Georgios.Karagiannis@eln.ericsson.se
> Cc:	nsis@ietf.org
> Subject:	RE: [NSIS] Two kinds of requirements
>
> Weijing,
>
> I can understand your desire to concentrate on the user-network problem
> space.
>
> However - I am concerned that the result will be an agreed and working
> solution
> in this problem space that is then not supported at the network-network
> interface
> (interdomain in IP speak, NNI in PSTN jargon).
>
> If the user-network interface is one protocol and then the next hop is
> RSVP with intserv,
> then the next is MPLS with LSP and so on, will you see anything at the far
> and distant end
> that looks anything like the original user-network request?
>
> Dick
>
> -----Original Message-----
> From: Chen, Weijing [mailto:wchen@tri.sbc.com]
> Sent: 21 January 2002 16:20
> To: 'Georgios Karagiannis (ELN)'
> Cc: 'nsis@ietf.org'
> Subject: RE: [NSIS] Two kinds of requirements
>
>
> I am afraid that we are creating a Utopian solution here.
>
>>> Therefore, the [everyhop] component should be supported by the NSIS
> protocol.
>>> However a "host" or a "edge" should be able to activated or not.
>
> It is not question of who activate it. It is the question of who initiate
> it. Who is going to stuff the [everyhop] component into signaling message?
> Don't expect it from [end host].
>
>>> Furthermore, in my opinion the NSIS protocol should be:
>>> end host - end host: the NSIS protocol is terminated at end hosts;
>>> end host - proxy: the NSIS protocol is terminated at end host and proxy;
>
>>> end host - edge: the NSIS protocol is terminated at end end host and
>>> edge;
> This should be our focus now.
>
>>> edge - edge: the NSIS protocol is terminated at egdes of one/multiple
> domains;
>
> Yes, a universal protocol used by different segments is very nice. But can
> it be agreed on and implementable? The missing piece in today's protocol
> soup is user-to-network signaling, sort of DTMF in data world. Let's solve
> it first here in NSIS. Later on we can engage on a more ambition mission.
>
> --
> Weijing Chen
> SBC Technology Resources
> 9505 Arboretum Blvd.
> Austin, TX 78759
> 512 372 5710
> wchen@tri.sbc.com
>
> -----Original Message-----
> From: 	Georgios Karagiannis (ELN)
> [mailto:Georgios.Karagiannis@eln.ericsson.se]
> Sent:	Monday, January 21, 2002 4:30 AM
> To:	'dick.rr.knight@bt.com'
> Cc:	nsis@ietf.org
> Subject:	RE: [NSIS] Two kinds of requirements
>
>
> Hi Dick
>
> Please see my comment in line:
> [DK]>> I do agree that it need not be processed on a per hop basis as it
> can [DK]>> transverse a domain with a single QoS mechanism. That
> mechanism, be it
> [DK]>> diffserv or intserv, PNNI, RSVP, or even over-provisioning, takes
> care of
> [DK]>> the policing and the "path" establishment within the domain.
>
> Please note that at the moment there are scenarios that will need to
> process the [everyhop] component. Some of these scenarios are the Radio
> Access
> Network and Mobile IP,..
> Therefore, the [everyhop] component should be supported by the NSIS
> protocol.
> However a "host" or a "edge" should be able to activated or not.
>
> Furthermore, in my opinion the NSIS protocol should be:
> end host - end host: the NSIS protocol is terminated at end hosts;
> end host - proxy: the NSIS protocol is terminated at end host and proxy;
> end host - edge: the NSIS protocol is terminated at end end host and edge;
> edge - edge: the NSIS protocol is terminated at egdes of one/multiple
> domains;
>
>
> Best regards,
> Georgios
>
>
> -----Original Message-----
> From: Schneider, Marco [mailto:schneider@tri.sbc.com]
> Sent: 18 January 2002 20:10
> To: 'Roy, Radhika R, ALASO'; Gary Kenward; Loughney John (NRC/Helsinki);
> brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
> dick.rr.knight@bt.com
> Cc: nsis@ietf.org
> Subject: RE: [NSIS] Two kinds of requirements
>
>
> Hi Roy,
>
> Below is the original text from your reponse to Gary Kenward. Hopefully
> the context is clear.
>
> "[Roy, Radhika R, ALARC]  I would say that it is the QOS needs of the
> application (e.g., SIP-based VoIP) that the user likes to express (as
> opposed to "service"). Similarly, instead of network services, we would
> say network layer QOS services (e.g., RSVP, DiffServ, MPLS). We would
> develop the end-to-end (application layer) QOS signaling protocol (say,
> NSIS QOS). Now, there needs to have some kinds of standards how NSIS QOS
> will be mapped over RSVP, DiffServ, MPLS, etc."
>
> So by End-to-End you mean between directly between two "users". This is
> session level signaling and I don't believe the signaling part is within
> the scope of this working group. An application level QOS specification
> may be.
>
> After a session level agreement on QOS, the host/client/customer will need
> to signal an actual reservation request to the network for the necessary
> QOS agreed to at the session level. This is the protocol that we need to
> work on.
>
> This approach is discussed in the SIP draft "SIP Extensions for Media
> Authorization" (draft-ietf-sip-call-auth-03.txt) and the RAP draft
> "Framework for session set-up with media authorization"
> (draft-ietf-rap-session-auth-02.txt).
>
> Marco Schneider
>
> -----Original Message-----
> From: Roy, Radhika R, ALASO [mailto:rrroy@att.com]
> Sent: Friday, January 18, 2002 9:18 AM
> To: Schneider, Marco; Gary Kenward; Loughney John (NRC/Helsinki);
> brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
> dick.rr.knight@bt.com
> Cc: nsis@ietf.org
> Subject: RE: [NSIS] Two kinds of requirements
>
>
> Defined below [RRR]
>
> -----Original Message-----
> From: Schneider, Marco [mailto:schneider@tri.sbc.com]
> Sent: Thursday, January 17, 2002 8:47 PM
> To: Roy, Radhika R, ALASO; Gary Kenward; Loughney John (NRC/Helsinki);
> brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
> dick.rr.knight@bt.com
> Cc: nsis@ietf.org
> Subject: RE: [NSIS] Two kinds of requirements
>
>
> Hi Roy,
>
> Can you please define what you mean by "End-to-End Application Layer QOS
> Signaling". Thanks.
>
> [RRR] Suppose an user is initiation a SIP call to another user with audio,
> video, and data. The use needs to express the needs of QOS for audio,
> video, and data to another user.
>
> [RRR] The signaling mechanism that allows to express the QOS parameters of
> audio, video, and data is termed as the "End-to-End Application Layer QOS
> Signaling."
>
> Marco Schneider
>
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis
>
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis
>
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis
>
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis
>
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis
>
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis
>



--------------------------------------
Dr. Marcus Brunner
Network Laboratories
NEC Europe Ltd.

E-Mail: brunner@ccrle.nec.de
WWW:    http://www.ccrle.nec.de/
personal home page: http://www.brubers.org/marcus


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



From daemon@optimus.ietf.org  Fri Jan 25 11: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 LAA07030
	for <nsis-archive@odin.ietf.org>; Fri, 25 Jan 2002 11:47:25 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id LAA25947
	for nsis-archive@odin.ietf.org; Fri, 25 Jan 2002 11: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 LAA25265;
	Fri, 25 Jan 2002 11:38: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 LAA25228
	for <nsis@optimus.ietf.org>; Fri, 25 Jan 2002 11:38:12 -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 LAA06778
	for <nsis@ietf.org>; Fri, 25 Jan 2002 11:38:08 -0500 (EST)
Received: from citadel.mobility.ccrle.nec.de ([192.168.156.1])
	by yamato.ccrle.nec.de (8.11.6/8.10.1) with ESMTP id g0PGcGj13933;
	Fri, 25 Jan 2002 17:38:16 +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 EF4FCC05B; Fri, 25 Jan 2002 17:37:40 +0100 (CET)
Date: Fri, 25 Jan 2002 17:49:30 +0100
From: Marcus Brunner <brunner@ccrle.nec.de>
Reply-To: brunner@ccrle.nec.de
To: Elwyn Davies <elwynd@nortelnetworks.com>, "Nsis (E-mail)" <nsis@ietf.org>
Subject: Re: [NSIS] Tying the requests to the flows exploiting them
Message-ID: <26103885.1011980970@[192.168.102.79]>
In-Reply-To: <4103264BC8D3D51180B7002048400C450A9BFF@zhard0jd.europe.nortel.com>
References:  <4103264BC8D3D51180B7002048400C450A9BFF@zhard0jd.europe.nortel.c
 om>
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

Elwynd,

This is a very critical point, and we have been thinking about it for quite 
some time, but found no solution which is suitable (some or to expensive in 
terms of a overhead, others are only peodo secure :-). It is getting very 
important at the time a user pays for QoS (as you said).

I think it boils down to the problem, that an source IP address does not 
tell you something about the user sittin behind.

Marcus

--On Friday, January 18, 2002 5:45 PM +0000 Elwyn Davies 
<elwynd@nortelnetworks.com> wrote:

>
> Hi.
>
> Nsis is targeting the setup of QoS paths across multiple domains
> potentially belonging to several organisations that don't trust each
> other.  This has been reflected in the proposals for the internal
> operation of the protocol where extensive security requirements are
> proposed (Sec 5.8).  What appears to be missing are equivalently
> stringent means for ensuring that domains that authorise a QoS path can
> tell that the packets using that path are actually the ones that should
> be using it.
>
> In the simpler world of Intserv and Diffserv, requested QoS is invoked by
> simple pattern matching on some combination of the packet header fields,
> but even here thare has been a good deal of heart searching about how to
> ensure that only the right packets can exploit better treatment from a
> network (sub-text: only get what they paid for).  To do this properly
> seems to need two things:
>
> - The QoS protocol must be able to carry back to the end host making the
> request from each QoS domain, a seed for unforgeable tokens which can be
> attached to packets belonging to flow(s) which are to exploit the QoS
> path setup by the request.
>
> - The end host must be able to generate and attach suitable unforgeable
> tokens to each packet in a flow that should receive the requested
> treatment, which may then be tested by each QoS domain through which the
> packet passes.
>
> Regards,
> Elwyn
>
> -------------------------------------------------------------------------
> ---------
>
> Elwyn B Davies
>
>         Routing and Addressing Strategy Prime
>         Portfolio Integration                   Solutions Ready
>
>         Nortel Networks plc                     Email:
> elwynd@nortelnetworks.com          Harlow Laboratories
> ESN                     6-742-5498          London Road, Harlow,
> Direct Line             +44-1279-405498          Essex, CM17 9NA, UK
> Fax                     +44-1279-402047          Registered Office:
> Maidenhead Office Park, Westacott Way,          Company No. 3937799
> Maidenhead, Berkshire, SSL6 3QH
> -------------------------------------------------------------------------
> ---  This message may contain information proprietary to Nortel Networks
> plc so any  unauthorised disclosure, copying or distribution of its
> contents is strictly prohibited.
> -------------------------------------------------------------------------
> ---  "The Folly is mostly mine"
> and the opinions are mine and not those of my employer.
> =========================================================================
> =========
>
>
>



--------------------------------------
Dr. Marcus Brunner
Network Laboratories
NEC Europe Ltd.

E-Mail: brunner@ccrle.nec.de
WWW:    http://www.ccrle.nec.de/
personal home page: http://www.brubers.org/marcus



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



From daemon@optimus.ietf.org  Fri Jan 25 11:47: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 LAA07048
	for <nsis-archive@odin.ietf.org>; Fri, 25 Jan 2002 11:47:41 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id LAA25965
	for nsis-archive@odin.ietf.org; Fri, 25 Jan 2002 11:47: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 LAA25920;
	Fri, 25 Jan 2002 11:46: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 LAA25891
	for <nsis@optimus.ietf.org>; Fri, 25 Jan 2002 11:46: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 LAA06988
	for <nsis@ietf.org>; Fri, 25 Jan 2002 11:46: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 g0PGkNj13977;
	Fri, 25 Jan 2002 17:46: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 B8462C05B; Fri, 25 Jan 2002 17:45:43 +0100 (CET)
Date: Fri, 25 Jan 2002 17:57:33 +0100
From: Marcus Brunner <brunner@ccrle.nec.de>
Reply-To: brunner@ccrle.nec.de
To: "Georgios Karagiannis (ELN)" <Georgios.Karagiannis@eln.ericsson.se>
Cc: nsis@ietf.org
Subject: Independence of signalling and data path (was RE: [NSIS] Two kinds
 of requirements)
Message-ID: <26586659.1011981453@[192.168.102.79]>
In-Reply-To: <E244E44D6AB85E40AEEF7EAABE3545FA8233C4@enleent104.nl.eu.ericsson.se>
References:  <E244E44D6AB85E40AEEF7EAABE3545FA8233C4@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

I you want to see SIP in you can sure. But that was our intention.

I  personally think, that the signalling path should not be bound to the 
data path. Whether you need to know the location of the QoS controller 
heavility depends on the specific protocols defined (and might be regard 
implementation dependent)

Marcus


--On Friday, January 25, 2002 5:04 PM +0100 "Georgios Karagiannis (ELN)" 
<Georgios.Karagiannis@eln.ericsson.se> wrote:

> Hi Marcus
>
> yes, but from what I understood from your draft
> you assume that the QoS initiator will have to know the
> location of the QoS controller and that the
> signaling path may follow a different path than
> the user data. It seems SIP to me.
>
> Best Regards,
> Georgios
>
>
> -----Original Message-----
> From: Marcus Brunner [mailto:brunner@ccrle.nec.de]
> Sent: vrijdag 25 januari 2002 17:09
> To: Georgios Karagiannis (ELN); 'Schneider, Marco'
> Cc: nsis@ietf.org
> Subject: RE: [NSIS] Two kinds of requirements
>
>
> Looks nice for fixed network. However, as soon as mobility is involved it
> gets more difficult. That was the reason that in our framewrok we talk
> about QoS initiator and QoS controller, instead of teh componenets where
> the componenets are sitting (which we find not really relevant)
>
> Marcus
>
> --On Tuesday, January 22, 2002 10:39 AM +0100 "Georgios Karagiannis
> (ELN)"  <Georgios.Karagiannis@eln.ericsson.se> wrote:
>
>> Hi Marco
>>
>> The possible NSIS protocol components that can be
>> used on the different NSIS protocol types are the following:
>>
>>  * used components in "end host to end host" NSIS scenario:
>>       [everyhost], [everyedge], [everyhop]
>>
>>  * used components in "end host to proxy" NSIS scenario:
>>       [everyhost], [everyedge], [everyhop]
>>
>>  * used components in "end host to edge" NSIS scenario:
>>       [everyedge], [everyhop]
>>
>>  * used components in "edge to edge" NSIS scenario:
>>       [everyedge], [everyhop]
>>
>> Regarding the priority, we should decide it after the requirements,
>> architecture and framework drafts are done!
>>
>> Best regards,
>> Georgios
>>
>> -----Original Message-----
>> From: Schneider, Marco [mailto:schneider@tri.sbc.com]
>> Sent: dinsdag 22 januari 2002 1:03
>> To: 'Georgios Karagiannis (ELN)'; 'dick.rr.knight@bt.com'
>> Cc: nsis@ietf.org
>> Subject: RE: [NSIS] Two kinds of requirements
>>
>>
>> Hi Georgios, All
>>
>> If by x -- y you mean a protocol that runs directly between x and y (e.g.
>> end host -- end host, end host -- proxy...) then strictly speaking we are
>> discussing four  functionally distinct interfaces and thus four
>> functionally distinct protocols(possibly three if we group end host --
>> proxy and  end host -- edge together). In my opinion: First we need to
>> decide which of these interfaces are in scope. Second we need to decide
>> which one(s) we will address first. Third we need to define the
>> requirements for each for each of the interfaces independently.
>>
>> With respect to scope and priority, I think we need to address in order:
>> 1) end host -- edge/proxy
>> 2) domain edge -- domain edge
>>
>>
>> Marco
>>
>>
>> -----Original Message-----
>> From: Georgios Karagiannis (ELN)
>> [mailto:Georgios.Karagiannis@eln.ericsson.se]
>> Sent: Monday, January 21, 2002 4:30 AM
>> To: 'dick.rr.knight@bt.com'
>> Cc: nsis@ietf.org
>> Subject: RE: [NSIS] Two kinds of requirements
>>
>>
>>
>> Hi Dick
>>
>> Please see my comment in line:
>> [DK]>> I do agree that it need not be processed on a per hop basis as it
>> can [DK]>> transverse a domain with a single QoS mechanism. That
>> mechanism, be it
>> [DK]>> diffserv or intserv, PNNI, RSVP, or even over-provisioning, takes
>> care of
>> [DK]>> the policing and the "path" establishment within the domain.
>>
>> Please note that at the moment there are scenarios that will need to
>> process the [everyhop] component. Some of these scenarios are the Radio
>> Access
>> Network and Mobile IP,..
>> Therefore, the [everyhop] component should be supported by the NSIS
>> protocol.
>> However a "host" or a "edge" should be able to activated or not.
>>
>> Furthermore, in my opinion the NSIS protocol should be:
>> end host - end host: the NSIS protocol is terminated at end hosts;
>> end host - proxy: the NSIS protocol is terminated at end host and proxy;
>> end host - edge: the NSIS protocol is terminated at end end host and
>> edge; edge - edge: the NSIS protocol is terminated at egdes of
>> one/multiple domains;
>>
>>
>> Best regards,
>> Georgios
>>
>>
>> -----Original Message-----
>> From: Schneider, Marco [mailto:schneider@tri.sbc.com]
>> Sent: 18 January 2002 20:10
>> To: 'Roy, Radhika R, ALASO'; Gary Kenward; Loughney John (NRC/Helsinki);
>> brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
>> dick.rr.knight@bt.com
>> Cc: nsis@ietf.org
>> Subject: RE: [NSIS] Two kinds of requirements
>>
>>
>> Hi Roy,
>>
>> Below is the original text from your reponse to Gary Kenward. Hopefully
>> the context is clear.
>>
>> "[Roy, Radhika R, ALARC]  I would say that it is the QOS needs of the
>> application (e.g., SIP-based VoIP) that the user likes to express (as
>> opposed to "service"). Similarly, instead of network services, we would
>> say network layer QOS services (e.g., RSVP, DiffServ, MPLS). We would
>> develop the end-to-end (application layer) QOS signaling protocol (say,
>> NSIS QOS). Now, there needs to have some kinds of standards how NSIS QOS
>> will be mapped over RSVP, DiffServ, MPLS, etc."
>>
>> So by End-to-End you mean between directly between two "users". This is
>> session level signaling and I don't believe the signaling part is within
>> the scope of this working group. An application level QOS specification
>> may be.
>>
>> After a session level agreement on QOS, the host/client/customer will
>> need to signal an actual reservation request to the network for the
>> necessary QOS agreed to at the session level. This is the protocol that
>> we need to work on.
>>
>> This approach is discussed in the SIP draft "SIP Extensions for Media
>> Authorization" (draft-ietf-sip-call-auth-03.txt) and the RAP draft
>> "Framework for session set-up with media authorization"
>> (draft-ietf-rap-session-auth-02.txt).
>>
>> Marco Schneider
>>
>> -----Original Message-----
>> From: Roy, Radhika R, ALASO [mailto:rrroy@att.com]
>> Sent: Friday, January 18, 2002 9:18 AM
>> To: Schneider, Marco; Gary Kenward; Loughney John (NRC/Helsinki);
>> brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
>> dick.rr.knight@bt.com
>> Cc: nsis@ietf.org
>> Subject: RE: [NSIS] Two kinds of requirements
>>
>>
>> Defined below [RRR]
>>
>> -----Original Message-----
>> From: Schneider, Marco [mailto:schneider@tri.sbc.com]
>> Sent: Thursday, January 17, 2002 8:47 PM
>> To: Roy, Radhika R, ALASO; Gary Kenward; Loughney John (NRC/Helsinki);
>> brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
>> dick.rr.knight@bt.com
>> Cc: nsis@ietf.org
>> Subject: RE: [NSIS] Two kinds of requirements
>>
>>
>> Hi Roy,
>>
>> Can you please define what you mean by "End-to-End Application Layer QOS
>> Signaling". Thanks.
>>
>> [RRR] Suppose an user is initiation a SIP call to another user with
>> audio, video, and data. The use needs to express the needs of QOS for
>> audio, video, and data to another user.
>>
>> [RRR] The signaling mechanism that allows to express the QOS parameters
>> of audio, video, and data is termed as the "End-to-End Application Layer
>> QOS Signaling."
>>
>> Marco Schneider
>>
>> _______________________________________________
>> 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
>>
>
>
>
> --------------------------------------
> Dr. Marcus Brunner
> Network Laboratories
> NEC Europe Ltd.
>
> E-Mail: brunner@ccrle.nec.de
> WWW:    http://www.ccrle.nec.de/
> personal home page: http://www.brubers.org/marcus
>
>
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis
>



--------------------------------------
Dr. Marcus Brunner
Network Laboratories
NEC Europe Ltd.

E-Mail: brunner@ccrle.nec.de
WWW:    http://www.ccrle.nec.de/
personal home page: http://www.brubers.org/marcus



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



From daemon@optimus.ietf.org  Fri Jan 25 11:49: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 LAA07110
	for <nsis-archive@odin.ietf.org>; Fri, 25 Jan 2002 11:49:41 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id LAA26232
	for nsis-archive@odin.ietf.org; Fri, 25 Jan 2002 11:49: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 LAA26117;
	Fri, 25 Jan 2002 11:48: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 LAA26090
	for <nsis@optimus.ietf.org>; Fri, 25 Jan 2002 11:48:23 -0500 (EST)
Received: from cbibipnt03.HC.BT.COM (saturn.bt.com [193.113.57.20])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07090
	for <nsis@ietf.org>; Fri, 25 Jan 2002 11:48:18 -0500 (EST)
From: dick.rr.knight@bt.com
Received: by cbibipnt03.hc.bt.com with Internet Mail Service (5.5.2652.35)
	id <DQ1X3QK8>; Fri, 25 Jan 2002 16:44:45 -0000
Message-ID: <451D45016C2CD2119DA50000F8FE7F07080E5A8E@mlngcbnt01.hc.bt.com>
To: brunner@ccrle.nec.de, dick.rr.knight@bt.com, schneider@tri.sbc.com,
        Georgios.Karagiannis@eln.ericsson.se
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements  (priority on the boundary b
	e	tween a customer and the network)
Date: Fri, 25 Jan 2002 16:41:13 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
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

Whoops. Of course the network can satisfy the request using
overprovisioning, management set-up, etc.

The problem is that these methods are not dynamic. They usually apply to a
scenarios where there is more bandwidth than the users will ever need, which
is an oxymoron. Users needs expand to take up the bandwidth available (see
the greenhouse effect below). But what about negotiation and re-negotiation?
What about VPN crossing interdomain boundary - just contracts? (actually I
think contracts are just a method of the lawyers getting their hands on more
money!).

An amusing aside to illustrate the above point: The Greenhouse Effect.

I read a gardening magazine in which therre was a letter, almost
complaining, from someone who had bought a greenhouse (or glasshouse) a year
previously. The person had read in the same magazine an article about
"Choosing your greenhouse", and the article outlined  various ways of
deciding how much square area you would need in your new greenhouse. The
article then recommended that the prospective purchaser increase the square
area by 50%, as this exactly how much extra space will be needed one year
after purchase.
The letter writer was complaining that they followed ALL the advice and
bought a greenhouse 50% larger than their perceived needs. Now, one year
later, it was too small, and they wished they had bought one 50% bigger than
the purchased size.

So, however much you have, you can always fill it.

Happy weekend.

Dick 

-----Original Message-----
From: Marcus Brunner [mailto:brunner@ccrle.nec.de]
Sent: 25 January 2002 16:25
To: dick.rr.knight@bt.com; schneider@tri.sbc.com;
Georgios.Karagiannis@eln.ericsson.se
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements (priority on the boundary
be tween a customer and the network)


Dick,

There are other means for inter-domain setup. E.g., on a management 
interface, contacting for traffic trunks etc.

Marcus

--On Friday, January 18, 2002 11:12 AM +0000 dick.rr.knight@bt.com wrote:

>
> I do not agree.
>
> What is the point of completing the work enabling the customer to signal
> to the network, if the network cannot signal between domains? The network
> can never satisfy the request.
>
> Dick
>
> -----Original Message-----
> From: Schneider, Marco [mailto:schneider@tri.sbc.com]
> Sent: 18 January 2002 01:44
> To: 'Georgios Karagiannis (ELN)'; 'dick.rr.knight@bt.com'
> Cc: nsis@ietf.org
> Subject: RE: [NSIS] Two kinds of requirements
>
>
> Hi Georgios,
>
> While I agree NSIS could be used to support Interior to Interior (of one
> carrier) or Edge to Core, I think that we need to prioritize on a
> signaling protocol across the boundary between a customer and the
> network. Note that the customer could be an individual, an ISP or another
> Carrier.
>
> Marco Schneider
>
> -----Original Message-----
> From: Georgios Karagiannis (ELN)
> [mailto:Georgios.Karagiannis@eln.ericsson.se]
> Sent: Thursday, January 17, 2002 3:39 AM
> To: 'dick.rr.knight@bt.com'
> Cc: nsis@ietf.org
> Subject: RE: [NSIS] Two kinds of requirements
>
>
> Hi Dick
>
> In principle I agree with your comment (see below).
>
> [DK] >> To be more precise, I am suggesting a new protocol that is
> [DK] >> independent of the underlying transport technology and the QoS
> [DK] >> implemented and is also independent of the session control
> protocol.
>
>
> However, a very important point here is that we need to
> specify a protocol that can be used independent of the underlying
> transport  technology, but that can satisfy the QoS requirements imposed
> by these  underlying transport technologies. Otherwise the protocol will
> not be suitable
> and useful.
>
> A way of achieving this is by first creating a modular QoS signaling
> toolkit
>
> that will contain mandatory and optional QoS requirements;
> Second, specify how the protocol functionality should be separated in
> building blocks (protocol components) and define a minimum set
> of mandatory reservation options/features that should be
> processed by any network nodes, e.g., end-hosts,
> proxies, edges and interior nodes.
> An example of such a protocol decomposition is given below!
> In this way each node will only process (check and use) the protocol
> components of interest.
>
>
>| ---------|
>| ---------|
>| everyhost|<------------------------------------------------------->|ever
>| yho
> st|
>| ---------|
>| ---------|
>|         |                                                         |
>|
>| ---------|   |---------|                             |---------|
>| ---------|
>| everyedge|<->|everyedge|<--------------------------->|everyedge|<->|ever
>| yed
> ge|
>| ---------|   |---------|                             |---------|
>| ---------|
>|         |   |         |                             |         |   |
>|
>| ---------|   |---------|   |--------|   |--------|   |---------|
>| ---------|
>| everyhop |<->|everyhop |<->|everyhop|<->|everyhop|<->|everyhop
>| <->|everyhop |
>| ---------|   |---------|   |--------|   |--------|   |---------|
>| ---------|
>     host          edge        interior    interior       edge
> host
>
>
>   NSIS protocol decomposition (building blocks):
>  *  "everyhost", "everyedge" and "everyhop" are protocol components;
>  *  host: can be an end-host or a proxy and it can process and use the
> "everyhost",
>     "everyedge", and "everyhop" protocol components;
>
>  *  edge: can be a Diffserv edge, MPLS edge, etc., and it can process and
> use
>     the "everyedge", and "everyhop" protocol components. The "everyhost"
>     protocol component is not processed (used or checked);
>
>  *  interior: can be any router within a domain and it can process and
> use      only the "everyhop" protocol component.
>     The "everyhost" and "everyedge" protocol components are not
>     processed (used or checked);
>
>
> Best Regards,
> Georgios
>
> -----Original Message-----
> From: dick.rr.knight@bt.com [mailto:dick.rr.knight@bt.com]
> Sent: woensdag 16 januari 2002 13:00
> To: brian.williams@ericsson.com.au; lieve.bos@alcatel.be
> Cc: nsis@ietf.org
> Subject: RE: [NSIS] Two kinds of requirements
>
>
> I was waiting for some reaction to Brian's comments, but as there aren't
> any, here are my thoughts on the requirements:
>
> I agree with the analysis that discussion has been based around
> application-related signalling for QoS (at session level) and QoS
> signalling protocols used to actually provision the QoS at the transport
> level. Brian is right that there will never be an enhancement to a single
> session protocol that will satisfy all applications.
> However, for similar reasons, it is never going to be possible to
> prescribe a single QoS mechanism to be used in all networks. Existing
> networks (or domains) will not be changed overnight and new networks
> already face several workable mechanisms to deploy QoS.
>
> I think that what is needed is a new protocol that can signal the
> requirements of any session and can be satisfied by any QoS mechanism,
> existing or new.
> To be more precise, I am suggesting a new protocol that is independent of
> the underlying transport technology and the QoS implemented and is also
> independent of the session control protocol. Such a new protocol would be
> generic, optionally implemented by applications that would benefit from
> end-to-end QoS, and would be complimentary to the QoS mechanisms deployed
> (and of course other mechanisms, such as the routing).
>
> I think that this implies a more abstract definition of the QoS mechanism
> and may lend itself to the signalling of pre-defined QoS classes rather
> than parameters.
>
> Dick Knight
>
> -----Original Message-----
> From: Brian Williams [mailto:brian.williams@ericsson.com.au]
> Sent: 22 December 2001 23:57
> To: lieve.bos@alcatel.be
> Cc: nsis@ietf.org
> Subject: Re: [NSIS] Two kinds of requirements
>
>
> Hi.
> While the two types of signalling may be related, I think there is a
> need to develop a QoS bearer mechanism which is independent of any
> specific session signalling, and thus can be used for any application. I
> believe many of the applications which have identified requirements to
> the working group have their own specific session layer signalling (ie
> it is not end-to-end SIP).
>
> Having the session and transport protocols developed separately of
> course does not prohibit the two being used in conjunction for a
> specific application.
> /brian
>
> On Fri, 2001-12-21 at 22:24, lieve.bos@alcatel.be wrote:
>> Hello all,
>>
>> > From the discussion in Salt Lake city and the drafts submitted, one can
>> easily see that people are suggesting improvements to QoS signalling at
>> two totally different levels (some at session level and some at
>> transport level).
>>
>> First of all, there are drafts suggesting some improvements in the
>> session setup procedures (i.e. the ability to negotiate the preferred
>> QoS level between end users during SDP negotiation in SIP, so before the
>> actual resources are being setup). The QoS information negotiated at the
>> session layer determines the QoS level both endusers have to use for
>> their local access connection. This first kind of 'session level QoS
>> negotiation' happens end-to-end between the two end-users.
>>
>> Secondly, there are drafts suggesting that we need
>> improvements/alternatives for the QoS signalling protocols (e.g. RSVP)
>> used to actually provision the QoS at the transport level between two
>> endusers. This second kind of 'transport level QoS signalling' can
>> consist of several phases: end-to-edge and edge-to-edge.
>>
>> It's important that everybody realises that, in order to give endusers
>> true end-to-end Quality of Service, we need improvements for QoS both at
>> session and transport level. Also its important to understand that they
>> are not uncorrelated. Providers want to be able to control (e.g. via
>> policy control mechanisms) that the QoS requested at the transport level
>> is not exceeding the QoS negotiated/authorised previously at session
>> level. So, what about developing in NSIS a modular framework
>> incorporating both session and transport level QoS signalling with
>> possible hooks between the two layers (e.g. for policy enforcement).
>>
>> Lieve
>>
>> _______________________________________________
>> nsis mailing list
>> nsis@ietf.org
>> https://www1.ietf.org/mailman/listinfo/nsis
>
>
>
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis
>
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis
>
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis
>
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis
>



--------------------------------------
Dr. Marcus Brunner
Network Laboratories
NEC Europe Ltd.

E-Mail: brunner@ccrle.nec.de
WWW:    http://www.ccrle.nec.de/
personal home page: http://www.brubers.org/marcus


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



From daemon@optimus.ietf.org  Fri Jan 25 11:58: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 LAA07326
	for <nsis-archive@odin.ietf.org>; Fri, 25 Jan 2002 11:58:35 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id LAA26465
	for nsis-archive@odin.ietf.org; Fri, 25 Jan 2002 11:58: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 LAA26062;
	Fri, 25 Jan 2002 11: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 LAA25981
	for <nsis@optimus.ietf.org>; Fri, 25 Jan 2002 11:48:03 -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 LAA07084
	for <nsis@ietf.org>; Fri, 25 Jan 2002 11:47:59 -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 g0PGo9T23097;
	Fri, 25 Jan 2002 10:50:09 -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 g0PGlR805309;
	Fri, 25 Jan 2002 10:47:27 -0600 (CST)
Received: by TRIMAIL2.ad.tri.sbc.com with Internet Mail Service (5.5.2653.19)
	id <ZND3J2CV>; Fri, 25 Jan 2002 10:47:54 -0600
Message-ID: <905A1C4ABF353F4C8CC16FA9F53DD0D6322449@TRIMAIL2.ad.tri.sbc.com>
From: "Chen, Weijing" <wchen@tri.sbc.com>
To: "'Georgios Karagiannis (ELN)'" <Georgios.Karagiannis@eln.ericsson.se>,
        "Schneider, Marco" <schneider@tri.sbc.com>
Cc: NSIS Mailing List <nsis@ietf.org>
Subject: RE: [NSIS] Framework & requirements part of the "Two kinds of req
	 uirements" thread
Date: Fri, 25 Jan 2002 10:47:50 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: nsis-admin@ietf.org
Errors-To: nsis-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Next Steps in Signaling <nsis.ietf.org>
X-BeenThere: nsis@ietf.org


Georgios, etc:
>>* A "host" could be an end host or a proxy.  It can process
>>   and use the "everyhost", "everyedge", and "everyhop"
>>   protocol components
>> * An "edge" can be a Diffserv edge, MPLS edge, etc.  It can
>>   process and use the "everyedge", and "everyhop" protocol
>>   components. The "everyhost" protocol component is not
>>   processed (used or checked) but is carried onward.
>>
>> * An "interior within domain" can be any router within
>>   a domain.  It can process and use only the "everyhop"
>>   protocol component.  The "everyhost" and "everyedge"
>>   protocol components are not processed (used or checked)
>>   but are carried onward.


Weijing, etc:
* A "host" could be an end host or a proxy. It only assembles and
disassembles the "every host" component.
* A "edge" could be a Diffserv edge, MPLS edge, IP edge, ATM edge, etc. It
must process "every host" compnonent, preserve its original form, and carry
it onward. It must also assemble and disassemble "every hop" components
based on information from "every host" component (which could be called
"glueing" "every host" component to "every hop" component).
* A "hop" is always "interior within domain", It could be a router, a
switch, etc. It must disassemble, process, and re-assemble "every hop"
component. However, "every host" component are not processed but are carried
onward.

Do you agree to the above disagreement? If so, let's move forward and table
it as an onging issue.

--
Weijing Chen
SBC Technology Resources
9505 Arboretum Blvd.
Austin, TX 78759
512 372 5710
wchen@tri.sbc.com


-----Original Message-----
From: Georgios Karagiannis (ELN)
[mailto:Georgios.Karagiannis@eln.ericsson.se] 
Sent: Friday, January 25, 2002 7:11 AM
To: Chen, Weijing; Schneider, Marco
Cc: NSIS Mailing List
Subject: RE: [NSIS] Framework & requirements part of the "Two kinds of req
uirements" thread

Hi Weijing and Marco

I will just repeat some text from the proposed framework:

 * A "host" could be an end host or a proxy.  It can process
   and use the "everyhost", "everyedge", and "everyhop"
   protocol components
 * An "edge" can be a Diffserv edge, MPLS edge, etc.  It can
   process and use the "everyedge", and "everyhop" protocol
   components. The "everyhost" protocol component is not
   processed (used or checked) but is carried onward.

 * An "interior within domain" can be any router within
   a domain.  It can process and use only the "everyhop"
   protocol component.  The "everyhost" and "everyedge"
   protocol components are not processed (used or checked)
   but are carried onward.

Example _1: Suppose that a network provider is managing an overprovisioned 
network and is willing to provide to its end users applications that 
require end to end QoS support (e.g., telephony).
This provider may choose to use the (NSIS) protocol 
on an "end host to end host" basis. In this case 
the "host" will not use (activate) the "everyedge" 
and "everyhop" components, since they are not required.
Therefore, all edges and hops in the network will not process this 
type of NSIS protocol. Thus the NSIS message will only be processed 
by the end hosts. This is identical to the ("simple") example used
by Weijing.

Example_2: Now suppose that the network consists of overprovisioned 
access networks (managed by one provider) and by many concatenated 
QoS domains that are overprovisioned
but they are managed by different network providers.

Assume that the end user will like to use the "end host 
to end host" type of NSIS protocol for this purpose.
In this case the "host" will only activate the [everyedge] 
component, which will include 
QoS information that is needed by an edge of a domain. 
The [everyhop] component will not be activated, and therefore,
it will not be processed by any router located within the 
overprovisioned access network. Thus, the interior nodes 
located within the overprovisioned access network will not use 
the NSIS message.

The first edge node of a domain that will receive the NSIS message
will only use the [everyedge] information. Please note
that the edge node may change (replace) the [everyedge]
information.  If within this domain 
none existing QoS mechanism, e.g., Intserv/MPLS/overprovisioning,
are used, then the edge (of course this depends on the 
policy of the provider of the domain) will activate and include 
information into the [everyhop] component. Every hop within this 
domain will only use the [everyhop] component included in 
the NSIS message.

The same principles could be applied to all other domains 
wherein the NSIS message will pass through in its way to the 
receiving end host.

This example shows that by using the proposed framework
the NSIS protocol will be used (and checked) only (and only) by the 
nodes that need to use it. In this way the protocol can be 
processed fast and at the same time provide a reasonable level 
of QoS signaling functionality.


Best Regards,
Georgios






-----Original Message-----
From: Chen, Weijing [mailto:wchen@tri.sbc.com]
Sent: vrijdag 25 januari 2002 4:59
To: 'Georgios Karagiannis (ELN)'
Cc: NSIS Mailing List
Subject: RE: [NSIS] Framework & requirements part of the "Two kinds of
req uirements" thread


Georgios,

>>In principle I agree with you. The framework should not be used
>>to  define the NSIS requirements. The NSIS requirements should be
>>produced based on different QoS needs of certain application types.

Thank you.

>>No it is not required that the "host" has a global view 
>>of the domains. The way of how this NSIS protocol finds the edges
>>and the hops is similar with the way the RSVPv1 protocol does it.

So we still expose the network interior to host. Then what is the benefit of
this for host? Compare the following stacks that the host has to handle:

|-----|
|ehost|
|-----|
|     |
|-----|
|eedge|
|-----|
|     |
|-----|
|ehop |
|-----|
 host    

vs.

|-----|
|ehost|
|-----|
 host                

Cleary the latter one is much simpler.

Now let's take a look what is the typical sequence of end-to-end QoS service
delivery chain:

[src ehost]->hello, edge, I want so and so [original QoS] to so and so
place.
[incoming eedge]->ok, host, just a millisecond.
       [background] glueing the [original QoS] to [ehop QoS] in first
[ehop], 
                    [ehop] passes [ehop QoS] and [original QoS] to next
                    [ehop], on and on to outgoing [eedge].
[outgoing eedge]->hello, ehost, here is [original QoS] request from
                  [src ehost], will you take it?
[dest ehost]->ok, accept.
[outgoing eedge]-->[ehop]-->[incoming eedge]...
[incoming eedge]->host, you are ready to go.
[src ehost]->ok...

In the above sequence, [ehost] only deals with [eedge] directly, not [ehop].
So why do we want to force [ehop] information (i.e. network internal
information) to [ehost]? If we are doing so, [ehost] would say "Ooo, I am
stuffed, choked, ok, I am giving up. I don't want QoS." Which is exactly
where we are today.

So please don't stuff the poor [ehost] with anything else except he
absoultly need for [ehost] to [eedge] request and response. Thank you very
much.

--
Weijing Chen
SBC Technology Resources
9505 Arboretum Blvd.
Austin, TX 78759
512 372 5710
wchen@tri.sbc.com


-----Original Message-----
From: Georgios Karagiannis (ELN)
[mailto:Georgios.Karagiannis@eln.ericsson.se] 
Sent: Thursday, January 24, 2002 3:33 AM
To: Chen, Weijing
Cc: NSIS Mailing List
Subject: RE: [NSIS] Framework & requirements part of the "Two kinds of req
uirements" thread

Hi Weijing

Please see my comments in line.

[WC]>> 1. David's proposal of working requirement within so 
[WC]>> called "framework" is putting the cart before the horse. 
[WC]>> Because we think one framework is cool,
[WC]>> we confine our requirements and use cases within 
[WC]>> that framework. It is totally unacceptable.

In principle I agree with you. The framework should not be used
to  define the NSIS requirements. The NSIS requirements should be
produced based on different QoS needs of certain application types.
However, the mentioned framework can be used to decompose a 
complex QoS problem into certain simpler QoS problems.

[WC]>> 2. Figure
[WC]>>  In above picture, [host] has to assemble and process 
[WC]>>  the [ehop], [eedge] in addition to [ehost] part. How will 
[WC]>>  the [host] correctly assemble and process
[WC]>> the [ehop] and [eedge] pieces? It implies that [host] has 
[WC]>> global view of [ehop] and [eedge] in every domains. 
[WC]>> to happen, there must be another protocol to exchange network 
[WC]>> information and pass whole network view
[WC]>> to [host]. 

No it is not required that the "host" has a global view 
of the domains. The way of how this NSIS protocol finds the edges
and the hops is similar with the way the RSVPv1 protocol does it.

[WC] >> Now what about "glue"? Shall NSIS do it? Part of me 
[WC] >> says yes, another says
[WC] >> no. I am 50/50.

Please note that the NSIS charter mentions that a "framework" 
draft should be specified by March 2002.

Best regards,
Georgios


-----Original Message-----
From: Chen, Weijing [mailto:wchen@tri.sbc.com]
Sent: donderdag 24 januari 2002 9:43
To: David.Partain@ericsson.com
Cc: NSIS Mailing List
Subject: RE: [NSIS] Framework & requirements part of the "Two kinds of
req uirements" thread



I have fundamental disagreement with David's point.

1. David's proposal of working requirement within so called "framework" is
putting the cart before the horse. Because we think one framework is cool,
we confine our requirements and use cases within that framework. It is
totally unacceptable.

2. 

|-----|                                                  |-----|
|ehost|<------------------------------------------------>|ehost|
|-----|                                                  |-----|
|     |                                                  |     |
|-----|            |-----|            |-----|            |-----|
|eedge|<---------->|eedge|<---------->|eedge|<---------->|eedge|
|-----|            |-----|            |-----|            |-----|
|     |            |     |            |     |            |     |
|-----|   |----|   |-----|   |----|   |-----|   |----|   |-----|
|ehop |<->|ehop|<->|ehop |<->|ehop|<->|ehop |<->|ehop|<->|ehop |
|-----|   |----|   |-----|   |----|   |-----|   |----|   |-----|
 host    interior   edge    interior   edge     interior  host
         w/in domain       w/in domain        w/in domain

In above picture, [host] has to assemble and process the [ehop], [eedge] in
addition to [ehost] part. How will the [host] correctly assemble and process
the [ehop] and [eedge] pieces? It implies that [host] has global view of
[ehop] and [eedge] in every domains. For this to happen, there must be
another protocol to exchange network information and pass whole network view
to [host]. So on, and so on, and sooner we know that we revive an ultimate
engineer dream: a protocol for all and do all. Be there, done that, and
failed. Otherwise we wouldn't be here to debate about what NSIS should be.

The right picture should be (if you insist talking about the framework
before requirement):

                   |-----|   |----|   |-----|  
                   |ehop |<->|ehop|<->|ehop |   
                   |-----|   |----|   |-----| 
                   |     |            |     |
                   |-----|            |-----|
                   |glue |            |glue |
                   |-----|            |-----|
                   |     |            |     |
|-----|            |-----|            |-----|            |-----|
|ehost|<---------->|ehost|<---------->|ehost|<---------->|ehost|
|-----|            |-----|            |-----|            |-----|
 host                edge     hop      edge                host
           domain            domains             domain
                             (inter and
                              intra)
           NSIS                                   NSIS

Now what about "glue"? Shall NSIS do it? Part of me says yes, another says
no. I am 50/50.

--
Weijing Chen
SBC Technology Resources
9505 Arboretum Blvd.
Austin, TX 78759
512 372 5710
wchen@tri.sbc.com



-----Original Message-----
From: David Partain [mailto:David.Partain@ericsson.com] 
Sent: Wednesday, January 23, 2002 3:58 AM
To: NSIS Mailing List
Subject: [NSIS] Framework & requirements part of the "Two kinds of
requirements" thread

Greetings all,

I'd like to offer my take on part of the thread "Two kinds
of requirements" to see if we can collectively reach any sort
of conclusion based on what's been written.  I doubt I'll say
anything new, but perhaps it'll help summarize a bit.

To cut to the chase, the conclusion of this mail is that
I think:

 - we should use the "framework" below as the starting point of
   framework discussions
 - the requirements should grow from use cases of particular
   applications that will use the network

The original mail postulated that people are wanting to work
on two kinds of requirements here:

 - end-host to end-host, or application to application
   signalling

 - transport level signalling

From that point, there has been a hearty debate about whether
this indeed is true, as well as a host of other issues.

I think the following points have been made, amongst others:

 - It should support the use of throughput adaptive applications
   and the ability for a traffic flow to express its QoS
   preferences with regard to the throughput values which it
   may be allocated.

 - One part of the thread was about whether RSVP and related
   work (e.g., RFC 2998), or perhaps SDPng, are suitable
   solutions.  While it's obvious that we need to learn from
   and perhaps start from one of these efforts in working on
   NSIS, it also seems clear that we shouldn't start working
   on that until the requirements are done.

 - There's no chance we'll create a single one-size-fits-all
   application-related signalling protocol that will be used
   by everyone.  That seems very clear.

 - There's a need for something transport independent that can
   help signal QoS needs across multiple domains in order
   to help the application-related signalling protocols do
   their thing.

The big issue there is what part of this we should solve here.
Should we concentrate specifically on the application/host
to network signalling?  I think not and others have agreed.
Should we try to design something that goes end to end?  If we
do that, do we have a "chicken and egg" problem of needing to
have the technology everywhere for things to work?

A case has been made that the goal should be to create a
signalling protocol that has different kinds of components
appropriate to different parts of the problem.  Georgios K.
proposed the following figure, which I like quite a lot and
which others have said is good, as a way of looking at it:

|-----|                                                  |-----|
|ehost|<------------------------------------------------>|ehost|
|-----|                                                  |-----|
|     |                                                  |     |
|-----|            |-----|            |-----|            |-----|
|eedge|<---------->|eedge|<---------->|eedge|<---------->|eedge|
|-----|            |-----|            |-----|            |-----|
|     |            |     |            |     |            |     |
|-----|   |----|   |-----|   |----|   |-----|   |----|   |-----|
|ehop |<->|ehop|<->|ehop |<->|ehop|<->|ehop |<->|ehop|<->|ehop |
|-----|   |----|   |-----|   |----|   |-----|   |----|   |-----|
 host    interior   edge    interior   edge     interior  host
         w/in domain       w/in domain        w/in domain

   ehost = everyhost
   eedge = everyedge
   ehop  = everyhop

NSIS protocol decomposition:

 * A "host" could be an end host or a proxy.  It can process
   and use the "everyhost", "everyedge", and "everyhop"
   protocol components.

 * An "edge" can be a Diffserv edge, MPLS edge, etc.  It can
   process and use the "everyedge", and "everyhop" protocol
   components. The "everyhost" protocol component is not
   processed (used or checked) but is carried onward.

 * An "interior within domain" can be any router within
   a domain.  It can process and use only the "everyhop"
   protocol component.  The "everyhost" and "everyedge"
   protocol components are not processed (used or checked)
   but are carried onward.

The everyhop bit within a domain provides signalling facilities
for that particular domain and is very likely to differ from
the everyhop bit used in the next boarding domain.

The point of all of this is to get a concatenation of results.
Each domain is responsible for taking its own decisions in its
own domain-specific ways.  The concatenation of the everyhop
decisions within a domain provides the domain's answer.
The concatenation of the domains' results gives and end to
end answer that can be used by the everyhost bit.

I think that having this overall framework -- for lack of a
better term -- in mind is very helpful.

If we can agree that this is a reasonable framework to use as
the basis of discussion, I think that what we need to do is
to produce a set of requirements for different "applications"
that will use these networks/this framework.  Indeed, I believe
this matches Keith Allen's request that requirements be based on
use cases.  If we know we're going to use the NSIS protocol on
a cellular wireless network (just to pull an example out of the
air :-)), then that "use case" implies a set of requirements.
A different scenario (e.g., the core of the network) implies
another set of requirements.

I personally think this is the right way forward and would
like to see this group move in this direction.

Georgios added some more thoughts on this topic
which addressed the applicability and prioritization
of work.  That can be found in the archive at
http://www1.ietf.org/mail-archive/working-groups/nsis/current/msg00418.html

I realize that I haven't covered everyone's particular topic
in this thread, but perhaps it'll help focus on one part of
the discussion.  If someone wants to summarize some other
sub-thread, that would be great...

Cheers,

dlp

ps. I think it would be very useful if Subject lines could more
accurately reflect the topic covered in the mail.  Long threads
with the same subject and covering a multitude of topics is
difficult to follow...

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

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

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

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



From daemon@optimus.ietf.org  Fri Jan 25 11:59: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 LAA07371
	for <nsis-archive@odin.ietf.org>; Fri, 25 Jan 2002 11:59:14 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id LAA26526
	for nsis-archive@odin.ietf.org; Fri, 25 Jan 2002 11:59: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 LAA26219;
	Fri, 25 Jan 2002 11:49: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 LAA26184
	for <nsis@optimus.ietf.org>; Fri, 25 Jan 2002 11:49: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 LAA07099
	for <nsis@ietf.org>; Fri, 25 Jan 2002 11:49:16 -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 g0PGnNj13989;
	Fri, 25 Jan 2002 17:49: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 2DEE8C05B; Fri, 25 Jan 2002 17:48:48 +0100 (CET)
Date: Fri, 25 Jan 2002 18:00:38 +0100
From: Marcus Brunner <brunner@ccrle.nec.de>
Reply-To: brunner@ccrle.nec.de
To: "Allen, Keith" <kallen@tri.sbc.com>, nsis@ietf.org
Subject: Use cases (RE: [NSIS] Two kinds of requirements)
Message-ID: <26771134.1011981638@[192.168.102.79]>
In-Reply-To: <905A1C4ABF353F4C8CC16FA9F53DD0D62A701E@TRIMAIL2.ad.tri.sbc.com>
References:  <905A1C4ABF353F4C8CC16FA9F53DD0D62A701E@TRIMAIL2.ad.tri.sbc.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

Keith, see inline

--On Friday, January 25, 2002 10:12 AM -0600 "Allen, Keith" 
<kallen@tri.sbc.com> wrote:
[...]
> Marcus,
>
> Use Cases are a technique used to gather and document requirements.  Using
> this technique, the requirements for a system are documented as a set of
> use cases which describe the ways in which all the different users of a
> system use it.  The four examples you give above would be good places to
> start. They would need to be fleshed out quite a bit, with discussion
> about what happens when the user's goal cannot be accomplished, etc.
>

Sure as you said it was ment to be a starting point.

[...]

> Simply listing all the different actors that will use the protocol, and
> the ways in which they are going to use it would begin to define the
> scope of the protocol.  The hard part, then, comes in fleshing out all
> those use cases with accurate and precise statements about what the
> interface does.
>

And what the interface MUST do (or what use case is supported and which one 
not.

Mrcus

>
> Keith Allen
> SBC Technology Resources
> 9505 Arboretum Blvd.
> Austin, TX 78759
> (512) 372-5741
> kallen@tri.sbc.com
>
>  -----Original Message-----
> From: 	Marcus Brunner [mailto:brunner@ccrle.nec.de]
> Sent:	Friday, January 25, 2002 10:02 AM
> To:	Allen, Keith; nsis@ietf.org
> Subject:	RE: [NSIS] Two kinds of requirements
>
> --On Monday, January 21, 2002 1:07 PM -0600 "Allen, Keith"
> <kallen@tri.sbc.com> wrote:
>
>> All,
>>
>> Along the lines of my earlier reference to Use Cases, what do you think
>> about beginning to document the requirements the protocol should meet as
>> a set of use cases describing how network users (or actually their
>> network devices) use the protocol-to-be to access the QoS capabilities
>> of the network.  For example, one use case could show a voice over IP
>> caller, another a network administrator setting up an Ethernet VPN, etc.
>> If the protocol has to support mobile handoffs, we would have a use case
>> showing that.  It would give us a focal point instead of just e-mail.
>>
>>
>> Keith Allen
>> SBC Technology Resources
>> 9505 Arboretum Blvd.
>> Austin, TX 78759
>> (512) 372-5741
>> kallen@tri.sbc.com
>>
>>  -----Original Message-----
>> From: 	Allen, Keith
>> Sent:	Monday, January 21, 2002 11:37 AM
>> To:	nsis@ietf.org
>> Subject:	RE: [NSIS] Two kinds of requirements
>>
>> Should the design of the protocol be driven by the needs of the user or
>> the currently implemented network?  If we choose the latter we will end
>> up with a protocol that will be obsolete when the next new network
>> innovation takes place, and it may not meet the basic needs of the
>> subscriber.
>>
>> The Object-Oriented software world has turned to user-centric
>> requirements (in the form of Use Cases) as the basis for analysis and
>> design.  They are getting good results with this process.  We should
>> also focus on what the user wants to do.  The user sends a request to
>> the network, then he doesn't care what the network has to do to meet it.
>> If it turns out that RSVP can't meet the needs of the subscriber it will
>> have to evolve or be replaced. Unfortunately, though, we don't even know
>> if RSVP will suffice because we haven't captured what the user can do.
>>
>> Form follows function.  The function of this protocol should be to enable
>> subscribers to utilize the guaranteed QoS capabilities of the network on
>> demand.
>>
>>
>> Keith Allen
>> SBC Technology Resources
>> 9505 Arboretum Blvd.
>> Austin, TX 78759
>> (512) 372-5741
>> kallen@tri.sbc.com
>>
>>  -----Original Message-----
>> From: 	dick.rr.knight@bt.com [mailto:dick.rr.knight@bt.com]
>> Sent:	Monday, January 21, 2002 11:15 AM
>> To:	Chen, Weijing; Georgios.Karagiannis@eln.ericsson.se
>> Cc:	nsis@ietf.org
>> Subject:	RE: [NSIS] Two kinds of requirements
>>
>> Weijing,
>>
>> I can understand your desire to concentrate on the user-network problem
>> space.
>>
>> However - I am concerned that the result will be an agreed and working
>> solution
>> in this problem space that is then not supported at the network-network
>> interface
>> (interdomain in IP speak, NNI in PSTN jargon).
>>
>> If the user-network interface is one protocol and then the next hop is
>> RSVP with intserv,
>> then the next is MPLS with LSP and so on, will you see anything at the
>> far and distant end
>> that looks anything like the original user-network request?
>>
>> Dick
>>
>> -----Original Message-----
>> From: Chen, Weijing [mailto:wchen@tri.sbc.com]
>> Sent: 21 January 2002 16:20
>> To: 'Georgios Karagiannis (ELN)'
>> Cc: 'nsis@ietf.org'
>> Subject: RE: [NSIS] Two kinds of requirements
>>
>>
>> I am afraid that we are creating a Utopian solution here.
>>
>>>> Therefore, the [everyhop] component should be supported by the NSIS
>> protocol.
>>>> However a "host" or a "edge" should be able to activated or not.
>>
>> It is not question of who activate it. It is the question of who initiate
>> it. Who is going to stuff the [everyhop] component into signaling
>> message? Don't expect it from [end host].
>>
>>>> Furthermore, in my opinion the NSIS protocol should be:
>>>> end host - end host: the NSIS protocol is terminated at end hosts;
>>>> end host - proxy: the NSIS protocol is terminated at end host and
>>>> proxy;
>>
>>>> end host - edge: the NSIS protocol is terminated at end end host and
>>>> edge;
>> This should be our focus now.
>>
>>>> edge - edge: the NSIS protocol is terminated at egdes of one/multiple
>> domains;
>>
>> Yes, a universal protocol used by different segments is very nice. But
>> can it be agreed on and implementable? The missing piece in today's
>> protocol soup is user-to-network signaling, sort of DTMF in data world.
>> Let's solve it first here in NSIS. Later on we can engage on a more
>> ambition mission.
>>
>> --
>> Weijing Chen
>> SBC Technology Resources
>> 9505 Arboretum Blvd.
>> Austin, TX 78759
>> 512 372 5710
>> wchen@tri.sbc.com
>>
>> -----Original Message-----
>> From: 	Georgios Karagiannis (ELN)
>> [mailto:Georgios.Karagiannis@eln.ericsson.se]
>> Sent:	Monday, January 21, 2002 4:30 AM
>> To:	'dick.rr.knight@bt.com'
>> Cc:	nsis@ietf.org
>> Subject:	RE: [NSIS] Two kinds of requirements
>>
>>
>> Hi Dick
>>
>> Please see my comment in line:
>> [DK]>> I do agree that it need not be processed on a per hop basis as it
>> can [DK]>> transverse a domain with a single QoS mechanism. That
>> mechanism, be it
>> [DK]>> diffserv or intserv, PNNI, RSVP, or even over-provisioning, takes
>> care of
>> [DK]>> the policing and the "path" establishment within the domain.
>>
>> Please note that at the moment there are scenarios that will need to
>> process the [everyhop] component. Some of these scenarios are the Radio
>> Access
>> Network and Mobile IP,..
>> Therefore, the [everyhop] component should be supported by the NSIS
>> protocol.
>> However a "host" or a "edge" should be able to activated or not.
>>
>> Furthermore, in my opinion the NSIS protocol should be:
>> end host - end host: the NSIS protocol is terminated at end hosts;
>> end host - proxy: the NSIS protocol is terminated at end host and proxy;
>> end host - edge: the NSIS protocol is terminated at end end host and
>> edge; edge - edge: the NSIS protocol is terminated at egdes of
>> one/multiple domains;
>>
>>
>> Best regards,
>> Georgios
>>
>>
>> -----Original Message-----
>> From: Schneider, Marco [mailto:schneider@tri.sbc.com]
>> Sent: 18 January 2002 20:10
>> To: 'Roy, Radhika R, ALASO'; Gary Kenward; Loughney John (NRC/Helsinki);
>> brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
>> dick.rr.knight@bt.com
>> Cc: nsis@ietf.org
>> Subject: RE: [NSIS] Two kinds of requirements
>>
>>
>> Hi Roy,
>>
>> Below is the original text from your reponse to Gary Kenward. Hopefully
>> the context is clear.
>>
>> "[Roy, Radhika R, ALARC]  I would say that it is the QOS needs of the
>> application (e.g., SIP-based VoIP) that the user likes to express (as
>> opposed to "service"). Similarly, instead of network services, we would
>> say network layer QOS services (e.g., RSVP, DiffServ, MPLS). We would
>> develop the end-to-end (application layer) QOS signaling protocol (say,
>> NSIS QOS). Now, there needs to have some kinds of standards how NSIS QOS
>> will be mapped over RSVP, DiffServ, MPLS, etc."
>>
>> So by End-to-End you mean between directly between two "users". This is
>> session level signaling and I don't believe the signaling part is within
>> the scope of this working group. An application level QOS specification
>> may be.
>>
>> After a session level agreement on QOS, the host/client/customer will
>> need to signal an actual reservation request to the network for the
>> necessary QOS agreed to at the session level. This is the protocol that
>> we need to work on.
>>
>> This approach is discussed in the SIP draft "SIP Extensions for Media
>> Authorization" (draft-ietf-sip-call-auth-03.txt) and the RAP draft
>> "Framework for session set-up with media authorization"
>> (draft-ietf-rap-session-auth-02.txt).
>>
>> Marco Schneider
>>
>> -----Original Message-----
>> From: Roy, Radhika R, ALASO [mailto:rrroy@att.com]
>> Sent: Friday, January 18, 2002 9:18 AM
>> To: Schneider, Marco; Gary Kenward; Loughney John (NRC/Helsinki);
>> brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
>> dick.rr.knight@bt.com
>> Cc: nsis@ietf.org
>> Subject: RE: [NSIS] Two kinds of requirements
>>
>>
>> Defined below [RRR]
>>
>> -----Original Message-----
>> From: Schneider, Marco [mailto:schneider@tri.sbc.com]
>> Sent: Thursday, January 17, 2002 8:47 PM
>> To: Roy, Radhika R, ALASO; Gary Kenward; Loughney John (NRC/Helsinki);
>> brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
>> dick.rr.knight@bt.com
>> Cc: nsis@ietf.org
>> Subject: RE: [NSIS] Two kinds of requirements
>>
>>
>> Hi Roy,
>>
>> Can you please define what you mean by "End-to-End Application Layer QOS
>> Signaling". Thanks.
>>
>> [RRR] Suppose an user is initiation a SIP call to another user with
>> audio, video, and data. The use needs to express the needs of QOS for
>> audio, video, and data to another user.
>>
>> [RRR] The signaling mechanism that allows to express the QOS parameters
>> of audio, video, and data is termed as the "End-to-End Application Layer
>> QOS Signaling."
>>
>> Marco Schneider
>>
>> _______________________________________________
>> nsis mailing list
>> nsis@ietf.org
>> https://www1.ietf.org/mailman/listinfo/nsis
>>
>> _______________________________________________
>> nsis mailing list
>> nsis@ietf.org
>> https://www1.ietf.org/mailman/listinfo/nsis
>>
>> _______________________________________________
>> nsis mailing list
>> nsis@ietf.org
>> https://www1.ietf.org/mailman/listinfo/nsis
>>
>> _______________________________________________
>> nsis mailing list
>> nsis@ietf.org
>> https://www1.ietf.org/mailman/listinfo/nsis
>>
>> _______________________________________________
>> nsis mailing list
>> nsis@ietf.org
>> https://www1.ietf.org/mailman/listinfo/nsis
>>
>> _______________________________________________
>> nsis mailing list
>> nsis@ietf.org
>> https://www1.ietf.org/mailman/listinfo/nsis
>>
>
>
>
> --------------------------------------
> Dr. Marcus Brunner
> Network Laboratories
> NEC Europe Ltd.
>
> E-Mail: brunner@ccrle.nec.de
> WWW:    http://www.ccrle.nec.de/
> personal home page: http://www.brubers.org/marcus
>
>
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis
>



--------------------------------------
Dr. Marcus Brunner
Network Laboratories
NEC Europe Ltd.

E-Mail: brunner@ccrle.nec.de
WWW:    http://www.ccrle.nec.de/
personal home page: http://www.brubers.org/marcus



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



From daemon@optimus.ietf.org  Fri Jan 25 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 MAA07911
	for <nsis-archive@odin.ietf.org>; Fri, 25 Jan 2002 12:13:39 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id MAA28191
	for nsis-archive@odin.ietf.org; Fri, 25 Jan 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 MAA27780;
	Fri, 25 Jan 2002 12:04: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 MAA27750
	for <nsis@optimus.ietf.org>; Fri, 25 Jan 2002 12:04:08 -0500 (EST)
Received: from newish7.ericsson.com.au (newish7.ericsson.com.au [203.61.155.116])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07610
	for <nsis@ietf.org>; Fri, 25 Jan 2002 12:04:02 -0500 (EST)
Received: from brsf10.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10])
	by newish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id EAA22612;
	Sat, 26 Jan 2002 04:02:41 +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 EAA18548;
	Sat, 26 Jan 2002 04:04:01 +1100 (EST)
Received: from localhost.localdomain (MINDY [147.214.68.87]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id XRFZQCCX; Sat, 26 Jan 2002 04:04:00 +1100
Subject: RE: [NSIS] Two kinds of requirements
From: Brian Williams <brian.williams@ericsson.com.au>
To: john loughney <john.loughney@nokia.com>
Cc: nsis@ietf.org
In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEF5D94A5@esebe004.NOE.Nokia.com>
References: <0C1353ABB1DEB74DB067ADFF749C4EEF5D94A5@esebe004.NOE.Nokia.com>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Mailer: Evolution/1.0.1 
Date: 26 Jan 2002 03:59:35 +1100
Message-Id: <1011977979.1917.96.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 John.
On Sat, 2002-01-26 at 01:46, john.loughney@nokia.com wrote:
> Brian,
> 
> > My concern is that there must be sufficient information of some type to
> > allow the derivation of what is required for the layer 2. However, the
> > typical set of parameters currently in Intserv is not sufficient to
> > allow a spectrum efficient bearer, and more information is needed.
> 
> I'd be very interested in know what kind of parameters you mean.
> Is there a reason why the layer 2 technology cannot handle the
> specifics for setting up of layer 2?  Are applications sitting over
> layer 3 so demanding / fussy that the need very precise details?
A layer 2 management entity (at either end of the L2 connection) would
be responsible for establishing the layer 2 connection using the layer 2
specific protocol. If you look at UMTS, this protocol has a large number
of parameters; the aim of which is to allow spectrum efficiency which is
_the_key_concern_ for cellular. So, it is not the layer 3 that is
demanding, it is the need to make the most of the spectrum (read as best
QoS possible for lowest possible cost).

The layer 2 can trade off some characteristics against others:
eg.- to get a lower delay, you may accept a higher bit error rate
- in some cases you want the radio link to build in more error
correction (possible increase in delay, but much better characteristics
than end-to-end error recovery). In other cases you want to have packets
delivered even with errors to get lowest delay (eg a speech application
can be tolerant to errors in codec bits).

There are many of these that need to be set. If you only provide the
typical parameters from layer 3 (eg. traffic rate, delay) then the layer
2 management function cannot identify the optimal (ie cheapest that best
meets your needs) bearer. That is because fixed networks typically
assume error rates are low enough to be ignored, and it is _only_
bandwidth, delay and congestion loss that determine QoS. For cellular,
we believe there are more factors that affect QoS, and there are more
details. 

We have two drafts which 
1) identify the problem
http://search.ietf.org/internet-drafts/draft-fodor-intserv-wireless-issues-00.txt
and
2) give an indication of the parameters we are considering 
http://search.ietf.org/internet-drafts/draft-fodor-intserv-wireless-params-00.txt
 
These drafts look at Intserv, and are not tailored to NSIS though. We
are currently working on a new draft discussing the cellular network
problem focused more towards NSIS.
/brian

> My feeling is that we should generalize the layer 3 needs, and
> that layer 2 (or the service provider) can interpret them to
> its needs.  
> 
> John



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



From daemon@ns.ietf.org  Fri Jan 25 13:42: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 NAA10656
	for <nsis-archive@odin.ietf.org>; Fri, 25 Jan 2002 13:42:13 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id NAA02400
	for nsis-archive@odin.ietf.org; Fri, 25 Jan 2002 13:42: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 NAA02278;
	Fri, 25 Jan 2002 13:40: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 NAA02247
	for <nsis@optimus.ietf.org>; Fri, 25 Jan 2002 13:40:16 -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 NAA10567
	for <nsis@ietf.org>; Fri, 25 Jan 2002 13:40:13 -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.34)
	  id 16UBGE-0000eQ-00; Fri, 25 Jan 2002 19:39:38 +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 g0PIdba20825;
	Fri, 25 Jan 2002 19:39:37 +0100
Message-ID: <3C51A669.7177F0B6@ee.tu-berlin.de>
Date: Fri, 25 Jan 2002 19:39:37 +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: brunner@ccrle.nec.de
CC: "Georgios Karagiannis (ELN)" <Georgios.Karagiannis@eln.ericsson.se>,
        nsis@ietf.org
Subject: Re: Independence of signalling and data path (was RE: [NSIS] Two kindsof 
 requirements)
References: <E244E44D6AB85E40AEEF7EAABE3545FA8233C4@enleent104.nl.eu.ericsso
	 n.se> <26586659.1011981453@[192.168.102.79]>
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

Marcus,

Marcus Brunner wrote:
> 
> I you want to see SIP in you can sure. But that was our intention.
> 
> I  personally think, that the signalling path should not be bound to the
> data path. Whether you need to know the location of the QoS controller
> heavility depends on the specific protocols defined (and might be regard
> implementation dependent)

Yeap. e.g., when BB is used signaling may be needed between BBs of adjacent 
QoS domains.	

Xiaoming

> 
> Marcus
> 
> --On Friday, January 25, 2002 5:04 PM +0100 "Georgios Karagiannis (ELN)"
> <Georgios.Karagiannis@eln.ericsson.se> wrote:
> 
> > Hi Marcus
> >
> > yes, but from what I understood from your draft
> > you assume that the QoS initiator will have to know the
> > location of the QoS controller and that the
> > signaling path may follow a different path than
> > the user data. It seems SIP to me.
> >
> > Best Regards,
> > Georgios
> >
> >
> > -----Original Message-----
> > From: Marcus Brunner [mailto:brunner@ccrle.nec.de]
> > Sent: vrijdag 25 januari 2002 17:09
> > To: Georgios Karagiannis (ELN); 'Schneider, Marco'
> > Cc: nsis@ietf.org
> > Subject: RE: [NSIS] Two kinds of requirements
> >
> >
> > Looks nice for fixed network. However, as soon as mobility is involved it
> > gets more difficult. That was the reason that in our framewrok we talk
> > about QoS initiator and QoS controller, instead of teh componenets where
> > the componenets are sitting (which we find not really relevant)
> >
> > Marcus
> >
> > --On Tuesday, January 22, 2002 10:39 AM +0100 "Georgios Karagiannis
> > (ELN)"  <Georgios.Karagiannis@eln.ericsson.se> wrote:
> >
> >> Hi Marco
> >>
> >> The possible NSIS protocol components that can be
> >> used on the different NSIS protocol types are the following:
> >>
> >>  * used components in "end host to end host" NSIS scenario:
> >>       [everyhost], [everyedge], [everyhop]
> >>
> >>  * used components in "end host to proxy" NSIS scenario:
> >>       [everyhost], [everyedge], [everyhop]
> >>
> >>  * used components in "end host to edge" NSIS scenario:
> >>       [everyedge], [everyhop]
> >>
> >>  * used components in "edge to edge" NSIS scenario:
> >>       [everyedge], [everyhop]
> >>
> >> Regarding the priority, we should decide it after the requirements,
> >> architecture and framework drafts are done!
> >>
> >> Best regards,
> >> Georgios
> >>
> >> -----Original Message-----
> >> From: Schneider, Marco [mailto:schneider@tri.sbc.com]
> >> Sent: dinsdag 22 januari 2002 1:03
> >> To: 'Georgios Karagiannis (ELN)'; 'dick.rr.knight@bt.com'
> >> Cc: nsis@ietf.org
> >> Subject: RE: [NSIS] Two kinds of requirements
> >>
> >>
> >> Hi Georgios, All
> >>
> >> If by x -- y you mean a protocol that runs directly between x and y (e.g.
> >> end host -- end host, end host -- proxy...) then strictly speaking we are
> >> discussing four  functionally distinct interfaces and thus four
> >> functionally distinct protocols(possibly three if we group end host --
> >> proxy and  end host -- edge together). In my opinion: First we need to
> >> decide which of these interfaces are in scope. Second we need to decide
> >> which one(s) we will address first. Third we need to define the
> >> requirements for each for each of the interfaces independently.
> >>
> >> With respect to scope and priority, I think we need to address in order:
> >> 1) end host -- edge/proxy
> >> 2) domain edge -- domain edge
> >>
> >>
> >> Marco
> >>
> >>
> >> -----Original Message-----
> >> From: Georgios Karagiannis (ELN)
> >> [mailto:Georgios.Karagiannis@eln.ericsson.se]
> >> Sent: Monday, January 21, 2002 4:30 AM
> >> To: 'dick.rr.knight@bt.com'
> >> Cc: nsis@ietf.org
> >> Subject: RE: [NSIS] Two kinds of requirements
> >>
> >>
> >>
> >> Hi Dick
> >>
> >> Please see my comment in line:
> >> [DK]>> I do agree that it need not be processed on a per hop basis as it
> >> can [DK]>> transverse a domain with a single QoS mechanism. That
> >> mechanism, be it
> >> [DK]>> diffserv or intserv, PNNI, RSVP, or even over-provisioning, takes
> >> care of
> >> [DK]>> the policing and the "path" establishment within the domain.
> >>
> >> Please note that at the moment there are scenarios that will need to
> >> process the [everyhop] component. Some of these scenarios are the Radio
> >> Access
> >> Network and Mobile IP,..
> >> Therefore, the [everyhop] component should be supported by the NSIS
> >> protocol.
> >> However a "host" or a "edge" should be able to activated or not.
> >>
> >> Furthermore, in my opinion the NSIS protocol should be:
> >> end host - end host: the NSIS protocol is terminated at end hosts;
> >> end host - proxy: the NSIS protocol is terminated at end host and proxy;
> >> end host - edge: the NSIS protocol is terminated at end end host and
> >> edge; edge - edge: the NSIS protocol is terminated at egdes of
> >> one/multiple domains;
> >>
> >>
> >> Best regards,
> >> Georgios
> >>
> >>
> >> -----Original Message-----
> >> From: Schneider, Marco [mailto:schneider@tri.sbc.com]
> >> Sent: 18 January 2002 20:10
> >> To: 'Roy, Radhika R, ALASO'; Gary Kenward; Loughney John (NRC/Helsinki);
> >> brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
> >> dick.rr.knight@bt.com
> >> Cc: nsis@ietf.org
> >> Subject: RE: [NSIS] Two kinds of requirements
> >>
> >>
> >> Hi Roy,
> >>
> >> Below is the original text from your reponse to Gary Kenward. Hopefully
> >> the context is clear.
> >>
> >> "[Roy, Radhika R, ALARC]  I would say that it is the QOS needs of the
> >> application (e.g., SIP-based VoIP) that the user likes to express (as
> >> opposed to "service"). Similarly, instead of network services, we would
> >> say network layer QOS services (e.g., RSVP, DiffServ, MPLS). We would
> >> develop the end-to-end (application layer) QOS signaling protocol (say,
> >> NSIS QOS). Now, there needs to have some kinds of standards how NSIS QOS
> >> will be mapped over RSVP, DiffServ, MPLS, etc."
> >>
> >> So by End-to-End you mean between directly between two "users". This is
> >> session level signaling and I don't believe the signaling part is within
> >> the scope of this working group. An application level QOS specification
> >> may be.
> >>
> >> After a session level agreement on QOS, the host/client/customer will
> >> need to signal an actual reservation request to the network for the
> >> necessary QOS agreed to at the session level. This is the protocol that
> >> we need to work on.
> >>
> >> This approach is discussed in the SIP draft "SIP Extensions for Media
> >> Authorization" (draft-ietf-sip-call-auth-03.txt) and the RAP draft
> >> "Framework for session set-up with media authorization"
> >> (draft-ietf-rap-session-auth-02.txt).
> >>
> >> Marco Schneider
> >>
> >> -----Original Message-----
> >> From: Roy, Radhika R, ALASO [mailto:rrroy@att.com]
> >> Sent: Friday, January 18, 2002 9:18 AM
> >> To: Schneider, Marco; Gary Kenward; Loughney John (NRC/Helsinki);
> >> brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
> >> dick.rr.knight@bt.com
> >> Cc: nsis@ietf.org
> >> Subject: RE: [NSIS] Two kinds of requirements
> >>
> >>
> >> Defined below [RRR]
> >>
> >> -----Original Message-----
> >> From: Schneider, Marco [mailto:schneider@tri.sbc.com]
> >> Sent: Thursday, January 17, 2002 8:47 PM
> >> To: Roy, Radhika R, ALASO; Gary Kenward; Loughney John (NRC/Helsinki);
> >> brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
> >> dick.rr.knight@bt.com
> >> Cc: nsis@ietf.org
> >> Subject: RE: [NSIS] Two kinds of requirements
> >>
> >>
> >> Hi Roy,
> >>
> >> Can you please define what you mean by "End-to-End Application Layer QOS
> >> Signaling". Thanks.
> >>
> >> [RRR] Suppose an user is initiation a SIP call to another user with
> >> audio, video, and data. The use needs to express the needs of QOS for
> >> audio, video, and data to another user.
> >>
> >> [RRR] The signaling mechanism that allows to express the QOS parameters
> >> of audio, video, and data is termed as the "End-to-End Application Layer
> >> QOS Signaling."
> >>
> >> Marco Schneider
> >>
> >> _______________________________________________
> >> 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
> >>
> >
> >
> >
> > --------------------------------------
> > Dr. Marcus Brunner
> > Network Laboratories
> > NEC Europe Ltd.
> >
> > E-Mail: brunner@ccrle.nec.de
> > WWW:    http://www.ccrle.nec.de/
> > personal home page: http://www.brubers.org/marcus
> >
> >
> > _______________________________________________
> > nsis mailing list
> > nsis@ietf.org
> > https://www1.ietf.org/mailman/listinfo/nsis
> >
> 
> --------------------------------------
> Dr. Marcus Brunner
> Network Laboratories
> NEC Europe Ltd.
> 
> E-Mail: brunner@ccrle.nec.de
> WWW:    http://www.ccrle.nec.de/
> personal home page: http://www.brubers.org/marcus
> 
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis

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



From daemon@ns.ietf.org  Fri Jan 25 14:27: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 OAA11933
	for <nsis-archive@odin.ietf.org>; Fri, 25 Jan 2002 14:27:41 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id OAA04544
	for nsis-archive@odin.ietf.org; Fri, 25 Jan 2002 14:27: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 OAA04136;
	Fri, 25 Jan 2002 14: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 OAA04103
	for <nsis@ns.ietf.org>; Fri, 25 Jan 2002 14:17:51 -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 OAA11568
	for <nsis@ietf.org>; Fri, 25 Jan 2002 14:17:48 -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.34)
	  id 16UBqe-0001OH-00; Fri, 25 Jan 2002 20:17:16 +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 g0PJHFa21626;
	Fri, 25 Jan 2002 20:17:15 +0100
Message-ID: <3C51AF3A.4D8CF5FE@ee.tu-berlin.de>
Date: Fri, 25 Jan 2002 20:17:14 +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: Ping Pan <pingpan@juniper.net>, nsis@ietf.org,
        Paulo Mendes <mendes@cs.columbia.edu>, David.Partain@ericsson.com
Subject: Re: [NSIS] Framework & requirements part of the "Two kinds of  
 requirements" thread
References: <0GQD001M6YBEYP@mbb1.ericsson.se> <3C4EF853.B10F8796@ee.tu-berlin.de> <3C4F0560.20508@juniper.net> <3C508301.7040206@cs.columbia.edu> <3C50942E.3080104@juniper.net>
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

Ping,

Ping Pan wrote:
> 
> Paulo,
> 
> How are you!
> 
> Paulo Mendes wrote:
> 
> >> Also, let's be careful with adaptive applications. They look very nice
> >> on paper, but when you see what type of switches are used interfacing
> >> between voice networks and the Internet, you gotta be kidding me to
> >> insist on adaptiveness for your traffic....
> >
> >
> >
> > [PM] I don't know about others, but when I speak about adaptive
> > applications I'm thinking of 100% IP networks.
> >
> 
> The problem is that much of the voice traffic flowing over the Internet
> has nothing to do with the native Internet applications. Many providers
> setup tunnels through their backbones and transport non-IP packets. The
> access points are not pure IP boxes. They may be some ancient and
> expensive Luent switches. If you ask the switches to run some fancy
> adaptive schemes to all the traffic, they may crash.

If the number of fancy applications increases fast (so that an expected
revenue is generated - even more than the cost of updating the infrastructure), 
those switches will be motivated to be updated with more advance stuffs, 
although there might be a latency for deployment.

> >
> >> Currently, most of the backbone networks are over-provisioned, so no
> >> serious signaling is required yet. End-to-end signaling is very
> >> attractive to the end users, but the providers will not allow the
> >> users to tell the routers how much to reserve. In fact, I doubt the
> >> providers will listen to anything that end-user are throwing at them.
> >> So other than some end-to-end measurement-based approach, I don't see
> >> e2e signaling will fly in the present network.
> >
> >
> >
> > [PM] Allow me to disagree... Are you mentioning US over-provided
> > networks, or networks in other geographic locations? And even if you're
> > only thinking in an US Internet, can you tell me how can this
> > over-provision take place?
> 
> (I thought I wrote a paper on this in my past life....:-)) Yes, all
> backbones have "hot" spots, and have congestion. But the backbone
> problems can be (or have been) addressed via RSVP-TE. Yes, we have
> short-time outage in the backbone due to frequent upgrade and router
> crash. That's why we have worked very hard on backbone traffic
> redundency (fast reroute, graceful restart.....) issues. So far, I have
> a pretty good feeling on resource management within the backbone. The
> focus is now on the edge and the access. I am hoping NSIS is the place
> to do it.
> 
> > I agree that network providers can't engineer their network to satisfy
> > every single client reclamation. That's why clients (receivers) with
> > adaptive applications are useful to network providers. The network
> > notify about their capabilities and the clients deal with it (adapt,
> > leave session, ...).
> 
> The "receivers" can be some monitoring boxes arranged by the providers
> to monitor the traffic in/out of the network. If things are not OK,
> these boxes may play some rotuing tricks to redirect traffic from the
> edge. I am not sure they are regular users.

Kind of such "monitoring" could be a good tool for providers, but I think
for regular users as you pointed out, the best way is still to follow
a host-edge/host-host way to be defined within NSIS or NSIS++ work.

> >
> >> Finally, the providers are motivated by money to provide any
> >> additional service. Unless the traffic that they are carrying worth
> >> something, they will never deploy some extra "stuff" inside the
> >> network. So what's worth money? ....
> >
> >
> 
> >
> > [PM] Okey.. But if network providers don't develop new services how can
> > they expect clients to use them, if they don't exist?
> >
> 
> I have just listed some of the services below. IMHO, the current state
> of the Internet is not about "new" services, or "new" economy to that
> matter. The Internet is a new media to transport traffic, like we have
> been doing via post office, SNA, phone networks, Frame/ATM networks....
> The trick is to send the same old information efficiently.... Plus the
> Internet needs to evolve itself to carry traffic some future
> applications when they come..
> >
> >> - voice traffic! I am not only talking about VoIP; I am talking all
> >> the voice traffic that use the Internet infrastructure.
> >>
> >> - wireless traffic: users packets are not landed inside the backbone,
> >> so the access network needs to do more to those flows.
> >>
> >> - VPN (an over-used term :-)): but some users want to have QoS
> >> reservation even though they are sending any traffic. Not for any
> >> technical reason, it's a business reason. Have you seen the amount of
> >> traffic in a SNA network, and how much they have been charged? :-)
> >>

Besides, mobility traffic may be also part of the former two you mentioned 
above but belongs to the "new" services which needs extra "stuff".

Cheers,
Xiaoming

> 
> - Ping
> 
> _______________________________________________
> 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  Sun Jan 27 12:58: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 MAA01800
	for <nsis-archive@odin.ietf.org>; Sun, 27 Jan 2002 12:58:44 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id MAA19589
	for nsis-archive@odin.ietf.org; Sun, 27 Jan 2002 12:58: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 MAA19409;
	Sun, 27 Jan 2002 12:48: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 MAA19379
	for <nsis@optimus.ietf.org>; Sun, 27 Jan 2002 12:48:33 -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 MAA01734
	for <nsis@ietf.org>; Sun, 27 Jan 2002 12:48:31 -0500 (EST)
Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56])
	by zcars0m9.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g0RHm1V12021;
	Sun, 27 Jan 2002 12:48:01 -0500 (EST)
Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7])
	by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g0RHlxG15589;
	Sun, 27 Jan 2002 12:47:59 -0500 (EST)
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19)
	id <C8PZ60GY>; Sun, 27 Jan 2002 12:47:59 -0500
Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA47BF@zcard031.ca.nortel.com>
From: "Gary Kenward"<gkenward@nortelnetworks.com>
To: "'David.Partain@ericsson.com'" <David.Partain@ericsson.com>,
        "'NSIS Mailing List'" <nsis@ietf.org>
Subject: RE: [NSIS] Framework & requirements part of the "Two kinds of  re
	quirements" thread
Date: Sun, 27 Jan 2002 12:47:59 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C1A75A.C290CF90"
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_01C1A75A.C290CF90
Content-Type: text/plain;
	charset="ISO-8859-1"

David:

  I agree with your definition of an application for this
work, namely use cases. Keep in mind there has been a thread
on "adaptive applications", which is an entirely different kind
of application.

  I find use cases a very useful tool, when properly used ;^}.

Gary

> -----Original Message-----
> From: David Partain [mailto:David.Partain@ericsson.com]
> Sent: January 25, 2002 10:42
> To: 'NSIS Mailing List'
> Subject: Re: [NSIS] Framework & requirements part of the "Two kinds of
> requirements" thread
> 
> 
> Greetings all,
> 
> > On Thursday 24 January 2002 17:17, Gary Kenward wrote:
> > I don't believe that anyone has proposed "kitchen sink" or
> > signalling that is not needed.
> 
> Perhaps that is the case.  I guess my wariness grows out
> of seeing folks in many contexts try to solve everything
> in this rather complex problem area all at once.  Seen
> individually, most of the ideas are likely a Good Thing, but
> seen collectively, it's just too much.  I guess Ping is just
> raising a red flag and I think that's useful.
> 
> > I believe that there are a number of very important problem
> > areas that need to be addressed. At the moment, the prevalent
> > thread is whether all or many of these signalling needs can be
> > resolved with one protocol. There is a great risk in attacking
> > the problem in a piecemeal fashion: the result may not hold
> > solve enough of the problem to be useful.
> 
> I certainly agree and wouldn't advocate piecemeal.  I just
> _know_ that we won't solve everything now, even if we try.
> As such, we need to solve what is most acute and put something
> in place that makes solving later problems easier.
> 
> > Some specific comments:
> > 
> >   - if there is a need for a protocol to run end-to-end at the
> >     application layer without interacting with the network,
> >     then this can be resolved in two ways: a separate protocol
> >     that is designed *only* for this purpose; a protocol
> >     that can interact with a network, if the network is able
> >     and willing (i.e. has the functional and policy support).
> >     the first solution fulfils only one of the needs stated so
> >     far on this list, and implies a requirement for multiple
> >     signalling protocols to set up the end to end *and* network
> >     QoS; on the plus side, it is a self contained problem
> >     (by definition), independent upon network architecture.
> > 
> >     the second solution is tougher because it requires
> >     a definition of a generic framework that will allow
> >     interaction between the end-to- end and entities within
> >     the network; on the plus side, it is likely to be more
> >     efficient then the first solution.
> 
> I'm not sure that I've got all the implications of what you
> write, but based on what I think I get, we need to work on the
> latter of the two.
> 
> >   - implicit in Ping Pan's proposal is the idea that a useful
> >     signalling protocol will emerge out of the sequential
> >     development of hop-by-hop signalling (i.e. host to edge,
> >     node to node, edge to edge, etc.); this is somewhat like
> >     trying to build a jet engine one piece at a time, it will
> >     not work unless you have an idea where the pieces fit
> >     ahead of time.
> 
> No doubt about it.  We need the overall plan as well.
> 
> >   - while I'm not entirely sure what Ping Pan means by an
> >     "application" (i.e. a usage scenario coupled with network
> >     services, a piece of software) basing the design on a
> >     subset of applications may be the fastest way of generating
> >     a solution, but no likely the most useful in the long term.
> 
> As long as we can avoid doing something Fatally Dumb in terms
> of extensibilty, it might be both the fastest way and useful
> in the long term.
> 
> > Finally, I support the idea of tackling a specific problem
> > are first: my preference being host to edge, but I strongly
> > recommend that we make an attempt to define a strawman
> > framework first. I emphasize "strawman" - the term implies
> > that the framework will be evolve significantly.
> 
> Yep.  This is one of our tasks.
> 
> > I do not support the idea of using a subset of applications
> > to design a protocol.  I like the idea of using use cases,
> > as long as they are acceptable to the IESG, and as long as
> > they go beyond "user/end system interaction".
> 
> Perhaps I'm just missing something, but I see the applications
> as use cases.  If I take the "application" of cellular mobile
> telephony (only as one of the possible applications, folks :-)),
> that provides a good use case for what we're defining.
> 
> Cheers,
> 
> dlp
> 
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis
> 

------_=_NextPart_001_01C1A75A.C290CF90
Content-Type: text/html;
	charset="ISO-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2654.89">
<TITLE>RE: [NSIS] Framework &amp; requirements part of the &quot;Two kinds of  requirements&quot; thread</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>David:</FONT>
</P>

<P><FONT SIZE=2>&nbsp; I agree with your definition of an application for this</FONT>
<BR><FONT SIZE=2>work, namely use cases. Keep in mind there has been a thread</FONT>
<BR><FONT SIZE=2>on &quot;adaptive applications&quot;, which is an entirely different kind</FONT>
<BR><FONT SIZE=2>of application.</FONT>
</P>

<P><FONT SIZE=2>&nbsp; I find use cases a very useful tool, when properly used ;^}.</FONT>
</P>

<P><FONT SIZE=2>Gary</FONT>
</P>

<P><FONT SIZE=2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; From: David Partain [<A HREF="mailto:David.Partain@ericsson.com">mailto:David.Partain@ericsson.com</A>]</FONT>
<BR><FONT SIZE=2>&gt; Sent: January 25, 2002 10:42</FONT>
<BR><FONT SIZE=2>&gt; To: 'NSIS Mailing List'</FONT>
<BR><FONT SIZE=2>&gt; Subject: Re: [NSIS] Framework &amp; requirements part of the &quot;Two kinds of</FONT>
<BR><FONT SIZE=2>&gt; requirements&quot; thread</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Greetings all,</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; On Thursday 24 January 2002 17:17, Gary Kenward wrote:</FONT>
<BR><FONT SIZE=2>&gt; &gt; I don't believe that anyone has proposed &quot;kitchen sink&quot; or</FONT>
<BR><FONT SIZE=2>&gt; &gt; signalling that is not needed.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Perhaps that is the case.&nbsp; I guess my wariness grows out</FONT>
<BR><FONT SIZE=2>&gt; of seeing folks in many contexts try to solve everything</FONT>
<BR><FONT SIZE=2>&gt; in this rather complex problem area all at once.&nbsp; Seen</FONT>
<BR><FONT SIZE=2>&gt; individually, most of the ideas are likely a Good Thing, but</FONT>
<BR><FONT SIZE=2>&gt; seen collectively, it's just too much.&nbsp; I guess Ping is just</FONT>
<BR><FONT SIZE=2>&gt; raising a red flag and I think that's useful.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; I believe that there are a number of very important problem</FONT>
<BR><FONT SIZE=2>&gt; &gt; areas that need to be addressed. At the moment, the prevalent</FONT>
<BR><FONT SIZE=2>&gt; &gt; thread is whether all or many of these signalling needs can be</FONT>
<BR><FONT SIZE=2>&gt; &gt; resolved with one protocol. There is a great risk in attacking</FONT>
<BR><FONT SIZE=2>&gt; &gt; the problem in a piecemeal fashion: the result may not hold</FONT>
<BR><FONT SIZE=2>&gt; &gt; solve enough of the problem to be useful.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; I certainly agree and wouldn't advocate piecemeal.&nbsp; I just</FONT>
<BR><FONT SIZE=2>&gt; _know_ that we won't solve everything now, even if we try.</FONT>
<BR><FONT SIZE=2>&gt; As such, we need to solve what is most acute and put something</FONT>
<BR><FONT SIZE=2>&gt; in place that makes solving later problems easier.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; Some specific comments:</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp; - if there is a need for a protocol to run end-to-end at the</FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; application layer without interacting with the network,</FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; then this can be resolved in two ways: a separate protocol</FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; that is designed *only* for this purpose; a protocol</FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; that can interact with a network, if the network is able</FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; and willing (i.e. has the functional and policy support).</FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; the first solution fulfils only one of the needs stated so</FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; far on this list, and implies a requirement for multiple</FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; signalling protocols to set up the end to end *and* network</FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; QoS; on the plus side, it is a self contained problem</FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; (by definition), independent upon network architecture.</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; the second solution is tougher because it requires</FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; a definition of a generic framework that will allow</FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; interaction between the end-to- end and entities within</FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; the network; on the plus side, it is likely to be more</FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; efficient then the first solution.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; I'm not sure that I've got all the implications of what you</FONT>
<BR><FONT SIZE=2>&gt; write, but based on what I think I get, we need to work on the</FONT>
<BR><FONT SIZE=2>&gt; latter of the two.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp; - implicit in Ping Pan's proposal is the idea that a useful</FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; signalling protocol will emerge out of the sequential</FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; development of hop-by-hop signalling (i.e. host to edge,</FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; node to node, edge to edge, etc.); this is somewhat like</FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; trying to build a jet engine one piece at a time, it will</FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; not work unless you have an idea where the pieces fit</FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; ahead of time.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; No doubt about it.&nbsp; We need the overall plan as well.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp; - while I'm not entirely sure what Ping Pan means by an</FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; &quot;application&quot; (i.e. a usage scenario coupled with network</FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; services, a piece of software) basing the design on a</FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; subset of applications may be the fastest way of generating</FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; a solution, but no likely the most useful in the long term.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; As long as we can avoid doing something Fatally Dumb in terms</FONT>
<BR><FONT SIZE=2>&gt; of extensibilty, it might be both the fastest way and useful</FONT>
<BR><FONT SIZE=2>&gt; in the long term.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; Finally, I support the idea of tackling a specific problem</FONT>
<BR><FONT SIZE=2>&gt; &gt; are first: my preference being host to edge, but I strongly</FONT>
<BR><FONT SIZE=2>&gt; &gt; recommend that we make an attempt to define a strawman</FONT>
<BR><FONT SIZE=2>&gt; &gt; framework first. I emphasize &quot;strawman&quot; - the term implies</FONT>
<BR><FONT SIZE=2>&gt; &gt; that the framework will be evolve significantly.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Yep.&nbsp; This is one of our tasks.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; I do not support the idea of using a subset of applications</FONT>
<BR><FONT SIZE=2>&gt; &gt; to design a protocol.&nbsp; I like the idea of using use cases,</FONT>
<BR><FONT SIZE=2>&gt; &gt; as long as they are acceptable to the IESG, and as long as</FONT>
<BR><FONT SIZE=2>&gt; &gt; they go beyond &quot;user/end system interaction&quot;.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Perhaps I'm just missing something, but I see the applications</FONT>
<BR><FONT SIZE=2>&gt; as use cases.&nbsp; If I take the &quot;application&quot; of cellular mobile</FONT>
<BR><FONT SIZE=2>&gt; telephony (only as one of the possible applications, folks :-)),</FONT>
<BR><FONT SIZE=2>&gt; that provides a good use case for what we're defining.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Cheers,</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; dlp</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; _______________________________________________</FONT>
<BR><FONT SIZE=2>&gt; nsis mailing list</FONT>
<BR><FONT SIZE=2>&gt; nsis@ietf.org</FONT>
<BR><FONT SIZE=2>&gt; <A HREF="https://www1.ietf.org/mailman/listinfo/nsis" TARGET="_blank">https://www1.ietf.org/mailman/listinfo/nsis</A></FONT>
<BR><FONT SIZE=2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1A75A.C290CF90--

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



From daemon@optimus.ietf.org  Mon Jan 28 05:12: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 FAA21624
	for <nsis-archive@odin.ietf.org>; Mon, 28 Jan 2002 05:12:47 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id FAA01816
	for nsis-archive@odin.ietf.org; Mon, 28 Jan 2002 05:12: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 FAA01441;
	Mon, 28 Jan 2002 05:03: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 FAA01412
	for <nsis@optimus.ietf.org>; Mon, 28 Jan 2002 05:02:56 -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 FAA21534
	for <nsis@ietf.org>; Mon, 28 Jan 2002 05:02:52 -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 g0SA2rC14587
	for <nsis@ietf.org>; Mon, 28 Jan 2002 11:02:54 +0100 (MET)
Received: from esealnt462.al.sw.ericsson.se
 (ESEALNT462.al.sw.ericsson.se [153.88.251.62])
 by mbb1.ericsson.se (PMDF V5.2-29 #39352)
 with SMTP id <0GQN003FV58004@mbb1.ericsson.se> for nsis@ietf.org; Mon,
 28 Jan 2002 10:04:48 +0100 (MET)
Received: FROM esealnt746.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ;
 Mon Jan 28 09:52:17 2002 +0100
Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service
 (5.5.2653.19)	id <YHLJM7AQ>; Mon, 28 Jan 2002 09:52:34 +0100
Date: Mon, 28 Jan 2002 09:52:33 +0100
From: "Georgios Karagiannis (ELN)" <Georgios.Karagiannis@eln.ericsson.se>
Subject: RE: Independence of signalling and data path (was RE: [NSIS] Two
	kindsof  requirements)
To: "'fu@ee.tu-berlin.de'" <fu@ee.tu-berlin.de>, brunner@ccrle.nec.de
Cc: nsis@ietf.org
Message-id: 
 <E244E44D6AB85E40AEEF7EAABE3545FA8233C8@enleent104.nl.eu.ericsson.se>
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 Xiaoming and Marcus

If you would like to have a QoS communication between a 
QoS initiator and a QoS controller you could
then use the "host to proxy" version of the NSIS protocol.

You could then accomplish exactly the same functionality
without requiring that the signaling path is independent from 
the data path.

Best regards,
Georgios

-----Original Message-----
From: Xiaoming Fu [mailto:fu@ee.tu-berlin.de]
Sent: vrijdag 25 januari 2002 19:40
To: brunner@ccrle.nec.de
Cc: Georgios Karagiannis (ELN); nsis@ietf.org
Subject: Re: Independence of signalling and data path (was RE: [NSIS]
Two kindsof requirements)


Marcus,

Marcus Brunner wrote:
> 
> I you want to see SIP in you can sure. But that was our intention.
> 
> I  personally think, that the signalling path should not be bound to the
> data path. Whether you need to know the location of the QoS controller
> heavility depends on the specific protocols defined (and might be regard
> implementation dependent)

Yeap. e.g., when BB is used signaling may be needed between BBs of adjacent 
QoS domains.	

Xiaoming

> 
> Marcus
> 
> --On Friday, January 25, 2002 5:04 PM +0100 "Georgios Karagiannis (ELN)"
> <Georgios.Karagiannis@eln.ericsson.se> wrote:
> 
> > Hi Marcus
> >
> > yes, but from what I understood from your draft
> > you assume that the QoS initiator will have to know the
> > location of the QoS controller and that the
> > signaling path may follow a different path than
> > the user data. It seems SIP to me.
> >
> > Best Regards,
> > Georgios
> >
> >
> > -----Original Message-----
> > From: Marcus Brunner [mailto:brunner@ccrle.nec.de]
> > Sent: vrijdag 25 januari 2002 17:09
> > To: Georgios Karagiannis (ELN); 'Schneider, Marco'
> > Cc: nsis@ietf.org
> > Subject: RE: [NSIS] Two kinds of requirements
> >
> >
> > Looks nice for fixed network. However, as soon as mobility is involved it
> > gets more difficult. That was the reason that in our framewrok we talk
> > about QoS initiator and QoS controller, instead of teh componenets where
> > the componenets are sitting (which we find not really relevant)
> >
> > Marcus
> >
> > --On Tuesday, January 22, 2002 10:39 AM +0100 "Georgios Karagiannis
> > (ELN)"  <Georgios.Karagiannis@eln.ericsson.se> wrote:
> >
> >> Hi Marco
> >>
> >> The possible NSIS protocol components that can be
> >> used on the different NSIS protocol types are the following:
> >>
> >>  * used components in "end host to end host" NSIS scenario:
> >>       [everyhost], [everyedge], [everyhop]
> >>
> >>  * used components in "end host to proxy" NSIS scenario:
> >>       [everyhost], [everyedge], [everyhop]
> >>
> >>  * used components in "end host to edge" NSIS scenario:
> >>       [everyedge], [everyhop]
> >>
> >>  * used components in "edge to edge" NSIS scenario:
> >>       [everyedge], [everyhop]
> >>
> >> Regarding the priority, we should decide it after the requirements,
> >> architecture and framework drafts are done!
> >>
> >> Best regards,
> >> Georgios
> >>
> >> -----Original Message-----
> >> From: Schneider, Marco [mailto:schneider@tri.sbc.com]
> >> Sent: dinsdag 22 januari 2002 1:03
> >> To: 'Georgios Karagiannis (ELN)'; 'dick.rr.knight@bt.com'
> >> Cc: nsis@ietf.org
> >> Subject: RE: [NSIS] Two kinds of requirements
> >>
> >>
> >> Hi Georgios, All
> >>
> >> If by x -- y you mean a protocol that runs directly between x and y (e.g.
> >> end host -- end host, end host -- proxy...) then strictly speaking we are
> >> discussing four  functionally distinct interfaces and thus four
> >> functionally distinct protocols(possibly three if we group end host --
> >> proxy and  end host -- edge together). In my opinion: First we need to
> >> decide which of these interfaces are in scope. Second we need to decide
> >> which one(s) we will address first. Third we need to define the
> >> requirements for each for each of the interfaces independently.
> >>
> >> With respect to scope and priority, I think we need to address in order:
> >> 1) end host -- edge/proxy
> >> 2) domain edge -- domain edge
> >>
> >>
> >> Marco
> >>
> >>
> >> -----Original Message-----
> >> From: Georgios Karagiannis (ELN)
> >> [mailto:Georgios.Karagiannis@eln.ericsson.se]
> >> Sent: Monday, January 21, 2002 4:30 AM
> >> To: 'dick.rr.knight@bt.com'
> >> Cc: nsis@ietf.org
> >> Subject: RE: [NSIS] Two kinds of requirements
> >>
> >>
> >>
> >> Hi Dick
> >>
> >> Please see my comment in line:
> >> [DK]>> I do agree that it need not be processed on a per hop basis as it
> >> can [DK]>> transverse a domain with a single QoS mechanism. That
> >> mechanism, be it
> >> [DK]>> diffserv or intserv, PNNI, RSVP, or even over-provisioning, takes
> >> care of
> >> [DK]>> the policing and the "path" establishment within the domain.
> >>
> >> Please note that at the moment there are scenarios that will need to
> >> process the [everyhop] component. Some of these scenarios are the Radio
> >> Access
> >> Network and Mobile IP,..
> >> Therefore, the [everyhop] component should be supported by the NSIS
> >> protocol.
> >> However a "host" or a "edge" should be able to activated or not.
> >>
> >> Furthermore, in my opinion the NSIS protocol should be:
> >> end host - end host: the NSIS protocol is terminated at end hosts;
> >> end host - proxy: the NSIS protocol is terminated at end host and proxy;
> >> end host - edge: the NSIS protocol is terminated at end end host and
> >> edge; edge - edge: the NSIS protocol is terminated at egdes of
> >> one/multiple domains;
> >>
> >>
> >> Best regards,
> >> Georgios
> >>
> >>
> >> -----Original Message-----
> >> From: Schneider, Marco [mailto:schneider@tri.sbc.com]
> >> Sent: 18 January 2002 20:10
> >> To: 'Roy, Radhika R, ALASO'; Gary Kenward; Loughney John (NRC/Helsinki);
> >> brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
> >> dick.rr.knight@bt.com
> >> Cc: nsis@ietf.org
> >> Subject: RE: [NSIS] Two kinds of requirements
> >>
> >>
> >> Hi Roy,
> >>
> >> Below is the original text from your reponse to Gary Kenward. Hopefully
> >> the context is clear.
> >>
> >> "[Roy, Radhika R, ALARC]  I would say that it is the QOS needs of the
> >> application (e.g., SIP-based VoIP) that the user likes to express (as
> >> opposed to "service"). Similarly, instead of network services, we would
> >> say network layer QOS services (e.g., RSVP, DiffServ, MPLS). We would
> >> develop the end-to-end (application layer) QOS signaling protocol (say,
> >> NSIS QOS). Now, there needs to have some kinds of standards how NSIS QOS
> >> will be mapped over RSVP, DiffServ, MPLS, etc."
> >>
> >> So by End-to-End you mean between directly between two "users". This is
> >> session level signaling and I don't believe the signaling part is within
> >> the scope of this working group. An application level QOS specification
> >> may be.
> >>
> >> After a session level agreement on QOS, the host/client/customer will
> >> need to signal an actual reservation request to the network for the
> >> necessary QOS agreed to at the session level. This is the protocol that
> >> we need to work on.
> >>
> >> This approach is discussed in the SIP draft "SIP Extensions for Media
> >> Authorization" (draft-ietf-sip-call-auth-03.txt) and the RAP draft
> >> "Framework for session set-up with media authorization"
> >> (draft-ietf-rap-session-auth-02.txt).
> >>
> >> Marco Schneider
> >>
> >> -----Original Message-----
> >> From: Roy, Radhika R, ALASO [mailto:rrroy@att.com]
> >> Sent: Friday, January 18, 2002 9:18 AM
> >> To: Schneider, Marco; Gary Kenward; Loughney John (NRC/Helsinki);
> >> brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
> >> dick.rr.knight@bt.com
> >> Cc: nsis@ietf.org
> >> Subject: RE: [NSIS] Two kinds of requirements
> >>
> >>
> >> Defined below [RRR]
> >>
> >> -----Original Message-----
> >> From: Schneider, Marco [mailto:schneider@tri.sbc.com]
> >> Sent: Thursday, January 17, 2002 8:47 PM
> >> To: Roy, Radhika R, ALASO; Gary Kenward; Loughney John (NRC/Helsinki);
> >> brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
> >> dick.rr.knight@bt.com
> >> Cc: nsis@ietf.org
> >> Subject: RE: [NSIS] Two kinds of requirements
> >>
> >>
> >> Hi Roy,
> >>
> >> Can you please define what you mean by "End-to-End Application Layer QOS
> >> Signaling". Thanks.
> >>
> >> [RRR] Suppose an user is initiation a SIP call to another user with
> >> audio, video, and data. The use needs to express the needs of QOS for
> >> audio, video, and data to another user.
> >>
> >> [RRR] The signaling mechanism that allows to express the QOS parameters
> >> of audio, video, and data is termed as the "End-to-End Application Layer
> >> QOS Signaling."
> >>
> >> Marco Schneider
> >>
> >> _______________________________________________
> >> 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
> >>
> >
> >
> >
> > --------------------------------------
> > Dr. Marcus Brunner
> > Network Laboratories
> > NEC Europe Ltd.
> >
> > E-Mail: brunner@ccrle.nec.de
> > WWW:    http://www.ccrle.nec.de/
> > personal home page: http://www.brubers.org/marcus
> >
> >
> > _______________________________________________
> > nsis mailing list
> > nsis@ietf.org
> > https://www1.ietf.org/mailman/listinfo/nsis
> >
> 
> --------------------------------------
> Dr. Marcus Brunner
> Network Laboratories
> NEC Europe Ltd.
> 
> E-Mail: brunner@ccrle.nec.de
> WWW:    http://www.ccrle.nec.de/
> personal home page: http://www.brubers.org/marcus
> 
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis

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



From daemon@optimus.ietf.org  Mon Jan 28 05:54:51 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21974
	for <nsis-archive@odin.ietf.org>; Mon, 28 Jan 2002 05:54:46 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id FAA03313
	for nsis-archive@odin.ietf.org; Mon, 28 Jan 2002 05:54: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 FAA03290;
	Mon, 28 Jan 2002 05:53: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 FAA03225
	for <nsis@optimus.ietf.org>; Mon, 28 Jan 2002 05:53: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 FAA21968
	for <nsis@ietf.org>; Mon, 28 Jan 2002 05:53:31 -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 g0SArEj39432;
	Mon, 28 Jan 2002 11:53:14 +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 05E02C05B; Mon, 28 Jan 2002 11:52:35 +0100 (CET)
Date: Mon, 28 Jan 2002 12:04:29 +0100
From: Marcus Brunner <brunner@ccrle.nec.de>
Reply-To: brunner@ccrle.nec.de
To: "Georgios Karagiannis (ELN)" <Georgios.Karagiannis@eln.ericsson.se>,
        "'fu@ee.tu-berlin.de'" <fu@ee.tu-berlin.de>
Cc: nsis@ietf.org
Message-ID: <12795078.1012219469@[192.168.102.79]>
In-Reply-To:  <E244E44D6AB85E40AEEF7EAABE3545FA8233C8@enleent104.nl.eu.ericsson.se>
References:  
 <E244E44D6AB85E40AEEF7EAABE3545FA8233C8@enleent104.nl.eu.ericsson.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: Independence of signalling and data path (was RE: [NSIS]
 Two	kindsof  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 not sure, what exactly you mean by the "host to proxy" version of the 
protocol, but the main problem lies in mobil environments, where I 
currently see a problem.

What is in your opinion the problem of requiring independent signalling and 
data pathes?

Marcus

--On Monday, January 28, 2002 9:52 AM +0100 "Georgios Karagiannis (ELN)" 
<Georgios.Karagiannis@eln.ericsson.se> wrote:

> Hi Xiaoming and Marcus
>
> If you would like to have a QoS communication between a
> QoS initiator and a QoS controller you could
> then use the "host to proxy" version of the NSIS protocol.
>
> You could then accomplish exactly the same functionality
> without requiring that the signaling path is independent from
> the data path.
>
> Best regards,
> Georgios
>
> -----Original Message-----
> From: Xiaoming Fu [mailto:fu@ee.tu-berlin.de]
> Sent: vrijdag 25 januari 2002 19:40
> To: brunner@ccrle.nec.de
> Cc: Georgios Karagiannis (ELN); nsis@ietf.org
> Subject: Re: Independence of signalling and data path (was RE: [NSIS]
> Two kindsof requirements)
>
>
> Marcus,
>
> Marcus Brunner wrote:
>>
>> I you want to see SIP in you can sure. But that was our intention.
>>
>> I  personally think, that the signalling path should not be bound to the
>> data path. Whether you need to know the location of the QoS controller
>> heavility depends on the specific protocols defined (and might be regard
>> implementation dependent)
>
> Yeap. e.g., when BB is used signaling may be needed between BBs of
> adjacent  QoS domains.	
>
> Xiaoming
>
>>
>> Marcus
>>
>> --On Friday, January 25, 2002 5:04 PM +0100 "Georgios Karagiannis (ELN)"
>> <Georgios.Karagiannis@eln.ericsson.se> wrote:
>>
>> > Hi Marcus
>> >
>> > yes, but from what I understood from your draft
>> > you assume that the QoS initiator will have to know the
>> > location of the QoS controller and that the
>> > signaling path may follow a different path than
>> > the user data. It seems SIP to me.
>> >
>> > Best Regards,
>> > Georgios
>> >
>> >
>> > -----Original Message-----
>> > From: Marcus Brunner [mailto:brunner@ccrle.nec.de]
>> > Sent: vrijdag 25 januari 2002 17:09
>> > To: Georgios Karagiannis (ELN); 'Schneider, Marco'
>> > Cc: nsis@ietf.org
>> > Subject: RE: [NSIS] Two kinds of requirements
>> >
>> >
>> > Looks nice for fixed network. However, as soon as mobility is involved
>> > it gets more difficult. That was the reason that in our framewrok we
>> > talk about QoS initiator and QoS controller, instead of teh
>> > componenets where the componenets are sitting (which we find not
>> > really relevant)
>> >
>> > Marcus
>> >
>> > --On Tuesday, January 22, 2002 10:39 AM +0100 "Georgios Karagiannis
>> > (ELN)"  <Georgios.Karagiannis@eln.ericsson.se> wrote:
>> >
>> >> Hi Marco
>> >>
>> >> The possible NSIS protocol components that can be
>> >> used on the different NSIS protocol types are the following:
>> >>
>> >>  * used components in "end host to end host" NSIS scenario:
>> >>       [everyhost], [everyedge], [everyhop]
>> >>
>> >>  * used components in "end host to proxy" NSIS scenario:
>> >>       [everyhost], [everyedge], [everyhop]
>> >>
>> >>  * used components in "end host to edge" NSIS scenario:
>> >>       [everyedge], [everyhop]
>> >>
>> >>  * used components in "edge to edge" NSIS scenario:
>> >>       [everyedge], [everyhop]
>> >>
>> >> Regarding the priority, we should decide it after the requirements,
>> >> architecture and framework drafts are done!
>> >>
>> >> Best regards,
>> >> Georgios
>> >>
>> >> -----Original Message-----
>> >> From: Schneider, Marco [mailto:schneider@tri.sbc.com]
>> >> Sent: dinsdag 22 januari 2002 1:03
>> >> To: 'Georgios Karagiannis (ELN)'; 'dick.rr.knight@bt.com'
>> >> Cc: nsis@ietf.org
>> >> Subject: RE: [NSIS] Two kinds of requirements
>> >>
>> >>
>> >> Hi Georgios, All
>> >>
>> >> If by x -- y you mean a protocol that runs directly between x and y
>> >> (e.g. end host -- end host, end host -- proxy...) then strictly
>> >> speaking we are discussing four  functionally distinct interfaces and
>> >> thus four functionally distinct protocols(possibly three if we group
>> >> end host -- proxy and  end host -- edge together). In my opinion:
>> >> First we need to decide which of these interfaces are in scope.
>> >> Second we need to decide which one(s) we will address first. Third we
>> >> need to define the requirements for each for each of the interfaces
>> >> independently.
>> >>
>> >> With respect to scope and priority, I think we need to address in
>> >> order: 1) end host -- edge/proxy
>> >> 2) domain edge -- domain edge
>> >>
>> >>
>> >> Marco
>> >>
>> >>
>> >> -----Original Message-----
>> >> From: Georgios Karagiannis (ELN)
>> >> [mailto:Georgios.Karagiannis@eln.ericsson.se]
>> >> Sent: Monday, January 21, 2002 4:30 AM
>> >> To: 'dick.rr.knight@bt.com'
>> >> Cc: nsis@ietf.org
>> >> Subject: RE: [NSIS] Two kinds of requirements
>> >>
>> >>
>> >>
>> >> Hi Dick
>> >>
>> >> Please see my comment in line:
>> >> [DK]>> I do agree that it need not be processed on a per hop basis as
>> >> it can [DK]>> transverse a domain with a single QoS mechanism. That
>> >> mechanism, be it
>> >> [DK]>> diffserv or intserv, PNNI, RSVP, or even over-provisioning,
>> >> takes care of
>> >> [DK]>> the policing and the "path" establishment within the domain.
>> >>
>> >> Please note that at the moment there are scenarios that will need to
>> >> process the [everyhop] component. Some of these scenarios are the
>> >> Radio Access
>> >> Network and Mobile IP,..
>> >> Therefore, the [everyhop] component should be supported by the NSIS
>> >> protocol.
>> >> However a "host" or a "edge" should be able to activated or not.
>> >>
>> >> Furthermore, in my opinion the NSIS protocol should be:
>> >> end host - end host: the NSIS protocol is terminated at end hosts;
>> >> end host - proxy: the NSIS protocol is terminated at end host and
>> >> proxy; end host - edge: the NSIS protocol is terminated at end end
>> >> host and edge; edge - edge: the NSIS protocol is terminated at egdes
>> >> of one/multiple domains;
>> >>
>> >>
>> >> Best regards,
>> >> Georgios
>> >>
>> >>
>> >> -----Original Message-----
>> >> From: Schneider, Marco [mailto:schneider@tri.sbc.com]
>> >> Sent: 18 January 2002 20:10
>> >> To: 'Roy, Radhika R, ALASO'; Gary Kenward; Loughney John
>> >> (NRC/Helsinki); brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
>> >> dick.rr.knight@bt.com
>> >> Cc: nsis@ietf.org
>> >> Subject: RE: [NSIS] Two kinds of requirements
>> >>
>> >>
>> >> Hi Roy,
>> >>
>> >> Below is the original text from your reponse to Gary Kenward.
>> >> Hopefully the context is clear.
>> >>
>> >> "[Roy, Radhika R, ALARC]  I would say that it is the QOS needs of the
>> >> application (e.g., SIP-based VoIP) that the user likes to express (as
>> >> opposed to "service"). Similarly, instead of network services, we
>> >> would say network layer QOS services (e.g., RSVP, DiffServ, MPLS). We
>> >> would develop the end-to-end (application layer) QOS signaling
>> >> protocol (say, NSIS QOS). Now, there needs to have some kinds of
>> >> standards how NSIS QOS will be mapped over RSVP, DiffServ, MPLS, etc."
>> >>
>> >> So by End-to-End you mean between directly between two "users". This
>> >> is session level signaling and I don't believe the signaling part is
>> >> within the scope of this working group. An application level QOS
>> >> specification may be.
>> >>
>> >> After a session level agreement on QOS, the host/client/customer will
>> >> need to signal an actual reservation request to the network for the
>> >> necessary QOS agreed to at the session level. This is the protocol
>> >> that we need to work on.
>> >>
>> >> This approach is discussed in the SIP draft "SIP Extensions for Media
>> >> Authorization" (draft-ietf-sip-call-auth-03.txt) and the RAP draft
>> >> "Framework for session set-up with media authorization"
>> >> (draft-ietf-rap-session-auth-02.txt).
>> >>
>> >> Marco Schneider
>> >>
>> >> -----Original Message-----
>> >> From: Roy, Radhika R, ALASO [mailto:rrroy@att.com]
>> >> Sent: Friday, January 18, 2002 9:18 AM
>> >> To: Schneider, Marco; Gary Kenward; Loughney John (NRC/Helsinki);
>> >> brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
>> >> dick.rr.knight@bt.com
>> >> Cc: nsis@ietf.org
>> >> Subject: RE: [NSIS] Two kinds of requirements
>> >>
>> >>
>> >> Defined below [RRR]
>> >>
>> >> -----Original Message-----
>> >> From: Schneider, Marco [mailto:schneider@tri.sbc.com]
>> >> Sent: Thursday, January 17, 2002 8:47 PM
>> >> To: Roy, Radhika R, ALASO; Gary Kenward; Loughney John (NRC/Helsinki);
>> >> brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
>> >> dick.rr.knight@bt.com
>> >> Cc: nsis@ietf.org
>> >> Subject: RE: [NSIS] Two kinds of requirements
>> >>
>> >>
>> >> Hi Roy,
>> >>
>> >> Can you please define what you mean by "End-to-End Application Layer
>> >> QOS Signaling". Thanks.
>> >>
>> >> [RRR] Suppose an user is initiation a SIP call to another user with
>> >> audio, video, and data. The use needs to express the needs of QOS for
>> >> audio, video, and data to another user.
>> >>
>> >> [RRR] The signaling mechanism that allows to express the QOS
>> >> parameters of audio, video, and data is termed as the "End-to-End
>> >> Application Layer QOS Signaling."
>> >>
>> >> Marco Schneider
>> >>
>> >> _______________________________________________
>> >> 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
>> >>
>> >
>> >
>> >
>> > --------------------------------------
>> > Dr. Marcus Brunner
>> > Network Laboratories
>> > NEC Europe Ltd.
>> >
>> > E-Mail: brunner@ccrle.nec.de
>> > WWW:    http://www.ccrle.nec.de/
>> > personal home page: http://www.brubers.org/marcus
>> >
>> >
>> > _______________________________________________
>> > nsis mailing list
>> > nsis@ietf.org
>> > https://www1.ietf.org/mailman/listinfo/nsis
>> >
>>
>> --------------------------------------
>> Dr. Marcus Brunner
>> Network Laboratories
>> NEC Europe Ltd.
>>
>> E-Mail: brunner@ccrle.nec.de
>> WWW:    http://www.ccrle.nec.de/
>> personal home page: http://www.brubers.org/marcus
>>
>> _______________________________________________
>> nsis mailing list
>> nsis@ietf.org
>> https://www1.ietf.org/mailman/listinfo/nsis
>



--------------------------------------
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  Mon Jan 28 07:34: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 HAA23095
	for <nsis-archive@odin.ietf.org>; Mon, 28 Jan 2002 07:34:24 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id HAA07258
	for nsis-archive@odin.ietf.org; Mon, 28 Jan 2002 07:34:26 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA07233;
	Mon, 28 Jan 2002 07:33:00 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA07203
	for <nsis@optimus.ietf.org>; Mon, 28 Jan 2002 07:32:58 -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 HAA23081
	for <nsis@ietf.org>; Mon, 28 Jan 2002 07:32:55 -0500 (EST)
Received: from esealnt409.al.sw.ericsson.se (ESEALNT409.al.sw.ericsson.se [153.88.251.32])
	by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g0SCWtX4026731
	for <nsis@ietf.org>; Mon, 28 Jan 2002 13:32:55 +0100 (MET)
Received: FROM esealnt746.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Mon Jan 28 13:32:38 2002 +0100
Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <YHLJM9ZM>; Mon, 28 Jan 2002 13:32:55 +0100
Message-ID: <E244E44D6AB85E40AEEF7EAABE3545FA8233CA@enleent104.nl.eu.ericsson.se>
From: "Georgios Karagiannis (ELN)" <Georgios.Karagiannis@eln.ericsson.se>
To: "'brunner@ccrle.nec.de'" <brunner@ccrle.nec.de>
Cc: nsis@ietf.org
Subject: RE: Independence of signalling and data path (was RE: [NSIS] Two	
	kindsof  requirements)
Date: Mon, 28 Jan 2002 13:32: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 Marcus

Please see my comments/remarks in line:

[MB]>> I am not sure, what exactly you mean by 
[MB]>> the "host to proxy" version of the 
[MB]>> protocol, but the main problem lies in mobil 
[MB]>> environments, where I currently see a problem.

Please let me explain how I see the QoS scenario
that you are thinking of by using the QoS framework that 
was proposed by me some time ago.


         NSIS protocol              NSIS protocol       NSIS protocol
         (host - host)               (host - host)      (host - host)
|-----|   (first-part)       |-----|(second-part)|-----|(third-part|-----|
|ehost|<-------------------->|ehost|<----------->|ehost|---------->|ehost|
|-----|                      |-----|             |-----|           |-----|
|     |                      |     |             |     |           |     |
|-----|            |-----|   |-----|             |-----|           |-----|
|eedge|            |eedge|   |eedge|             |eedge|           |eedge|
|-----|            |-----|   |-----|             |-----|           |-----|
|     |            |     |   |     |             |     |           |     |
|-----|   |----|   |-----|   |-----|   |----|    |-----|   |----|  |-----|
|ehop |   |ehop|   |ehop |   |ehop |   |ehop|    |ehop |   |ehop|  |ehop |
|-----|   |----|   |-----|   |-----|   |----|    |-----|   |----|  |-----|
end-host1 interior   edge      BB1      interior   BB2    interior end-host2
         w/in domain                   w/in domain       w/in domain

   ehost = everyhost
   eedge = everyedge
   ehop  = everyhop

NSIS protocol (host - host): is a NSIS protocol version
that is:
  *  started at a host (could be an-end host or a 
     Bandwidth Broker (BB))
  * terminated at a host (could be an-end host or a 
     Bandwidth Broker (BB))

In the above figure the end to end QoS signaling solution 
is provided by three NSIS protocol parts.
  * the first-part is started at end-host1 and is 
    terminated at BB1 (Note that the end-host1 must know the 
    address of BB1); 
  * the second-part is started at BB1 and is terminated 
    at BB2(Note that the BB1 must know the 
    address of BB2);
  * the third part is started at BB2 and is terminated at
    end-host2 (Note that the BB2 must know the 
    address of endhost2);


For this scenario the NSIS protocol decomposition is as follows:

 * A "host" could be an end host or a Bandwidth Broker (BB).
   It can process and use the "everyhost", "everyedge", and "everyhop"
   protocol components. However, in this scenario (that uses BBs), 
   the "everyedge" and "everyhop" components may not be used. 
   Therefore the QoS framework 
   will look as depicted in figure above.

 * An "edge" can be a Diffserv edge, MPLS edge, etc.  It can
   process and use the "everyedge", and "everyhop" protocol
   components. However, in this scenario (that uses BBs), 
   the "everyedge" and "everyhop" components may not be 
   used (or checked), since they will 
   be  not set (e.g., empty). 
   The "everyhost" protocol component is not
   processed (used or checked) but is carried onward.

 * An "interior within domain" can be any router within
   a domain.  It can process and use only the "everyhop"
   protocol component. However, in this scenario 
   (that uses BBs), "everyhop" component may not be 
   used (or checked), since it will 
   be not set (e.g., empty). The "everyhost" and "everyedge"
   protocol components are not processed (used or checked)
   but are carried onward. 


PLEASE NOTE that in my opinion, this scenario is only useful 
when you will consider that:
* BB's or QoS controllers are used;
* the end-host should know the address of the first hop Bandwidth Broker;
* the BBs should be aware (know) the addresses of neighboring BBs;
* BB's or QoS controllers should be able to relate 
  the QoS signaling to the data path;


In general the above considerations are very difficult to 
fulfill. Please note that we need a NSIS protocol that can 
be applied in general. Of course your
scenario, but other types as well will be included.  

I think that the example explained above 
is providing a possible solution to your problem. 

[MB] What is in your opinion the problem of requiring 
[MB] independent signalling and data pathes?

First of all: I will just try to explain what this independence means.
It means that the NSIS signaling messages my follow a different path 
then the user data packets (associated to these NSIS signaling 
messages). 

Second:  the problem of this independence is that the NSIS protocol
in most of the cases is useless. 
Thus, for example, if the NSIS signaling messages will 
signal QoS information to an edge node, and the user 
data packets (associated to this QoS information)
will not pass through the same edge node, then 
the NSIS protocol in most of the cases is useless. 

Please note that when the signaling path is independent than 
the user data path, then the NSIS protocol will only be useful 
when:

* BB's or QoS controllers are used;
* the end-host should know the address of the first hop Bandwidth Broker;
* the BBs should be aware (know) the addresses of neighbouring BBs;
* BB's or QoS controllers should be able to relate 
  the QoS signalling to the data path;


Solution on how signaling messages and user data 
packets can follow the same path:
The signaling messages will
follow the same path as the user data packets when for example,
the IP destination address of the signaling messages is the same 
as the IP destination address of the user data packets.
Typical IP routing protocols will route both signaling messages
and user data packets that have the same IP destination address through
the same path. RSVPv1 uses something similar (on the PATH messages 
and user data packets having the same flow ID);



Best regards,
Georgios


-----Original Message-----
From: Marcus Brunner [mailto:brunner@ccrle.nec.de]
Sent: maandag 28 januari 2002 12:04
To: Georgios Karagiannis (ELN); 'fu@ee.tu-berlin.de'
Cc: nsis@ietf.org
Subject: RE: Independence of signalling and data path (was RE: [NSIS]
Two kindsof requirements)


Georgios,

I am not sure, what exactly you mean by the "host to proxy" version of the 
protocol, but the main problem lies in mobil environments, where I 
currently see a problem.

What is in your opinion the problem of requiring independent signalling and 
data pathes?

Marcus

--On Monday, January 28, 2002 9:52 AM +0100 "Georgios Karagiannis (ELN)" 
<Georgios.Karagiannis@eln.ericsson.se> wrote:

> Hi Xiaoming and Marcus
>
> If you would like to have a QoS communication between a
> QoS initiator and a QoS controller you could
> then use the "host to proxy" version of the NSIS protocol.
>
> You could then accomplish exactly the same functionality
> without requiring that the signaling path is independent from
> the data path.
>
> Best regards,
> Georgios
>
> -----Original Message-----
> From: Xiaoming Fu [mailto:fu@ee.tu-berlin.de]
> Sent: vrijdag 25 januari 2002 19:40
> To: brunner@ccrle.nec.de
> Cc: Georgios Karagiannis (ELN); nsis@ietf.org
> Subject: Re: Independence of signalling and data path (was RE: [NSIS]
> Two kindsof requirements)
>
>
> Marcus,
>
> Marcus Brunner wrote:
>>
>> I you want to see SIP in you can sure. But that was our intention.
>>
>> I  personally think, that the signalling path should not be bound to the
>> data path. Whether you need to know the location of the QoS controller
>> heavility depends on the specific protocols defined (and might be regard
>> implementation dependent)
>
> Yeap. e.g., when BB is used signaling may be needed between BBs of
> adjacent  QoS domains.	
>
> Xiaoming
>
>>
>> Marcus
>>
>> --On Friday, January 25, 2002 5:04 PM +0100 "Georgios Karagiannis (ELN)"
>> <Georgios.Karagiannis@eln.ericsson.se> wrote:
>>
>> > Hi Marcus
>> >
>> > yes, but from what I understood from your draft
>> > you assume that the QoS initiator will have to know the
>> > location of the QoS controller and that the
>> > signaling path may follow a different path than
>> > the user data. It seems SIP to me.
>> >
>> > Best Regards,
>> > Georgios
>> >
>> >
>> > -----Original Message-----
>> > From: Marcus Brunner [mailto:brunner@ccrle.nec.de]
>> > Sent: vrijdag 25 januari 2002 17:09
>> > To: Georgios Karagiannis (ELN); 'Schneider, Marco'
>> > Cc: nsis@ietf.org
>> > Subject: RE: [NSIS] Two kinds of requirements
>> >
>> >
>> > Looks nice for fixed network. However, as soon as mobility is involved
>> > it gets more difficult. That was the reason that in our framewrok we
>> > talk about QoS initiator and QoS controller, instead of teh
>> > componenets where the componenets are sitting (which we find not
>> > really relevant)
>> >
>> > Marcus
>> >
>> > --On Tuesday, January 22, 2002 10:39 AM +0100 "Georgios Karagiannis
>> > (ELN)"  <Georgios.Karagiannis@eln.ericsson.se> wrote:
>> >
>> >> Hi Marco
>> >>
>> >> The possible NSIS protocol components that can be
>> >> used on the different NSIS protocol types are the following:
>> >>
>> >>  * used components in "end host to end host" NSIS scenario:
>> >>       [everyhost], [everyedge], [everyhop]
>> >>
>> >>  * used components in "end host to proxy" NSIS scenario:
>> >>       [everyhost], [everyedge], [everyhop]
>> >>
>> >>  * used components in "end host to edge" NSIS scenario:
>> >>       [everyedge], [everyhop]
>> >>
>> >>  * used components in "edge to edge" NSIS scenario:
>> >>       [everyedge], [everyhop]
>> >>
>> >> Regarding the priority, we should decide it after the requirements,
>> >> architecture and framework drafts are done!
>> >>
>> >> Best regards,
>> >> Georgios
>> >>
>> >> -----Original Message-----
>> >> From: Schneider, Marco [mailto:schneider@tri.sbc.com]
>> >> Sent: dinsdag 22 januari 2002 1:03
>> >> To: 'Georgios Karagiannis (ELN)'; 'dick.rr.knight@bt.com'
>> >> Cc: nsis@ietf.org
>> >> Subject: RE: [NSIS] Two kinds of requirements
>> >>
>> >>
>> >> Hi Georgios, All
>> >>
>> >> If by x -- y you mean a protocol that runs directly between x and y
>> >> (e.g. end host -- end host, end host -- proxy...) then strictly
>> >> speaking we are discussing four  functionally distinct interfaces and
>> >> thus four functionally distinct protocols(possibly three if we group
>> >> end host -- proxy and  end host -- edge together). In my opinion:
>> >> First we need to decide which of these interfaces are in scope.
>> >> Second we need to decide which one(s) we will address first. Third we
>> >> need to define the requirements for each for each of the interfaces
>> >> independently.
>> >>
>> >> With respect to scope and priority, I think we need to address in
>> >> order: 1) end host -- edge/proxy
>> >> 2) domain edge -- domain edge
>> >>
>> >>
>> >> Marco
>> >>
>> >>
>> >> -----Original Message-----
>> >> From: Georgios Karagiannis (ELN)
>> >> [mailto:Georgios.Karagiannis@eln.ericsson.se]
>> >> Sent: Monday, January 21, 2002 4:30 AM
>> >> To: 'dick.rr.knight@bt.com'
>> >> Cc: nsis@ietf.org
>> >> Subject: RE: [NSIS] Two kinds of requirements
>> >>
>> >>
>> >>
>> >> Hi Dick
>> >>
>> >> Please see my comment in line:
>> >> [DK]>> I do agree that it need not be processed on a per hop basis as
>> >> it can [DK]>> transverse a domain with a single QoS mechanism. That
>> >> mechanism, be it
>> >> [DK]>> diffserv or intserv, PNNI, RSVP, or even over-provisioning,
>> >> takes care of
>> >> [DK]>> the policing and the "path" establishment within the domain.
>> >>
>> >> Please note that at the moment there are scenarios that will need to
>> >> process the [everyhop] component. Some of these scenarios are the
>> >> Radio Access
>> >> Network and Mobile IP,..
>> >> Therefore, the [everyhop] component should be supported by the NSIS
>> >> protocol.
>> >> However a "host" or a "edge" should be able to activated or not.
>> >>
>> >> Furthermore, in my opinion the NSIS protocol should be:
>> >> end host - end host: the NSIS protocol is terminated at end hosts;
>> >> end host - proxy: the NSIS protocol is terminated at end host and
>> >> proxy; end host - edge: the NSIS protocol is terminated at end end
>> >> host and edge; edge - edge: the NSIS protocol is terminated at egdes
>> >> of one/multiple domains;
>> >>
>> >>
>> >> Best regards,
>> >> Georgios
>> >>
>> >>
>> >> -----Original Message-----
>> >> From: Schneider, Marco [mailto:schneider@tri.sbc.com]
>> >> Sent: 18 January 2002 20:10
>> >> To: 'Roy, Radhika R, ALASO'; Gary Kenward; Loughney John
>> >> (NRC/Helsinki); brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
>> >> dick.rr.knight@bt.com
>> >> Cc: nsis@ietf.org
>> >> Subject: RE: [NSIS] Two kinds of requirements
>> >>
>> >>
>> >> Hi Roy,
>> >>
>> >> Below is the original text from your reponse to Gary Kenward.
>> >> Hopefully the context is clear.
>> >>
>> >> "[Roy, Radhika R, ALARC]  I would say that it is the QOS needs of the
>> >> application (e.g., SIP-based VoIP) that the user likes to express (as
>> >> opposed to "service"). Similarly, instead of network services, we
>> >> would say network layer QOS services (e.g., RSVP, DiffServ, MPLS). We
>> >> would develop the end-to-end (application layer) QOS signaling
>> >> protocol (say, NSIS QOS). Now, there needs to have some kinds of
>> >> standards how NSIS QOS will be mapped over RSVP, DiffServ, MPLS, etc."
>> >>
>> >> So by End-to-End you mean between directly between two "users". This
>> >> is session level signaling and I don't believe the signaling part is
>> >> within the scope of this working group. An application level QOS
>> >> specification may be.
>> >>
>> >> After a session level agreement on QOS, the host/client/customer will
>> >> need to signal an actual reservation request to the network for the
>> >> necessary QOS agreed to at the session level. This is the protocol
>> >> that we need to work on.
>> >>
>> >> This approach is discussed in the SIP draft "SIP Extensions for Media
>> >> Authorization" (draft-ietf-sip-call-auth-03.txt) and the RAP draft
>> >> "Framework for session set-up with media authorization"
>> >> (draft-ietf-rap-session-auth-02.txt).
>> >>
>> >> Marco Schneider
>> >>
>> >> -----Original Message-----
>> >> From: Roy, Radhika R, ALASO [mailto:rrroy@att.com]
>> >> Sent: Friday, January 18, 2002 9:18 AM
>> >> To: Schneider, Marco; Gary Kenward; Loughney John (NRC/Helsinki);
>> >> brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
>> >> dick.rr.knight@bt.com
>> >> Cc: nsis@ietf.org
>> >> Subject: RE: [NSIS] Two kinds of requirements
>> >>
>> >>
>> >> Defined below [RRR]
>> >>
>> >> -----Original Message-----
>> >> From: Schneider, Marco [mailto:schneider@tri.sbc.com]
>> >> Sent: Thursday, January 17, 2002 8:47 PM
>> >> To: Roy, Radhika R, ALASO; Gary Kenward; Loughney John (NRC/Helsinki);
>> >> brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
>> >> dick.rr.knight@bt.com
>> >> Cc: nsis@ietf.org
>> >> Subject: RE: [NSIS] Two kinds of requirements
>> >>
>> >>
>> >> Hi Roy,
>> >>
>> >> Can you please define what you mean by "End-to-End Application Layer
>> >> QOS Signaling". Thanks.
>> >>
>> >> [RRR] Suppose an user is initiation a SIP call to another user with
>> >> audio, video, and data. The use needs to express the needs of QOS for
>> >> audio, video, and data to another user.
>> >>
>> >> [RRR] The signaling mechanism that allows to express the QOS
>> >> parameters of audio, video, and data is termed as the "End-to-End
>> >> Application Layer QOS Signaling."
>> >>
>> >> Marco Schneider
>> >>
>> >> _______________________________________________
>> >> 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
>> >>
>> >
>> >
>> >
>> > --------------------------------------
>> > Dr. Marcus Brunner
>> > Network Laboratories
>> > NEC Europe Ltd.
>> >
>> > E-Mail: brunner@ccrle.nec.de
>> > WWW:    http://www.ccrle.nec.de/
>> > personal home page: http://www.brubers.org/marcus
>> >
>> >
>> > _______________________________________________
>> > nsis mailing list
>> > nsis@ietf.org
>> > https://www1.ietf.org/mailman/listinfo/nsis
>> >
>>
>> --------------------------------------
>> Dr. Marcus Brunner
>> Network Laboratories
>> NEC Europe Ltd.
>>
>> E-Mail: brunner@ccrle.nec.de
>> WWW:    http://www.ccrle.nec.de/
>> personal home page: http://www.brubers.org/marcus
>>
>> _______________________________________________
>> nsis mailing list
>> nsis@ietf.org
>> https://www1.ietf.org/mailman/listinfo/nsis
>



--------------------------------------
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  Mon Jan 28 08:35:26 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24624
	for <nsis-archive@odin.ietf.org>; Mon, 28 Jan 2002 08:35:26 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id IAA09882
	for nsis-archive@odin.ietf.org; Mon, 28 Jan 2002 08:35: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 IAA09325;
	Mon, 28 Jan 2002 08: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 IAA09256
	for <nsis@optimus.ietf.org>; Mon, 28 Jan 2002 08:25:50 -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 IAA24392
	for <nsis@ietf.org>; Mon, 28 Jan 2002 08:25:46 -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 g0SDPgj40710;
	Mon, 28 Jan 2002 14:25:42 +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 761C8C05B; Mon, 28 Jan 2002 14:25:01 +0100 (CET)
Date: Mon, 28 Jan 2002 14:36:55 +0100
From: Marcus Brunner <brunner@ccrle.nec.de>
Reply-To: brunner@ccrle.nec.de
To: "Georgios Karagiannis (ELN)" <Georgios.Karagiannis@eln.ericsson.se>
Cc: nsis@ietf.org
Message-ID: <21941620.1012228615@[192.168.102.79]>
In-Reply-To: <E244E44D6AB85E40AEEF7EAABE3545FA8233CA@enleent104.nl.eu.ericsson.se>
References:  <E244E44D6AB85E40AEEF7EAABE3545FA8233CA@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: Independence of signalling and data path (was RE: [NSIS]
 Two		kindsof  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,

So, I think you much in line with that req. The protocol from host to BB 
does not depend on the data path completly. What the constrain for the 
communication are is a different question. And whether, the protocol work 
between ehost, eedge, ehop, all of them can be controllers and initiators 
on the other side. So they do not require data and signalling on the same 
path.

Marcus

--On Monday, January 28, 2002 1:32 PM +0100 "Georgios Karagiannis (ELN)" 
<Georgios.Karagiannis@eln.ericsson.se> wrote:

> Hi Marcus
>
> Please see my comments/remarks in line:
>
> [MB]>> I am not sure, what exactly you mean by
> [MB]>> the "host to proxy" version of the
> [MB]>> protocol, but the main problem lies in mobil
> [MB]>> environments, where I currently see a problem.
>
> Please let me explain how I see the QoS scenario
> that you are thinking of by using the QoS framework that
> was proposed by me some time ago.
>
>
>          NSIS protocol              NSIS protocol       NSIS protocol
>          (host - host)               (host - host)      (host - host)
>| -----|   (first-part)       |-----|(second-part)|-----|(third-part|-----|
>| ehost|<-------------------->|ehost|<----------->|ehost|---------->|ehost|
>| -----|                      |-----|             |-----|           |-----|
>|     |                      |     |             |     |           |     |
>| -----|            |-----|   |-----|             |-----|           |-----|
>| eedge|            |eedge|   |eedge|             |eedge|           |eedge|
>| -----|            |-----|   |-----|             |-----|           |-----|
>|     |            |     |   |     |             |     |           |     |
>| -----|   |----|   |-----|   |-----|   |----|    |-----|   |----|  |-----|
>| ehop |   |ehop|   |ehop |   |ehop |   |ehop|    |ehop |   |ehop|  |ehop |
>| -----|   |----|   |-----|   |-----|   |----|    |-----|   |----|  |-----|
> end-host1 interior   edge      BB1      interior   BB2    interior
> end-host2          w/in domain                   w/in domain       w/in
> domain
>
>    ehost = everyhost
>    eedge = everyedge
>    ehop  = everyhop
>
> NSIS protocol (host - host): is a NSIS protocol version
> that is:
>   *  started at a host (could be an-end host or a
>      Bandwidth Broker (BB))
>   * terminated at a host (could be an-end host or a
>      Bandwidth Broker (BB))
>
> In the above figure the end to end QoS signaling solution
> is provided by three NSIS protocol parts.
>   * the first-part is started at end-host1 and is
>     terminated at BB1 (Note that the end-host1 must know the
>     address of BB1);
>   * the second-part is started at BB1 and is terminated
>     at BB2(Note that the BB1 must know the
>     address of BB2);
>   * the third part is started at BB2 and is terminated at
>     end-host2 (Note that the BB2 must know the
>     address of endhost2);
>
>
> For this scenario the NSIS protocol decomposition is as follows:
>
>  * A "host" could be an end host or a Bandwidth Broker (BB).
>    It can process and use the "everyhost", "everyedge", and "everyhop"
>    protocol components. However, in this scenario (that uses BBs),
>    the "everyedge" and "everyhop" components may not be used.
>    Therefore the QoS framework
>    will look as depicted in figure above.
>
>  * An "edge" can be a Diffserv edge, MPLS edge, etc.  It can
>    process and use the "everyedge", and "everyhop" protocol
>    components. However, in this scenario (that uses BBs),
>    the "everyedge" and "everyhop" components may not be
>    used (or checked), since they will
>    be  not set (e.g., empty).
>    The "everyhost" protocol component is not
>    processed (used or checked) but is carried onward.
>
>  * An "interior within domain" can be any router within
>    a domain.  It can process and use only the "everyhop"
>    protocol component. However, in this scenario
>    (that uses BBs), "everyhop" component may not be
>    used (or checked), since it will
>    be not set (e.g., empty). The "everyhost" and "everyedge"
>    protocol components are not processed (used or checked)
>    but are carried onward.
>
>
> PLEASE NOTE that in my opinion, this scenario is only useful
> when you will consider that:
> * BB's or QoS controllers are used;
> * the end-host should know the address of the first hop Bandwidth Broker;
> * the BBs should be aware (know) the addresses of neighboring BBs;
> * BB's or QoS controllers should be able to relate
>   the QoS signaling to the data path;
>
>
> In general the above considerations are very difficult to
> fulfill. Please note that we need a NSIS protocol that can
> be applied in general. Of course your
> scenario, but other types as well will be included.
>
> I think that the example explained above
> is providing a possible solution to your problem.
>
> [MB] What is in your opinion the problem of requiring
> [MB] independent signalling and data pathes?
>
> First of all: I will just try to explain what this independence means.
> It means that the NSIS signaling messages my follow a different path
> then the user data packets (associated to these NSIS signaling
> messages).
>
> Second:  the problem of this independence is that the NSIS protocol
> in most of the cases is useless.
> Thus, for example, if the NSIS signaling messages will
> signal QoS information to an edge node, and the user
> data packets (associated to this QoS information)
> will not pass through the same edge node, then
> the NSIS protocol in most of the cases is useless.
>
> Please note that when the signaling path is independent than
> the user data path, then the NSIS protocol will only be useful
> when:
>
> * BB's or QoS controllers are used;
> * the end-host should know the address of the first hop Bandwidth Broker;
> * the BBs should be aware (know) the addresses of neighbouring BBs;
> * BB's or QoS controllers should be able to relate
>   the QoS signalling to the data path;
>
>
> Solution on how signaling messages and user data
> packets can follow the same path:
> The signaling messages will
> follow the same path as the user data packets when for example,
> the IP destination address of the signaling messages is the same
> as the IP destination address of the user data packets.
> Typical IP routing protocols will route both signaling messages
> and user data packets that have the same IP destination address through
> the same path. RSVPv1 uses something similar (on the PATH messages
> and user data packets having the same flow ID);
>
>
>
> Best regards,
> Georgios
>
>
> -----Original Message-----
> From: Marcus Brunner [mailto:brunner@ccrle.nec.de]
> Sent: maandag 28 januari 2002 12:04
> To: Georgios Karagiannis (ELN); 'fu@ee.tu-berlin.de'
> Cc: nsis@ietf.org
> Subject: RE: Independence of signalling and data path (was RE: [NSIS]
> Two kindsof requirements)
>
>
> Georgios,
>
> I am not sure, what exactly you mean by the "host to proxy" version of
> the  protocol, but the main problem lies in mobil environments, where I
> currently see a problem.
>
> What is in your opinion the problem of requiring independent signalling
> and  data pathes?
>
> Marcus
>
> --On Monday, January 28, 2002 9:52 AM +0100 "Georgios Karagiannis (ELN)"
> <Georgios.Karagiannis@eln.ericsson.se> wrote:
>
>> Hi Xiaoming and Marcus
>>
>> If you would like to have a QoS communication between a
>> QoS initiator and a QoS controller you could
>> then use the "host to proxy" version of the NSIS protocol.
>>
>> You could then accomplish exactly the same functionality
>> without requiring that the signaling path is independent from
>> the data path.
>>
>> Best regards,
>> Georgios
>>
>> -----Original Message-----
>> From: Xiaoming Fu [mailto:fu@ee.tu-berlin.de]
>> Sent: vrijdag 25 januari 2002 19:40
>> To: brunner@ccrle.nec.de
>> Cc: Georgios Karagiannis (ELN); nsis@ietf.org
>> Subject: Re: Independence of signalling and data path (was RE: [NSIS]
>> Two kindsof requirements)
>>
>>
>> Marcus,
>>
>> Marcus Brunner wrote:
>>>
>>> I you want to see SIP in you can sure. But that was our intention.
>>>
>>> I  personally think, that the signalling path should not be bound to the
>>> data path. Whether you need to know the location of the QoS controller
>>> heavility depends on the specific protocols defined (and might be regard
>>> implementation dependent)
>>
>> Yeap. e.g., when BB is used signaling may be needed between BBs of
>> adjacent  QoS domains.	
>>
>> Xiaoming
>>
>>>
>>> Marcus
>>>
>>> --On Friday, January 25, 2002 5:04 PM +0100 "Georgios Karagiannis (ELN)"
>>> <Georgios.Karagiannis@eln.ericsson.se> wrote:
>>>
>>> > Hi Marcus
>>> >
>>> > yes, but from what I understood from your draft
>>> > you assume that the QoS initiator will have to know the
>>> > location of the QoS controller and that the
>>> > signaling path may follow a different path than
>>> > the user data. It seems SIP to me.
>>> >
>>> > Best Regards,
>>> > Georgios
>>> >
>>> >
>>> > -----Original Message-----
>>> > From: Marcus Brunner [mailto:brunner@ccrle.nec.de]
>>> > Sent: vrijdag 25 januari 2002 17:09
>>> > To: Georgios Karagiannis (ELN); 'Schneider, Marco'
>>> > Cc: nsis@ietf.org
>>> > Subject: RE: [NSIS] Two kinds of requirements
>>> >
>>> >
>>> > Looks nice for fixed network. However, as soon as mobility is involved
>>> > it gets more difficult. That was the reason that in our framewrok we
>>> > talk about QoS initiator and QoS controller, instead of teh
>>> > componenets where the componenets are sitting (which we find not
>>> > really relevant)
>>> >
>>> > Marcus
>>> >
>>> > --On Tuesday, January 22, 2002 10:39 AM +0100 "Georgios Karagiannis
>>> > (ELN)"  <Georgios.Karagiannis@eln.ericsson.se> wrote:
>>> >
>>> >> Hi Marco
>>> >>
>>> >> The possible NSIS protocol components that can be
>>> >> used on the different NSIS protocol types are the following:
>>> >>
>>> >>  * used components in "end host to end host" NSIS scenario:
>>> >>       [everyhost], [everyedge], [everyhop]
>>> >>
>>> >>  * used components in "end host to proxy" NSIS scenario:
>>> >>       [everyhost], [everyedge], [everyhop]
>>> >>
>>> >>  * used components in "end host to edge" NSIS scenario:
>>> >>       [everyedge], [everyhop]
>>> >>
>>> >>  * used components in "edge to edge" NSIS scenario:
>>> >>       [everyedge], [everyhop]
>>> >>
>>> >> Regarding the priority, we should decide it after the requirements,
>>> >> architecture and framework drafts are done!
>>> >>
>>> >> Best regards,
>>> >> Georgios
>>> >>
>>> >> -----Original Message-----
>>> >> From: Schneider, Marco [mailto:schneider@tri.sbc.com]
>>> >> Sent: dinsdag 22 januari 2002 1:03
>>> >> To: 'Georgios Karagiannis (ELN)'; 'dick.rr.knight@bt.com'
>>> >> Cc: nsis@ietf.org
>>> >> Subject: RE: [NSIS] Two kinds of requirements
>>> >>
>>> >>
>>> >> Hi Georgios, All
>>> >>
>>> >> If by x -- y you mean a protocol that runs directly between x and y
>>> >> (e.g. end host -- end host, end host -- proxy...) then strictly
>>> >> speaking we are discussing four  functionally distinct interfaces and
>>> >> thus four functionally distinct protocols(possibly three if we group
>>> >> end host -- proxy and  end host -- edge together). In my opinion:
>>> >> First we need to decide which of these interfaces are in scope.
>>> >> Second we need to decide which one(s) we will address first. Third we
>>> >> need to define the requirements for each for each of the interfaces
>>> >> independently.
>>> >>
>>> >> With respect to scope and priority, I think we need to address in
>>> >> order: 1) end host -- edge/proxy
>>> >> 2) domain edge -- domain edge
>>> >>
>>> >>
>>> >> Marco
>>> >>
>>> >>
>>> >> -----Original Message-----
>>> >> From: Georgios Karagiannis (ELN)
>>> >> [mailto:Georgios.Karagiannis@eln.ericsson.se]
>>> >> Sent: Monday, January 21, 2002 4:30 AM
>>> >> To: 'dick.rr.knight@bt.com'
>>> >> Cc: nsis@ietf.org
>>> >> Subject: RE: [NSIS] Two kinds of requirements
>>> >>
>>> >>
>>> >>
>>> >> Hi Dick
>>> >>
>>> >> Please see my comment in line:
>>> >> [DK]>> I do agree that it need not be processed on a per hop basis as
>>> >> it can [DK]>> transverse a domain with a single QoS mechanism. That
>>> >> mechanism, be it
>>> >> [DK]>> diffserv or intserv, PNNI, RSVP, or even over-provisioning,
>>> >> takes care of
>>> >> [DK]>> the policing and the "path" establishment within the domain.
>>> >>
>>> >> Please note that at the moment there are scenarios that will need to
>>> >> process the [everyhop] component. Some of these scenarios are the
>>> >> Radio Access
>>> >> Network and Mobile IP,..
>>> >> Therefore, the [everyhop] component should be supported by the NSIS
>>> >> protocol.
>>> >> However a "host" or a "edge" should be able to activated or not.
>>> >>
>>> >> Furthermore, in my opinion the NSIS protocol should be:
>>> >> end host - end host: the NSIS protocol is terminated at end hosts;
>>> >> end host - proxy: the NSIS protocol is terminated at end host and
>>> >> proxy; end host - edge: the NSIS protocol is terminated at end end
>>> >> host and edge; edge - edge: the NSIS protocol is terminated at egdes
>>> >> of one/multiple domains;
>>> >>
>>> >>
>>> >> Best regards,
>>> >> Georgios
>>> >>
>>> >>
>>> >> -----Original Message-----
>>> >> From: Schneider, Marco [mailto:schneider@tri.sbc.com]
>>> >> Sent: 18 January 2002 20:10
>>> >> To: 'Roy, Radhika R, ALASO'; Gary Kenward; Loughney John
>>> >> (NRC/Helsinki); brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
>>> >> dick.rr.knight@bt.com
>>> >> Cc: nsis@ietf.org
>>> >> Subject: RE: [NSIS] Two kinds of requirements
>>> >>
>>> >>
>>> >> Hi Roy,
>>> >>
>>> >> Below is the original text from your reponse to Gary Kenward.
>>> >> Hopefully the context is clear.
>>> >>
>>> >> "[Roy, Radhika R, ALARC]  I would say that it is the QOS needs of the
>>> >> application (e.g., SIP-based VoIP) that the user likes to express (as
>>> >> opposed to "service"). Similarly, instead of network services, we
>>> >> would say network layer QOS services (e.g., RSVP, DiffServ, MPLS). We
>>> >> would develop the end-to-end (application layer) QOS signaling
>>> >> protocol (say, NSIS QOS). Now, there needs to have some kinds of
>>> >> standards how NSIS QOS will be mapped over RSVP, DiffServ, MPLS,
>>> >> etc."
>>> >>
>>> >> So by End-to-End you mean between directly between two "users". This
>>> >> is session level signaling and I don't believe the signaling part is
>>> >> within the scope of this working group. An application level QOS
>>> >> specification may be.
>>> >>
>>> >> After a session level agreement on QOS, the host/client/customer will
>>> >> need to signal an actual reservation request to the network for the
>>> >> necessary QOS agreed to at the session level. This is the protocol
>>> >> that we need to work on.
>>> >>
>>> >> This approach is discussed in the SIP draft "SIP Extensions for Media
>>> >> Authorization" (draft-ietf-sip-call-auth-03.txt) and the RAP draft
>>> >> "Framework for session set-up with media authorization"
>>> >> (draft-ietf-rap-session-auth-02.txt).
>>> >>
>>> >> Marco Schneider
>>> >>
>>> >> -----Original Message-----
>>> >> From: Roy, Radhika R, ALASO [mailto:rrroy@att.com]
>>> >> Sent: Friday, January 18, 2002 9:18 AM
>>> >> To: Schneider, Marco; Gary Kenward; Loughney John (NRC/Helsinki);
>>> >> brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
>>> >> dick.rr.knight@bt.com
>>> >> Cc: nsis@ietf.org
>>> >> Subject: RE: [NSIS] Two kinds of requirements
>>> >>
>>> >>
>>> >> Defined below [RRR]
>>> >>
>>> >> -----Original Message-----
>>> >> From: Schneider, Marco [mailto:schneider@tri.sbc.com]
>>> >> Sent: Thursday, January 17, 2002 8:47 PM
>>> >> To: Roy, Radhika R, ALASO; Gary Kenward; Loughney John
>>> >> (NRC/Helsinki); brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
>>> >> dick.rr.knight@bt.com
>>> >> Cc: nsis@ietf.org
>>> >> Subject: RE: [NSIS] Two kinds of requirements
>>> >>
>>> >>
>>> >> Hi Roy,
>>> >>
>>> >> Can you please define what you mean by "End-to-End Application Layer
>>> >> QOS Signaling". Thanks.
>>> >>
>>> >> [RRR] Suppose an user is initiation a SIP call to another user with
>>> >> audio, video, and data. The use needs to express the needs of QOS for
>>> >> audio, video, and data to another user.
>>> >>
>>> >> [RRR] The signaling mechanism that allows to express the QOS
>>> >> parameters of audio, video, and data is termed as the "End-to-End
>>> >> Application Layer QOS Signaling."
>>> >>
>>> >> Marco Schneider
>>> >>
>>> >> _______________________________________________
>>> >> 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
>>> >>
>>> >
>>> >
>>> >
>>> > --------------------------------------
>>> > Dr. Marcus Brunner
>>> > Network Laboratories
>>> > NEC Europe Ltd.
>>> >
>>> > E-Mail: brunner@ccrle.nec.de
>>> > WWW:    http://www.ccrle.nec.de/
>>> > personal home page: http://www.brubers.org/marcus
>>> >
>>> >
>>> > _______________________________________________
>>> > nsis mailing list
>>> > nsis@ietf.org
>>> > https://www1.ietf.org/mailman/listinfo/nsis
>>> >
>>>
>>> --------------------------------------
>>> Dr. Marcus Brunner
>>> Network Laboratories
>>> NEC Europe Ltd.
>>>
>>> E-Mail: brunner@ccrle.nec.de
>>> WWW:    http://www.ccrle.nec.de/
>>> personal home page: http://www.brubers.org/marcus
>>>
>>> _______________________________________________
>>> nsis mailing list
>>> nsis@ietf.org
>>> https://www1.ietf.org/mailman/listinfo/nsis
>>
>
>
>
> --------------------------------------
> Dr. Marcus Brunner
> Network Laboratories
> NEC Europe Ltd.
>
> E-Mail: brunner@ccrle.nec.de
> WWW:    http://www.ccrle.nec.de/
> personal home page: http://www.brubers.org/marcus
>



--------------------------------------
Dr. Marcus Brunner
Network Laboratories
NEC Europe Ltd.

E-Mail: brunner@ccrle.nec.de
WWW:    http://www.ccrle.nec.de/
personal home page: http://www.brubers.org/marcus



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



From daemon@optimus.ietf.org  Mon Jan 28 08:48: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 IAA25326
	for <nsis-archive@odin.ietf.org>; Mon, 28 Jan 2002 08:48:07 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id IAA10505
	for nsis-archive@odin.ietf.org; Mon, 28 Jan 2002 08:47: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 IAA10406;
	Mon, 28 Jan 2002 08:45: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 IAA10371
	for <nsis@optimus.ietf.org>; Mon, 28 Jan 2002 08:45: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 IAA25104
	for <nsis@ietf.org>; Mon, 28 Jan 2002 08:45:11 -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 g0SDjDX4018971
	for <nsis@ietf.org>; Mon, 28 Jan 2002 14:45:13 +0100 (MET)
Received: FROM esealnt747.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Mon Jan 28 14:45:12 2002 +0100
Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <YHKTMF7L>; Mon, 28 Jan 2002 14:44:54 +0100
Message-ID: <E244E44D6AB85E40AEEF7EAABE3545FA8233CB@enleent104.nl.eu.ericsson.se>
From: "Georgios Karagiannis (ELN)" <Georgios.Karagiannis@eln.ericsson.se>
To: "'brunner@ccrle.nec.de'" <brunner@ccrle.nec.de>
Cc: nsis@ietf.org
Subject: RE: Independence of signalling and data path (was RE: [NSIS] Two	
		kindsof  requirements)
Date: Mon, 28 Jan 2002 14:45: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 Marcus


[MB]>> So, I think you much in line with that req. The protocol 
[MB]>> from host to BB does not depend on the data path 
[MB}>> completly. What the constrain for the 
[MB]>> communication are is a different question. 

I will repeat what was already said in my previous e-mail:

This is only true when the following CONSIDEARTIONS are 
fulfilled: 

* BB's or QoS controllers are used;
* the end-host should know the address of the first hop Bandwidth Broker;
* the BBs should be aware (know) the addresses of neighboring BBs;
* BB's or QoS controllers should be able to relate
   the QoS signaling to the data path;


 In GENERAL the above CONSIDERATIONS are very difficult to
 fulfill. Please note that we need a NSIS protocol that can
 be applied for GENERAL cases. Of course YOUR
 SCENARIO, but OTHER TYPES as well will be INCLUDED.

Thus, in GENERAL the path followed by signaling 
messages and the path followed by user data packets (associated
to these signaling messages) MUST BE THE SAME!!


Solution on how signaling messages and user data
packets can follow the same path:
The signaling messages will
follow the same path as the user data packets when for example,
the IP destination address of the signaling messages is the same
as the IP destination address of the user data packets.
Typical IP routing protocols will route both signaling messages
and user data packets that have the same IP destination address through
the same path. RSVPv1 uses something similar (on the PATH messages
and user data packets having the same flow ID);

[MB]>> And whether, the 
[MB]>> protocol work 
[MB]>> between ehost, eedge, ehop, all of them can be controllers 
[MB]>> and initiators 
[MB] on the other side. So they do not require data and signalling 
[MB] on the same path.

What do you mean, would you like to have a NSIS protocol version 
that starts at one hop router and terminates at the next first hop router.
This protocol will be very slow, very complex, and in my opinion 
not useful!


Best regards,
Georgios




-----Original Message-----
From: Marcus Brunner [mailto:brunner@ccrle.nec.de]
Sent: maandag 28 januari 2002 14:37
To: Georgios Karagiannis (ELN)
Cc: nsis@ietf.org
Subject: RE: Independence of signalling and data path (was RE: [NSIS]
Two kindsof requirements)


Georgios,

So, I think you much in line with that req. The protocol from host to BB 
does not depend on the data path completly. What the constrain for the 
communication are is a different question. And whether, the protocol work 
between ehost, eedge, ehop, all of them can be controllers and initiators 
on the other side. So they do not require data and signalling on the same 
path.

Marcus

--On Monday, January 28, 2002 1:32 PM +0100 "Georgios Karagiannis (ELN)" 
<Georgios.Karagiannis@eln.ericsson.se> wrote:

> Hi Marcus
>
> Please see my comments/remarks in line:
>
> [MB]>> I am not sure, what exactly you mean by
> [MB]>> the "host to proxy" version of the
> [MB]>> protocol, but the main problem lies in mobil
> [MB]>> environments, where I currently see a problem.
>
> Please let me explain how I see the QoS scenario
> that you are thinking of by using the QoS framework that
> was proposed by me some time ago.
>
>
>          NSIS protocol              NSIS protocol       NSIS protocol
>          (host - host)               (host - host)      (host - host)
>| -----|   (first-part)       |-----|(second-part)|-----|(third-part|-----|
>| ehost|<-------------------->|ehost|<----------->|ehost|---------->|ehost|
>| -----|                      |-----|             |-----|           |-----|
>|     |                      |     |             |     |           |     |
>| -----|            |-----|   |-----|             |-----|           |-----|
>| eedge|            |eedge|   |eedge|             |eedge|           |eedge|
>| -----|            |-----|   |-----|             |-----|           |-----|
>|     |            |     |   |     |             |     |           |     |
>| -----|   |----|   |-----|   |-----|   |----|    |-----|   |----|  |-----|
>| ehop |   |ehop|   |ehop |   |ehop |   |ehop|    |ehop |   |ehop|  |ehop |
>| -----|   |----|   |-----|   |-----|   |----|    |-----|   |----|  |-----|
> end-host1 interior   edge      BB1      interior   BB2    interior
> end-host2          w/in domain                   w/in domain       w/in
> domain
>
>    ehost = everyhost
>    eedge = everyedge
>    ehop  = everyhop
>
> NSIS protocol (host - host): is a NSIS protocol version
> that is:
>   *  started at a host (could be an-end host or a
>      Bandwidth Broker (BB))
>   * terminated at a host (could be an-end host or a
>      Bandwidth Broker (BB))
>
> In the above figure the end to end QoS signaling solution
> is provided by three NSIS protocol parts.
>   * the first-part is started at end-host1 and is
>     terminated at BB1 (Note that the end-host1 must know the
>     address of BB1);
>   * the second-part is started at BB1 and is terminated
>     at BB2(Note that the BB1 must know the
>     address of BB2);
>   * the third part is started at BB2 and is terminated at
>     end-host2 (Note that the BB2 must know the
>     address of endhost2);
>
>
> For this scenario the NSIS protocol decomposition is as follows:
>
>  * A "host" could be an end host or a Bandwidth Broker (BB).
>    It can process and use the "everyhost", "everyedge", and "everyhop"
>    protocol components. However, in this scenario (that uses BBs),
>    the "everyedge" and "everyhop" components may not be used.
>    Therefore the QoS framework
>    will look as depicted in figure above.
>
>  * An "edge" can be a Diffserv edge, MPLS edge, etc.  It can
>    process and use the "everyedge", and "everyhop" protocol
>    components. However, in this scenario (that uses BBs),
>    the "everyedge" and "everyhop" components may not be
>    used (or checked), since they will
>    be  not set (e.g., empty).
>    The "everyhost" protocol component is not
>    processed (used or checked) but is carried onward.
>
>  * An "interior within domain" can be any router within
>    a domain.  It can process and use only the "everyhop"
>    protocol component. However, in this scenario
>    (that uses BBs), "everyhop" component may not be
>    used (or checked), since it will
>    be not set (e.g., empty). The "everyhost" and "everyedge"
>    protocol components are not processed (used or checked)
>    but are carried onward.
>
>
> PLEASE NOTE that in my opinion, this scenario is only useful
> when you will consider that:
> * BB's or QoS controllers are used;
> * the end-host should know the address of the first hop Bandwidth Broker;
> * the BBs should be aware (know) the addresses of neighboring BBs;
> * BB's or QoS controllers should be able to relate
>   the QoS signaling to the data path;
>
>
> In general the above considerations are very difficult to
> fulfill. Please note that we need a NSIS protocol that can
> be applied in general. Of course your
> scenario, but other types as well will be included.
>
> I think that the example explained above
> is providing a possible solution to your problem.
>
> [MB] What is in your opinion the problem of requiring
> [MB] independent signalling and data pathes?
>
> First of all: I will just try to explain what this independence means.
> It means that the NSIS signaling messages my follow a different path
> then the user data packets (associated to these NSIS signaling
> messages).
>
> Second:  the problem of this independence is that the NSIS protocol
> in most of the cases is useless.
> Thus, for example, if the NSIS signaling messages will
> signal QoS information to an edge node, and the user
> data packets (associated to this QoS information)
> will not pass through the same edge node, then
> the NSIS protocol in most of the cases is useless.
>
> Please note that when the signaling path is independent than
> the user data path, then the NSIS protocol will only be useful
> when:
>
> * BB's or QoS controllers are used;
> * the end-host should know the address of the first hop Bandwidth Broker;
> * the BBs should be aware (know) the addresses of neighbouring BBs;
> * BB's or QoS controllers should be able to relate
>   the QoS signalling to the data path;
>
>
> Solution on how signaling messages and user data
> packets can follow the same path:
> The signaling messages will
> follow the same path as the user data packets when for example,
> the IP destination address of the signaling messages is the same
> as the IP destination address of the user data packets.
> Typical IP routing protocols will route both signaling messages
> and user data packets that have the same IP destination address through
> the same path. RSVPv1 uses something similar (on the PATH messages
> and user data packets having the same flow ID);
>
>
>
> Best regards,
> Georgios
>
>
> -----Original Message-----
> From: Marcus Brunner [mailto:brunner@ccrle.nec.de]
> Sent: maandag 28 januari 2002 12:04
> To: Georgios Karagiannis (ELN); 'fu@ee.tu-berlin.de'
> Cc: nsis@ietf.org
> Subject: RE: Independence of signalling and data path (was RE: [NSIS]
> Two kindsof requirements)
>
>
> Georgios,
>
> I am not sure, what exactly you mean by the "host to proxy" version of
> the  protocol, but the main problem lies in mobil environments, where I
> currently see a problem.
>
> What is in your opinion the problem of requiring independent signalling
> and  data pathes?
>
> Marcus
>
> --On Monday, January 28, 2002 9:52 AM +0100 "Georgios Karagiannis (ELN)"
> <Georgios.Karagiannis@eln.ericsson.se> wrote:
>
>> Hi Xiaoming and Marcus
>>
>> If you would like to have a QoS communication between a
>> QoS initiator and a QoS controller you could
>> then use the "host to proxy" version of the NSIS protocol.
>>
>> You could then accomplish exactly the same functionality
>> without requiring that the signaling path is independent from
>> the data path.
>>
>> Best regards,
>> Georgios
>>
>> -----Original Message-----
>> From: Xiaoming Fu [mailto:fu@ee.tu-berlin.de]
>> Sent: vrijdag 25 januari 2002 19:40
>> To: brunner@ccrle.nec.de
>> Cc: Georgios Karagiannis (ELN); nsis@ietf.org
>> Subject: Re: Independence of signalling and data path (was RE: [NSIS]
>> Two kindsof requirements)
>>
>>
>> Marcus,
>>
>> Marcus Brunner wrote:
>>>
>>> I you want to see SIP in you can sure. But that was our intention.
>>>
>>> I  personally think, that the signalling path should not be bound to the
>>> data path. Whether you need to know the location of the QoS controller
>>> heavility depends on the specific protocols defined (and might be regard
>>> implementation dependent)
>>
>> Yeap. e.g., when BB is used signaling may be needed between BBs of
>> adjacent  QoS domains.	
>>
>> Xiaoming
>>
>>>
>>> Marcus
>>>
>>> --On Friday, January 25, 2002 5:04 PM +0100 "Georgios Karagiannis (ELN)"
>>> <Georgios.Karagiannis@eln.ericsson.se> wrote:
>>>
>>> > Hi Marcus
>>> >
>>> > yes, but from what I understood from your draft
>>> > you assume that the QoS initiator will have to know the
>>> > location of the QoS controller and that the
>>> > signaling path may follow a different path than
>>> > the user data. It seems SIP to me.
>>> >
>>> > Best Regards,
>>> > Georgios
>>> >
>>> >
>>> > -----Original Message-----
>>> > From: Marcus Brunner [mailto:brunner@ccrle.nec.de]
>>> > Sent: vrijdag 25 januari 2002 17:09
>>> > To: Georgios Karagiannis (ELN); 'Schneider, Marco'
>>> > Cc: nsis@ietf.org
>>> > Subject: RE: [NSIS] Two kinds of requirements
>>> >
>>> >
>>> > Looks nice for fixed network. However, as soon as mobility is involved
>>> > it gets more difficult. That was the reason that in our framewrok we
>>> > talk about QoS initiator and QoS controller, instead of teh
>>> > componenets where the componenets are sitting (which we find not
>>> > really relevant)
>>> >
>>> > Marcus
>>> >
>>> > --On Tuesday, January 22, 2002 10:39 AM +0100 "Georgios Karagiannis
>>> > (ELN)"  <Georgios.Karagiannis@eln.ericsson.se> wrote:
>>> >
>>> >> Hi Marco
>>> >>
>>> >> The possible NSIS protocol components that can be
>>> >> used on the different NSIS protocol types are the following:
>>> >>
>>> >>  * used components in "end host to end host" NSIS scenario:
>>> >>       [everyhost], [everyedge], [everyhop]
>>> >>
>>> >>  * used components in "end host to proxy" NSIS scenario:
>>> >>       [everyhost], [everyedge], [everyhop]
>>> >>
>>> >>  * used components in "end host to edge" NSIS scenario:
>>> >>       [everyedge], [everyhop]
>>> >>
>>> >>  * used components in "edge to edge" NSIS scenario:
>>> >>       [everyedge], [everyhop]
>>> >>
>>> >> Regarding the priority, we should decide it after the requirements,
>>> >> architecture and framework drafts are done!
>>> >>
>>> >> Best regards,
>>> >> Georgios
>>> >>
>>> >> -----Original Message-----
>>> >> From: Schneider, Marco [mailto:schneider@tri.sbc.com]
>>> >> Sent: dinsdag 22 januari 2002 1:03
>>> >> To: 'Georgios Karagiannis (ELN)'; 'dick.rr.knight@bt.com'
>>> >> Cc: nsis@ietf.org
>>> >> Subject: RE: [NSIS] Two kinds of requirements
>>> >>
>>> >>
>>> >> Hi Georgios, All
>>> >>
>>> >> If by x -- y you mean a protocol that runs directly between x and y
>>> >> (e.g. end host -- end host, end host -- proxy...) then strictly
>>> >> speaking we are discussing four  functionally distinct interfaces and
>>> >> thus four functionally distinct protocols(possibly three if we group
>>> >> end host -- proxy and  end host -- edge together). In my opinion:
>>> >> First we need to decide which of these interfaces are in scope.
>>> >> Second we need to decide which one(s) we will address first. Third we
>>> >> need to define the requirements for each for each of the interfaces
>>> >> independently.
>>> >>
>>> >> With respect to scope and priority, I think we need to address in
>>> >> order: 1) end host -- edge/proxy
>>> >> 2) domain edge -- domain edge
>>> >>
>>> >>
>>> >> Marco
>>> >>
>>> >>
>>> >> -----Original Message-----
>>> >> From: Georgios Karagiannis (ELN)
>>> >> [mailto:Georgios.Karagiannis@eln.ericsson.se]
>>> >> Sent: Monday, January 21, 2002 4:30 AM
>>> >> To: 'dick.rr.knight@bt.com'
>>> >> Cc: nsis@ietf.org
>>> >> Subject: RE: [NSIS] Two kinds of requirements
>>> >>
>>> >>
>>> >>
>>> >> Hi Dick
>>> >>
>>> >> Please see my comment in line:
>>> >> [DK]>> I do agree that it need not be processed on a per hop basis as
>>> >> it can [DK]>> transverse a domain with a single QoS mechanism. That
>>> >> mechanism, be it
>>> >> [DK]>> diffserv or intserv, PNNI, RSVP, or even over-provisioning,
>>> >> takes care of
>>> >> [DK]>> the policing and the "path" establishment within the domain.
>>> >>
>>> >> Please note that at the moment there are scenarios that will need to
>>> >> process the [everyhop] component. Some of these scenarios are the
>>> >> Radio Access
>>> >> Network and Mobile IP,..
>>> >> Therefore, the [everyhop] component should be supported by the NSIS
>>> >> protocol.
>>> >> However a "host" or a "edge" should be able to activated or not.
>>> >>
>>> >> Furthermore, in my opinion the NSIS protocol should be:
>>> >> end host - end host: the NSIS protocol is terminated at end hosts;
>>> >> end host - proxy: the NSIS protocol is terminated at end host and
>>> >> proxy; end host - edge: the NSIS protocol is terminated at end end
>>> >> host and edge; edge - edge: the NSIS protocol is terminated at egdes
>>> >> of one/multiple domains;
>>> >>
>>> >>
>>> >> Best regards,
>>> >> Georgios
>>> >>
>>> >>
>>> >> -----Original Message-----
>>> >> From: Schneider, Marco [mailto:schneider@tri.sbc.com]
>>> >> Sent: 18 January 2002 20:10
>>> >> To: 'Roy, Radhika R, ALASO'; Gary Kenward; Loughney John
>>> >> (NRC/Helsinki); brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
>>> >> dick.rr.knight@bt.com
>>> >> Cc: nsis@ietf.org
>>> >> Subject: RE: [NSIS] Two kinds of requirements
>>> >>
>>> >>
>>> >> Hi Roy,
>>> >>
>>> >> Below is the original text from your reponse to Gary Kenward.
>>> >> Hopefully the context is clear.
>>> >>
>>> >> "[Roy, Radhika R, ALARC]  I would say that it is the QOS needs of the
>>> >> application (e.g., SIP-based VoIP) that the user likes to express (as
>>> >> opposed to "service"). Similarly, instead of network services, we
>>> >> would say network layer QOS services (e.g., RSVP, DiffServ, MPLS). We
>>> >> would develop the end-to-end (application layer) QOS signaling
>>> >> protocol (say, NSIS QOS). Now, there needs to have some kinds of
>>> >> standards how NSIS QOS will be mapped over RSVP, DiffServ, MPLS,
>>> >> etc."
>>> >>
>>> >> So by End-to-End you mean between directly between two "users". This
>>> >> is session level signaling and I don't believe the signaling part is
>>> >> within the scope of this working group. An application level QOS
>>> >> specification may be.
>>> >>
>>> >> After a session level agreement on QOS, the host/client/customer will
>>> >> need to signal an actual reservation request to the network for the
>>> >> necessary QOS agreed to at the session level. This is the protocol
>>> >> that we need to work on.
>>> >>
>>> >> This approach is discussed in the SIP draft "SIP Extensions for Media
>>> >> Authorization" (draft-ietf-sip-call-auth-03.txt) and the RAP draft
>>> >> "Framework for session set-up with media authorization"
>>> >> (draft-ietf-rap-session-auth-02.txt).
>>> >>
>>> >> Marco Schneider
>>> >>
>>> >> -----Original Message-----
>>> >> From: Roy, Radhika R, ALASO [mailto:rrroy@att.com]
>>> >> Sent: Friday, January 18, 2002 9:18 AM
>>> >> To: Schneider, Marco; Gary Kenward; Loughney John (NRC/Helsinki);
>>> >> brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
>>> >> dick.rr.knight@bt.com
>>> >> Cc: nsis@ietf.org
>>> >> Subject: RE: [NSIS] Two kinds of requirements
>>> >>
>>> >>
>>> >> Defined below [RRR]
>>> >>
>>> >> -----Original Message-----
>>> >> From: Schneider, Marco [mailto:schneider@tri.sbc.com]
>>> >> Sent: Thursday, January 17, 2002 8:47 PM
>>> >> To: Roy, Radhika R, ALASO; Gary Kenward; Loughney John
>>> >> (NRC/Helsinki); brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
>>> >> dick.rr.knight@bt.com
>>> >> Cc: nsis@ietf.org
>>> >> Subject: RE: [NSIS] Two kinds of requirements
>>> >>
>>> >>
>>> >> Hi Roy,
>>> >>
>>> >> Can you please define what you mean by "End-to-End Application Layer
>>> >> QOS Signaling". Thanks.
>>> >>
>>> >> [RRR] Suppose an user is initiation a SIP call to another user with
>>> >> audio, video, and data. The use needs to express the needs of QOS for
>>> >> audio, video, and data to another user.
>>> >>
>>> >> [RRR] The signaling mechanism that allows to express the QOS
>>> >> parameters of audio, video, and data is termed as the "End-to-End
>>> >> Application Layer QOS Signaling."
>>> >>
>>> >> Marco Schneider
>>> >>
>>> >> _______________________________________________
>>> >> 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
>>> >>
>>> >
>>> >
>>> >
>>> > --------------------------------------
>>> > Dr. Marcus Brunner
>>> > Network Laboratories
>>> > NEC Europe Ltd.
>>> >
>>> > E-Mail: brunner@ccrle.nec.de
>>> > WWW:    http://www.ccrle.nec.de/
>>> > personal home page: http://www.brubers.org/marcus
>>> >
>>> >
>>> > _______________________________________________
>>> > nsis mailing list
>>> > nsis@ietf.org
>>> > https://www1.ietf.org/mailman/listinfo/nsis
>>> >
>>>
>>> --------------------------------------
>>> Dr. Marcus Brunner
>>> Network Laboratories
>>> NEC Europe Ltd.
>>>
>>> E-Mail: brunner@ccrle.nec.de
>>> WWW:    http://www.ccrle.nec.de/
>>> personal home page: http://www.brubers.org/marcus
>>>
>>> _______________________________________________
>>> nsis mailing list
>>> nsis@ietf.org
>>> https://www1.ietf.org/mailman/listinfo/nsis
>>
>
>
>
> --------------------------------------
> Dr. Marcus Brunner
> Network Laboratories
> NEC Europe Ltd.
>
> E-Mail: brunner@ccrle.nec.de
> WWW:    http://www.ccrle.nec.de/
> personal home page: http://www.brubers.org/marcus
>



--------------------------------------
Dr. Marcus Brunner
Network Laboratories
NEC Europe Ltd.

E-Mail: brunner@ccrle.nec.de
WWW:    http://www.ccrle.nec.de/
personal home page: http://www.brubers.org/marcus


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



From daemon@optimus.ietf.org  Mon Jan 28 09:03: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 JAA26027
	for <nsis-archive@odin.ietf.org>; Mon, 28 Jan 2002 09:03:24 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id JAA12340
	for nsis-archive@odin.ietf.org; Mon, 28 Jan 2002 09:03: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 IAA10676;
	Mon, 28 Jan 2002 08:51: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 IAA10643
	for <nsis@optimus.ietf.org>; Mon, 28 Jan 2002 08:51:45 -0500 (EST)
Received: from ierw.net.avaya.com (ierw.net.avaya.com [198.152.13.101])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25527
	for <nsis@ietf.org>; Mon, 28 Jan 2002 08:51:41 -0500 (EST)
Received: from ierw.net.avaya.com (localhost [127.0.0.1])
	by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id IAA15669
	for <nsis@ietf.org>; Mon, 28 Jan 2002 08:49:54 -0500 (EST)
Received: from IS0004AVEXU1.global.avaya.com (h149-49-38-91.avaya.com [149.49.38.91])
	by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id IAA15645
	for <nsis@ietf.org>; Mon, 28 Jan 2002 08:49:53 -0500 (EST)
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: Independence of signalling and data path (was RE: [NSIS] Two		kindsof  requirements)
Date: Mon, 28 Jan 2002 15:50:29 +0200
Message-ID: <AAB4B3D3CF0F454F98272CBE187FDE2FF54154@IS0004AVEXU1.global.avaya.com>
Thread-Topic: Independence of signalling and data path (was RE: [NSIS] Two		kindsof  requirements)
Thread-Index: AcGoAe7oloB8OCdlQpis9zAqvwlXEAAAF8kA
From: "Romascanu, Dan (Dan)" <dromasca@avaya.com>
To: "Georgios Karagiannis (ELN)" <Georgios.Karagiannis@eln.ericsson.se>,
        <brunner@ccrle.nec.de>
Cc: <nsis@ietf.org>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id IAA10644
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

> Thus, in GENERAL the path followed by signaling 
> messages and the path followed by user data packets (associated
> to these signaling messages) MUST BE THE SAME!!
> 
> 
Interestingly enough, I am right now involved in a thread in a different
standards group, where customers (service providers) argue strongly that
any control plane protocol should not consume bandwidth at the expense
of the customer traffic. Their argument is that it is not possible to
provide a coherent set of deterministic services if an non-deterministic
amount of the customer bandwidth is consumed by the control plane.

Regards,

Dan

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



From daemon@optimus.ietf.org  Mon Jan 28 09:04: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 JAA26126
	for <nsis-archive@odin.ietf.org>; Mon, 28 Jan 2002 09:04:51 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id JAA12493
	for nsis-archive@odin.ietf.org; Mon, 28 Jan 2002 09:04: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 JAA12429;
	Mon, 28 Jan 2002 09:03: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 JAA12394
	for <nsis@optimus.ietf.org>; Mon, 28 Jan 2002 09:03:48 -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 JAA26052
	for <nsis@ietf.org>; Mon, 28 Jan 2002 09:03:43 -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 g0SE3jX4002950
	for <nsis@ietf.org>; Mon, 28 Jan 2002 15:03:45 +0100 (MET)
Received: FROM esealnt746.al.sw.ericsson.se BY esealnt461 ; Mon Jan 28 15:01:34 2002 +0100
Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <YHLJM0ZA>; Mon, 28 Jan 2002 15:01:51 +0100
Message-ID: <E244E44D6AB85E40AEEF7EAABE3545FA8233CC@enleent104.nl.eu.ericsson.se>
From: "Georgios Karagiannis (ELN)" <Georgios.Karagiannis@eln.ericsson.se>
To: "'Romascanu, Dan (Dan)'" <dromasca@avaya.com>
Cc: nsis@ietf.org
Subject: RE: Independence of signalling and data path (was RE: [NSIS] Two	
		kindsof  requirements)
Date: Mon, 28 Jan 2002 15:01:41 +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 Dan

Please note that these signaling messages are 
QoS signaling messages. 
If the QoS signaling messages will 
signal QoS information to an edge node, and the user 
data packets (associated to this QoS information)
will not pass through the same edge node, then 
the sent QoS information is useless. 

Please note that existing QoS protocols, e.g., 
RSVPv1 works in the same way, i.e.,the RSVP PATH messages
and user data packets that have the same flow ID are using 
the same communication path.

In my opinion your remark is referring to other types of 
signaling protocols.

Best regards,
Georgios


-----Original Message-----
From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com]
Sent: maandag 28 januari 2002 14:50
To: Georgios Karagiannis (ELN); brunner@ccrle.nec.de
Cc: nsis@ietf.org
Subject: RE: Independence of signalling and data path (was RE: [NSIS]
Two kindsof requirements)


> Thus, in GENERAL the path followed by signaling 
> messages and the path followed by user data packets (associated
> to these signaling messages) MUST BE THE SAME!!
> 
> 
Interestingly enough, I am right now involved in a thread in a different
standards group, where customers (service providers) argue strongly that
any control plane protocol should not consume bandwidth at the expense
of the customer traffic. Their argument is that it is not possible to
provide a coherent set of deterministic services if an non-deterministic
amount of the customer bandwidth is consumed by the control plane.

Regards,

Dan

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



From daemon@optimus.ietf.org  Mon Jan 28 12:18: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 MAA02986
	for <nsis-archive@odin.ietf.org>; Mon, 28 Jan 2002 12:18:02 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id MAA24418
	for nsis-archive@odin.ietf.org; Mon, 28 Jan 2002 12:18: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 MAA24288;
	Mon, 28 Jan 2002 12:15: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 MAA24249
	for <nsis@optimus.ietf.org>; Mon, 28 Jan 2002 12:15:12 -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 MAA02907
	for <nsis@ietf.org>; Mon, 28 Jan 2002 12:15:08 -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 g0SHHJT03910;
	Mon, 28 Jan 2002 11:17:19 -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 g0SHEZL02508;
	Mon, 28 Jan 2002 11:14:35 -0600 (CST)
Received: by TRIMAIL2.ad.tri.sbc.com with Internet Mail Service (5.5.2653.19)
	id <ZND3JP6K>; Mon, 28 Jan 2002 11:15:03 -0600
Message-ID: <905A1C4ABF353F4C8CC16FA9F53DD0D638B9BB@TRIMAIL2.ad.tri.sbc.com>
From: "Schneider, Marco" <schneider@tri.sbc.com>
To: "'Ping Pan'" <pingpan@juniper.net>,
        Paulo Mendes
	 <mendes@cs.columbia.edu>
Cc: fu@ee.tu-berlin.de, David.Partain@ericsson.com, NSIS <nsis@ietf.org>
Subject: RE: [NSIS] Framework & requirements part of the "Two kinds of  re
	quirements" thread
Date: Mon, 28 Jan 2002 11:15:03 -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

Ping,

Please see my comments below.

Marco

> -----Original Message-----
> From: Ping Pan [mailto:pingpan@juniper.net]
> Sent: Thursday, January 24, 2002 5:10 PM
> To: Paulo Mendes
> Cc: fu@ee.tu-berlin.de; David.Partain@ericsson.com; NSIS
> Subject: Re: [NSIS] Framework & requirements part of the "Two kinds of
> requirements" thread
> 
> 
> Paulo,
> 
> How are you!
> 
> Paulo Mendes wrote:
> 
> >> Also, let's be careful with adaptive applications. They 
> look very nice 
> >> on paper, but when you see what type of switches are used 
> interfacing 
> >> between voice networks and the Internet, you gotta be 
> kidding me to 
> >> insist on adaptiveness for your traffic....
> > 
> > 
> > 
> > [PM] I don't know about others, but when I speak about adaptive 
> > applications I'm thinking of 100% IP networks.
> > 
> 
> 
> The problem is that much of the voice traffic flowing over 
> the Internet 
> has nothing to do with the native Internet applications. Many 
> providers 
> setup tunnels through their backbones and transport non-IP 
> packets. The 
> access points are not pure IP boxes. They may be some ancient and 
> expensive Luent switches. If you ask the switches to run some fancy 
> adaptive schemes to all the traffic, they may crash.
> 
> > 
> >> Currently, most of the backbone networks are 
> over-provisioned, so no 
> >> serious signaling is required yet. End-to-end signaling is very 
> >> attractive to the end users, but the providers will not allow the 
> >> users to tell the routers how much to reserve. In fact, I 
> doubt the 
> >> providers will listen to anything that end-user are 
> throwing at them. 
> >> So other than some end-to-end measurement-based approach, 
> I don't see 
> >> e2e signaling will fly in the present network.

[MS] If we think we can charge extra for it then we will do it. As you well
know the user is not going to care whether the reservations in the network
are hop by hop or there is overprovisioning or whatever, as long as the QOS
is met.  We will let users tell us "how much to reserve".

> > 
> > 
> > 
> > [PM] Allow me to disagree... Are you mentioning US over-provided 
> > networks, or networks in other geographic locations? And 
> even if you're 
> > only thinking in an US Internet, can you tell me how can this 
> > over-provision take place?
> 
> 
> (I thought I wrote a paper on this in my past life....:-)) Yes, all 
> backbones have "hot" spots, and have congestion. But the backbone 
> problems can be (or have been) addressed via RSVP-TE. Yes, we have 
> short-time outage in the backbone due to frequent upgrade and router 
> crash. That's why we have worked very hard on backbone traffic 
> redundency (fast reroute, graceful restart.....) issues. So 
> far, I have 
> a pretty good feeling on resource management within the backbone. The 
> focus is now on the edge and the access. I am hoping NSIS is 
> the place 
> to do it.
> 
> 
> > I agree that network providers can't engineer their network 
> to satisfy 
> > every single client reclamation. That's why clients 
> (receivers) with 
> > adaptive applications are useful to network providers. The network 
> > notify about their capabilities and the clients deal with 
> it (adapt, 
> > leave session, ...).
> 
> 
> The "receivers" can be some monitoring boxes arranged by the 
> providers 
> to monitor the traffic in/out of the network. If things are not OK, 
> these boxes may play some rotuing tricks to redirect traffic from the 
> edge. I am not sure they are regular users.
> 
> 
> > 
> >> Finally, the providers are motivated by money to provide any 
> >> additional service. Unless the traffic that they are 
> carrying worth 
> >> something, they will never deploy some extra "stuff" inside the 
> >> network. So what's worth money? ....
> > 
> > 
> 
> > 
> > [PM] Okey.. But if network providers don't develop new 
> services how can 
> > they expect clients to use them, if they don't exist?
> > 
> 
> 
> I have just listed some of the services below. IMHO, the 
> current state 
> of the Internet is not about "new" services, or "new" economy to that 
> matter. The Internet is a new media to transport traffic, 
> like we have 
> been doing via post office, SNA, phone networks, Frame/ATM 
> networks.... 
> The trick is to send the same old information efficiently.... 
> Plus the 
> Internet needs to evolve itself to carry traffic some future 
> applications when they come..
> 
> 
> > 
> >> - voice traffic! I am not only talking about VoIP; I am 
> talking all 
> >> the voice traffic that use the Internet infrastructure.
> >>
> >> - wireless traffic: users packets are not landed inside 
> the backbone, 
> >> so the access network needs to do more to those flows.
> >>
> >> - VPN (an over-used term :-)): but some users want to have QoS 
> >> reservation even though they are sending any traffic. Not for any 
> >> technical reason, it's a business reason. Have you seen 
> the amount of 
> >> traffic in a SNA network, and how much they have been charged? :-)
> >>
> 
> - Ping
> 
> 
> _______________________________________________
> 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 Jan 28 12:23: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 MAA03106
	for <nsis-archive@odin.ietf.org>; Mon, 28 Jan 2002 12:23:09 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id MAA24573
	for nsis-archive@odin.ietf.org; Mon, 28 Jan 2002 12:23: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 MAA23966;
	Mon, 28 Jan 2002 12:10: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 MAA23933
	for <nsis@optimus.ietf.org>; Mon, 28 Jan 2002 12:10:23 -0500 (EST)
Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02734
	for <nsis@ietf.org>; Mon, 28 Jan 2002 12:10:14 -0500 (EST)
Received: from zrchb200.us.nortel.com (zrchb200.us.nortel.com [47.103.121.45])
	by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g0SH9Kr02226;
	Mon, 28 Jan 2002 11:09:20 -0600 (CST)
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <CK6QY50V>; Mon, 28 Jan 2002 11:09:19 -0600
Message-ID: <933FADF5E673D411B8A30002A5608A0E01B4E80B@zrc2c012.us.nortel.com>
From: "Glenn Morrow"<gmorrow@nortelnetworks.com>
To: brunner@ccrle.nec.de,
        "Georgios Karagiannis (ELN)"
	 <Georgios.Karagiannis@eln.ericsson.se>,
        "'fu@ee.tu-berlin.de'"
	 <fu@ee.tu-berlin.de>
Cc: nsis@ietf.org
Subject: RE: [NSIS] RE: Independence of signalling and data path (was RE: 
	[NSIS] Two	kindsof  requirements)
Date: Mon, 28 Jan 2002 11:09:38 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C1A81E.9144B950"
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_01C1A81E.9144B950
Content-Type: text/plain;
	charset="iso-8859-1"

Marcus,

Here is my opinion on the path-directed or separation question.

It seems to me that some parts of the network will benefit from separate
paths for signaling and bearer data; whereas other parts will not benefit
and will actually be complicated by such a separation. 

The parts that could benefit from a separation are expensive shared media
hops such as cellular and perhaps cable.  

The parts that will not benefit in my opinion is everything else. If
signaling does not follow the path then the signaling nodes will have to
know a great deal of information about routes and routing policies. They
will have to be disclosed either via configuration or cross signaling, the
routing tables, LSPs, VCs, policies and updates. This seems to create a
rather large mess in terms of administrative costs, race conditions,
mismatches in policy and routes between routers and these controllers etc.. 

Mandatory separation would also eliminate the ability to bundle or piggyback
signaling with bearer data.

Sometimes it is beneficial to separate and sometimes it is not. The
architecture could allow for both at different parts of the network;
however, I think the separation is a specific layer 2 optimization issue;
whereas path-directed would be more geared to a general solution for the
connectionless network problem space. 

Glenn

------_=_NextPart_001_01C1A81E.9144B950
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] RE: Independence of signalling and data path (was RE: =
[NSIS] Two	kindsof  requirements)</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Marcus,</FONT>
</P>

<P><FONT SIZE=3D2>Here is my opinion on the path-directed or separation =
question.</FONT>
</P>

<P><FONT SIZE=3D2>It seems to me that some parts of the network will =
benefit from separate paths for signaling and bearer data; whereas =
other parts will not benefit and will actually be complicated by such a =
separation. </FONT></P>

<P><FONT SIZE=3D2>The parts that could benefit from a separation are =
expensive shared media hops such as cellular and perhaps cable.&nbsp; =
</FONT>
</P>

<P><FONT SIZE=3D2>The parts that will not benefit in my opinion is =
everything else. If signaling does not follow the path then the =
signaling nodes will have to know a great deal of information about =
routes and routing policies. They will have to be disclosed either via =
configuration or cross signaling, the routing tables, LSPs, VCs, =
policies and updates. This seems to create a rather large mess in terms =
of administrative costs, race conditions, mismatches in policy and =
routes between routers and these controllers etc.. </FONT></P>

<P><FONT SIZE=3D2>Mandatory separation would also eliminate the ability =
to bundle or piggyback signaling with bearer data.</FONT>
</P>

<P><FONT SIZE=3D2>Sometimes it is beneficial to separate and sometimes =
it is not. The architecture could allow for both at different parts of =
the network; however, I think the separation is a specific layer 2 =
optimization issue; whereas path-directed would be more geared to a =
general solution for the connectionless network problem space. =
</FONT></P>

<P><FONT SIZE=3D2>Glenn</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1A81E.9144B950--

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



From daemon@optimus.ietf.org  Mon Jan 28 12: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 MAA04061
	for <nsis-archive@odin.ietf.org>; Mon, 28 Jan 2002 12:56:14 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id MAA26305
	for nsis-archive@odin.ietf.org; Mon, 28 Jan 2002 12:56: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 MAA26039;
	Mon, 28 Jan 2002 12:46: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 MAA26010
	for <nsis@optimus.ietf.org>; Mon, 28 Jan 2002 12:46:37 -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 MAA03799
	for <nsis@ietf.org>; Mon, 28 Jan 2002 12:46:34 -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 g0SHmkT04227;
	Mon, 28 Jan 2002 11:48:46 -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 g0SHk0T03958;
	Mon, 28 Jan 2002 11:46:01 -0600 (CST)
Received: by TRIMAIL2.ad.tri.sbc.com with Internet Mail Service (5.5.2653.19)
	id <ZND3JQC9>; Mon, 28 Jan 2002 11:46:29 -0600
Message-ID: <905A1C4ABF353F4C8CC16FA9F53DD0D638B9BC@TRIMAIL2.ad.tri.sbc.com>
From: "Schneider, Marco" <schneider@tri.sbc.com>
To: "'Georgios Karagiannis (ELN)'" <Georgios.Karagiannis@eln.ericsson.se>,
        "Chen, Weijing" <wchen@tri.sbc.com>
Cc: NSIS Mailing List <nsis@ietf.org>
Subject: RE: [NSIS] Framework & requirements part of the "Two kinds of req
	 uirements" thread
Date: Mon, 28 Jan 2002 11:46:28 -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

Georgios,

Thank you for clarifying the picture you presented. I still interpret that
you are imposing structure on the solution (albeit generalized which is a
good thing). 

1) It assumes the same functionality in the host as the edge for UNI
signaling: (The picture shows everyedge function in both host and edge, and
your discussion below seems to imply that this is what a host will use to
signal to the network for a QOS connection.)

2) It assumes a linear model of signaling and thus rules out alternative
hierarchical approaches. By linear I mean that whether hop by hop or edge to
edge it shows this occuring in order across a path. One hop/edge signals to
the next hop/edge. By hierarchical I mean that either the host (which I
don't advocate) or a network element signals the creation of multiple
segments which spliced together provide the end-to-end QOS. 

Marco



> -----Original Message-----
> From: Georgios Karagiannis (ELN)
> [mailto:Georgios.Karagiannis@eln.ericsson.se]
> Sent: Friday, January 25, 2002 7:11 AM
> To: Chen, Weijing; Schneider, Marco
> Cc: NSIS Mailing List
> Subject: RE: [NSIS] Framework & requirements part of the "Two kinds of
> req uirements" thread
> 
> 
> Hi Weijing and Marco
> 
> I will just repeat some text from the proposed framework:
> 
>  * A "host" could be an end host or a proxy.  It can process
>    and use the "everyhost", "everyedge", and "everyhop"
>    protocol components
>  * An "edge" can be a Diffserv edge, MPLS edge, etc.  It can
>    process and use the "everyedge", and "everyhop" protocol
>    components. The "everyhost" protocol component is not
>    processed (used or checked) but is carried onward.
> 
>  * An "interior within domain" can be any router within
>    a domain.  It can process and use only the "everyhop"
>    protocol component.  The "everyhost" and "everyedge"
>    protocol components are not processed (used or checked)
>    but are carried onward.
> 
> Example _1: Suppose that a network provider is managing an 
> overprovisioned 
> network and is willing to provide to its end users applications that 
> require end to end QoS support (e.g., telephony).
> This provider may choose to use the (NSIS) protocol 
> on an "end host to end host" basis. In this case 
> the "host" will not use (activate) the "everyedge" 
> and "everyhop" components, since they are not required.
> Therefore, all edges and hops in the network will not process this 
> type of NSIS protocol. Thus the NSIS message will only be processed 
> by the end hosts. This is identical to the ("simple") example used
> by Weijing.
> 
> Example_2: Now suppose that the network consists of overprovisioned 
> access networks (managed by one provider) and by many concatenated 
> QoS domains that are overprovisioned
> but they are managed by different network providers.
> 
> Assume that the end user will like to use the "end host 
> to end host" type of NSIS protocol for this purpose.
> In this case the "host" will only activate the [everyedge] 
> component, which will include 
> QoS information that is needed by an edge of a domain. 
> The [everyhop] component will not be activated, and therefore,
> it will not be processed by any router located within the 
> overprovisioned access network. Thus, the interior nodes 
> located within the overprovisioned access network will not use 
> the NSIS message.
> 
> The first edge node of a domain that will receive the NSIS message
> will only use the [everyedge] information. Please note
> that the edge node may change (replace) the [everyedge]
> information.  If within this domain 
> none existing QoS mechanism, e.g., Intserv/MPLS/overprovisioning,
> are used, then the edge (of course this depends on the 
> policy of the provider of the domain) will activate and include 
> information into the [everyhop] component. Every hop within this 
> domain will only use the [everyhop] component included in 
> the NSIS message.
> 
> The same principles could be applied to all other domains 
> wherein the NSIS message will pass through in its way to the 
> receiving end host.
> 
> This example shows that by using the proposed framework
> the NSIS protocol will be used (and checked) only (and only) by the 
> nodes that need to use it. In this way the protocol can be 
> processed fast and at the same time provide a reasonable level 
> of QoS signaling functionality.
> 
> 
> Best Regards,
> Georgios
> 
> 
> 
> 
> 
> 
> -----Original Message-----
> From: Chen, Weijing [mailto:wchen@tri.sbc.com]
> Sent: vrijdag 25 januari 2002 4:59
> To: 'Georgios Karagiannis (ELN)'
> Cc: NSIS Mailing List
> Subject: RE: [NSIS] Framework & requirements part of the "Two kinds of
> req uirements" thread
> 
> 
> Georgios,
> 
> >>In principle I agree with you. The framework should not be used
> >>to  define the NSIS requirements. The NSIS requirements should be
> >>produced based on different QoS needs of certain application types.
> 
> Thank you.
> 
> >>No it is not required that the "host" has a global view 
> >>of the domains. The way of how this NSIS protocol finds the edges
> >>and the hops is similar with the way the RSVPv1 protocol does it.
> 
> So we still expose the network interior to host. Then what is 
> the benefit of
> this for host? Compare the following stacks that the host has 
> to handle:
> 
> |-----|
> |ehost|
> |-----|
> |     |
> |-----|
> |eedge|
> |-----|
> |     |
> |-----|
> |ehop |
> |-----|
>  host    
> 
> vs.
> 
> |-----|
> |ehost|
> |-----|
>  host                
> 
> Cleary the latter one is much simpler.
> 
> Now let's take a look what is the typical sequence of 
> end-to-end QoS service
> delivery chain:
> 
> [src ehost]->hello, edge, I want so and so [original QoS] to so and so
> place.
> [incoming eedge]->ok, host, just a millisecond.
>        [background] glueing the [original QoS] to [ehop QoS] in first
> [ehop], 
>                     [ehop] passes [ehop QoS] and [original 
> QoS] to next
>                     [ehop], on and on to outgoing [eedge].
> [outgoing eedge]->hello, ehost, here is [original QoS] request from
>                   [src ehost], will you take it?
> [dest ehost]->ok, accept.
> [outgoing eedge]-->[ehop]-->[incoming eedge]...
> [incoming eedge]->host, you are ready to go.
> [src ehost]->ok...
> 
> In the above sequence, [ehost] only deals with [eedge] 
> directly, not [ehop].
> So why do we want to force [ehop] information (i.e. network internal
> information) to [ehost]? If we are doing so, [ehost] would 
> say "Ooo, I am
> stuffed, choked, ok, I am giving up. I don't want QoS." Which 
> is exactly
> where we are today.
> 
> So please don't stuff the poor [ehost] with anything else except he
> absoultly need for [ehost] to [eedge] request and response. 
> Thank you very
> much.
> 
> --
> Weijing Chen
> SBC Technology Resources
> 9505 Arboretum Blvd.
> Austin, TX 78759
> 512 372 5710
> wchen@tri.sbc.com
> 
> 
> -----Original Message-----
> From: Georgios Karagiannis (ELN)
> [mailto:Georgios.Karagiannis@eln.ericsson.se] 
> Sent: Thursday, January 24, 2002 3:33 AM
> To: Chen, Weijing
> Cc: NSIS Mailing List
> Subject: RE: [NSIS] Framework & requirements part of the "Two 
> kinds of req
> uirements" thread
> 
> Hi Weijing
> 
> Please see my comments in line.
> 
> [WC]>> 1. David's proposal of working requirement within so 
> [WC]>> called "framework" is putting the cart before the horse. 
> [WC]>> Because we think one framework is cool,
> [WC]>> we confine our requirements and use cases within 
> [WC]>> that framework. It is totally unacceptable.
> 
> In principle I agree with you. The framework should not be used
> to  define the NSIS requirements. The NSIS requirements should be
> produced based on different QoS needs of certain application types.
> However, the mentioned framework can be used to decompose a 
> complex QoS problem into certain simpler QoS problems.
> 
> [WC]>> 2. Figure
> [WC]>>  In above picture, [host] has to assemble and process 
> [WC]>>  the [ehop], [eedge] in addition to [ehost] part. How will 
> [WC]>>  the [host] correctly assemble and process
> [WC]>> the [ehop] and [eedge] pieces? It implies that [host] has 
> [WC]>> global view of [ehop] and [eedge] in every domains. 
> [WC]>> to happen, there must be another protocol to exchange network 
> [WC]>> information and pass whole network view
> [WC]>> to [host]. 
> 
> No it is not required that the "host" has a global view 
> of the domains. The way of how this NSIS protocol finds the edges
> and the hops is similar with the way the RSVPv1 protocol does it.
> 
> [WC] >> Now what about "glue"? Shall NSIS do it? Part of me 
> [WC] >> says yes, another says
> [WC] >> no. I am 50/50.
> 
> Please note that the NSIS charter mentions that a "framework" 
> draft should be specified by March 2002.
> 
> Best regards,
> Georgios
> 
> 
> -----Original Message-----
> From: Chen, Weijing [mailto:wchen@tri.sbc.com]
> Sent: donderdag 24 januari 2002 9:43
> To: David.Partain@ericsson.com
> Cc: NSIS Mailing List
> Subject: RE: [NSIS] Framework & requirements part of the "Two kinds of
> req uirements" thread
> 
> 
> 
> I have fundamental disagreement with David's point.
> 
> 1. David's proposal of working requirement within so called 
> "framework" is
> putting the cart before the horse. Because we think one 
> framework is cool,
> we confine our requirements and use cases within that framework. It is
> totally unacceptable.
> 
> 2. 
> 
> |-----|                                                  |-----|
> |ehost|<------------------------------------------------>|ehost|
> |-----|                                                  |-----|
> |     |                                                  |     |
> |-----|            |-----|            |-----|            |-----|
> |eedge|<---------->|eedge|<---------->|eedge|<---------->|eedge|
> |-----|            |-----|            |-----|            |-----|
> |     |            |     |            |     |            |     |
> |-----|   |----|   |-----|   |----|   |-----|   |----|   |-----|
> |ehop |<->|ehop|<->|ehop |<->|ehop|<->|ehop |<->|ehop|<->|ehop |
> |-----|   |----|   |-----|   |----|   |-----|   |----|   |-----|
>  host    interior   edge    interior   edge     interior  host
>          w/in domain       w/in domain        w/in domain
> 
> In above picture, [host] has to assemble and process the 
> [ehop], [eedge] in
> addition to [ehost] part. How will the [host] correctly 
> assemble and process
> the [ehop] and [eedge] pieces? It implies that [host] has 
> global view of
> [ehop] and [eedge] in every domains. For this to happen, there must be
> another protocol to exchange network information and pass 
> whole network view
> to [host]. So on, and so on, and sooner we know that we 
> revive an ultimate
> engineer dream: a protocol for all and do all. Be there, done 
> that, and
> failed. Otherwise we wouldn't be here to debate about what 
> NSIS should be.
> 
> The right picture should be (if you insist talking about the framework
> before requirement):
> 
>                    |-----|   |----|   |-----|  
>                    |ehop |<->|ehop|<->|ehop |   
>                    |-----|   |----|   |-----| 
>                    |     |            |     |
>                    |-----|            |-----|
>                    |glue |            |glue |
>                    |-----|            |-----|
>                    |     |            |     |
> |-----|            |-----|            |-----|            |-----|
> |ehost|<---------->|ehost|<---------->|ehost|<---------->|ehost|
> |-----|            |-----|            |-----|            |-----|
>  host                edge     hop      edge                host
>            domain            domains             domain
>                              (inter and
>                               intra)
>            NSIS                                   NSIS
> 
> Now what about "glue"? Shall NSIS do it? Part of me says yes, 
> another says
> no. I am 50/50.
> 
> --
> Weijing Chen
> SBC Technology Resources
> 9505 Arboretum Blvd.
> Austin, TX 78759
> 512 372 5710
> wchen@tri.sbc.com
> 
> 
> 
> -----Original Message-----
> From: David Partain [mailto:David.Partain@ericsson.com] 
> Sent: Wednesday, January 23, 2002 3:58 AM
> To: NSIS Mailing List
> Subject: [NSIS] Framework & requirements part of the "Two kinds of
> requirements" thread
> 
> Greetings all,
> 
> I'd like to offer my take on part of the thread "Two kinds
> of requirements" to see if we can collectively reach any sort
> of conclusion based on what's been written.  I doubt I'll say
> anything new, but perhaps it'll help summarize a bit.
> 
> To cut to the chase, the conclusion of this mail is that
> I think:
> 
>  - we should use the "framework" below as the starting point of
>    framework discussions
>  - the requirements should grow from use cases of particular
>    applications that will use the network
> 
> The original mail postulated that people are wanting to work
> on two kinds of requirements here:
> 
>  - end-host to end-host, or application to application
>    signalling
> 
>  - transport level signalling
> 
> From that point, there has been a hearty debate about whether
> this indeed is true, as well as a host of other issues.
> 
> I think the following points have been made, amongst others:
> 
>  - It should support the use of throughput adaptive applications
>    and the ability for a traffic flow to express its QoS
>    preferences with regard to the throughput values which it
>    may be allocated.
> 
>  - One part of the thread was about whether RSVP and related
>    work (e.g., RFC 2998), or perhaps SDPng, are suitable
>    solutions.  While it's obvious that we need to learn from
>    and perhaps start from one of these efforts in working on
>    NSIS, it also seems clear that we shouldn't start working
>    on that until the requirements are done.
> 
>  - There's no chance we'll create a single one-size-fits-all
>    application-related signalling protocol that will be used
>    by everyone.  That seems very clear.
> 
>  - There's a need for something transport independent that can
>    help signal QoS needs across multiple domains in order
>    to help the application-related signalling protocols do
>    their thing.
> 
> The big issue there is what part of this we should solve here.
> Should we concentrate specifically on the application/host
> to network signalling?  I think not and others have agreed.
> Should we try to design something that goes end to end?  If we
> do that, do we have a "chicken and egg" problem of needing to
> have the technology everywhere for things to work?
> 
> A case has been made that the goal should be to create a
> signalling protocol that has different kinds of components
> appropriate to different parts of the problem.  Georgios K.
> proposed the following figure, which I like quite a lot and
> which others have said is good, as a way of looking at it:
> 
> |-----|                                                  |-----|
> |ehost|<------------------------------------------------>|ehost|
> |-----|                                                  |-----|
> |     |                                                  |     |
> |-----|            |-----|            |-----|            |-----|
> |eedge|<---------->|eedge|<---------->|eedge|<---------->|eedge|
> |-----|            |-----|            |-----|            |-----|
> |     |            |     |            |     |            |     |
> |-----|   |----|   |-----|   |----|   |-----|   |----|   |-----|
> |ehop |<->|ehop|<->|ehop |<->|ehop|<->|ehop |<->|ehop|<->|ehop |
> |-----|   |----|   |-----|   |----|   |-----|   |----|   |-----|
>  host    interior   edge    interior   edge     interior  host
>          w/in domain       w/in domain        w/in domain
> 
>    ehost = everyhost
>    eedge = everyedge
>    ehop  = everyhop
> 
> NSIS protocol decomposition:
> 
>  * A "host" could be an end host or a proxy.  It can process
>    and use the "everyhost", "everyedge", and "everyhop"
>    protocol components.
> 
>  * An "edge" can be a Diffserv edge, MPLS edge, etc.  It can
>    process and use the "everyedge", and "everyhop" protocol
>    components. The "everyhost" protocol component is not
>    processed (used or checked) but is carried onward.
> 
>  * An "interior within domain" can be any router within
>    a domain.  It can process and use only the "everyhop"
>    protocol component.  The "everyhost" and "everyedge"
>    protocol components are not processed (used or checked)
>    but are carried onward.
> 
> The everyhop bit within a domain provides signalling facilities
> for that particular domain and is very likely to differ from
> the everyhop bit used in the next boarding domain.
> 
> The point of all of this is to get a concatenation of results.
> Each domain is responsible for taking its own decisions in its
> own domain-specific ways.  The concatenation of the everyhop
> decisions within a domain provides the domain's answer.
> The concatenation of the domains' results gives and end to
> end answer that can be used by the everyhost bit.
> 
> I think that having this overall framework -- for lack of a
> better term -- in mind is very helpful.
> 
> If we can agree that this is a reasonable framework to use as
> the basis of discussion, I think that what we need to do is
> to produce a set of requirements for different "applications"
> that will use these networks/this framework.  Indeed, I believe
> this matches Keith Allen's request that requirements be based on
> use cases.  If we know we're going to use the NSIS protocol on
> a cellular wireless network (just to pull an example out of the
> air :-)), then that "use case" implies a set of requirements.
> A different scenario (e.g., the core of the network) implies
> another set of requirements.
> 
> I personally think this is the right way forward and would
> like to see this group move in this direction.
> 
> Georgios added some more thoughts on this topic
> which addressed the applicability and prioritization
> of work.  That can be found in the archive at
> http://www1.ietf.org/mail-archive/working-groups/nsis/current/
msg00418.html

I realize that I haven't covered everyone's particular topic
in this thread, but perhaps it'll help focus on one part of
the discussion.  If someone wants to summarize some other
sub-thread, that would be great...

Cheers,

dlp

ps. I think it would be very useful if Subject lines could more
accurately reflect the topic covered in the mail.  Long threads
with the same subject and covering a multitude of topics is
difficult to follow...

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

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

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

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



From daemon@optimus.ietf.org  Mon Jan 28 14:05: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 OAA06023
	for <nsis-archive@odin.ietf.org>; Mon, 28 Jan 2002 14:05:50 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id OAA29900
	for nsis-archive@odin.ietf.org; Mon, 28 Jan 2002 14:05: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 OAA29729;
	Mon, 28 Jan 2002 14:02: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 OAA29656
	for <nsis@optimus.ietf.org>; Mon, 28 Jan 2002 14:02:17 -0500 (EST)
Received: from swan.prod.itd.earthlink.net (swan.mail.pas.earthlink.net [207.217.120.123])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05969
	for <nsis@ietf.org>; Mon, 28 Jan 2002 14:02:13 -0500 (EST)
Received: from user-vcaulgn.dsl.mindspring.com ([216.175.86.23] helo=ANDREWHOME)
	by swan.prod.itd.earthlink.net with smtp (Exim 3.33 #1)
	id 16VH2i-0002DX-00; Mon, 28 Jan 2002 11:02:13 -0800
From: "Andrew Smith" <ah_smith@acm.org>
To: "Romascanu, Dan \(Dan\)" <dromasca@avaya.com>
Cc: <nsis@ietf.org>
Subject: RE: Independence of signalling and data path (was RE: [NSIS] Two kindsof  requirements)
Date: Mon, 28 Jan 2002 11:29:53 -0800
Message-ID: <KIEAIFILPFNLNGMKLEMGGECFDAAA.ah_smith@acm.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
In-Reply-To: <AAB4B3D3CF0F454F98272CBE187FDE2FF54154@IS0004AVEXU1.global.avaya.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

Dan,

I think that's a specious argument that they are using (in 802.3 Ethernet
First Mile I assume you mean) to try to force an out-of-band management
channel as part of that standard. And if there's sufficient control-plane
traffic to measureably and significantly affect the determinism of the
service offered then I think there are bigger problems with the control
protocol (or possibly you are trying to allocate resource chunks that are
way too small)!

And do you remember some of the ATM Forum debates where some people were
arguing that the control protocol (UNI signaling) must not contain
end-user-defined fields because they could be used for theft-of-service?
That line of reasoning was abandoned though when someone pointed out that
the presence or absence of a signaling request or response in a given time
interval could be construed as a 1-bit, presumably un-billed-for, message in
itself ...

Andrew Smith

-----Original Message-----
From: nsis-admin@ietf.org [mailto:nsis-admin@ietf.org]On Behalf Of
Romascanu, Dan (Dan)
Sent: Monday, January 28, 2002 5:50 AM
To: Georgios Karagiannis (ELN); brunner@ccrle.nec.de
Cc: nsis@ietf.org
Subject: RE: Independence of signalling and data path (was RE: [NSIS]
Two kindsof requirements)


> Thus, in GENERAL the path followed by signaling
> messages and the path followed by user data packets (associated
> to these signaling messages) MUST BE THE SAME!!
>
>
Interestingly enough, I am right now involved in a thread in a different
standards group, where customers (service providers) argue strongly that
any control plane protocol should not consume bandwidth at the expense
of the customer traffic. Their argument is that it is not possible to
provide a coherent set of deterministic services if an non-deterministic
amount of the customer bandwidth is consumed by the control plane.

Regards,

Dan

_______________________________________________
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 Jan 28 14:42: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 OAA06917
	for <nsis-archive@odin.ietf.org>; Mon, 28 Jan 2002 14:42:22 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id OAA01678
	for nsis-archive@odin.ietf.org; Mon, 28 Jan 2002 14:42: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 OAA01316;
	Mon, 28 Jan 2002 14:32: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 OAA01285
	for <nsis@optimus.ietf.org>; Mon, 28 Jan 2002 14:32:53 -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 OAA06685
	for <nsis@ietf.org>; Mon, 28 Jan 2002 14:32:49 -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 g0SIY3T04569;
	Mon, 28 Jan 2002 12:34:03 -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 g0SIVIh06993;
	Mon, 28 Jan 2002 12:31:20 -0600 (CST)
Received: by TRIMAIL2.ad.tri.sbc.com with Internet Mail Service (5.5.2653.19)
	id <ZND3JQNX>; Mon, 28 Jan 2002 12:31:46 -0600
Message-ID: <905A1C4ABF353F4C8CC16FA9F53DD0D638B9BE@TRIMAIL2.ad.tri.sbc.com>
From: "Schneider, Marco" <schneider@tri.sbc.com>
To: "'Brian Williams'" <brian.williams@ericsson.com.au>,
        john loughney
	 <john.loughney@nokia.com>
Cc: nsis@ietf.org
Subject: RE: [NSIS] Two kinds of requirements
Date: Mon, 28 Jan 2002 12:31:44 -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

Brian,

I will look forward to reading your draft as this is an area I know very
little about.

Marco

> -----Original Message-----
> From: Brian Williams [mailto:brian.williams@ericsson.com.au]
> Sent: Friday, January 25, 2002 11:00 AM
> To: john loughney
> Cc: nsis@ietf.org
> Subject: RE: [NSIS] Two kinds of requirements
> 
> 
> Hi John.
> On Sat, 2002-01-26 at 01:46, john.loughney@nokia.com wrote:
> > Brian,
> > 
> > > My concern is that there must be sufficient information 
> of some type to
> > > allow the derivation of what is required for the layer 2. 
> However, the
> > > typical set of parameters currently in Intserv is not 
> sufficient to
> > > allow a spectrum efficient bearer, and more information is needed.
> > 
> > I'd be very interested in know what kind of parameters you mean.
> > Is there a reason why the layer 2 technology cannot handle the
> > specifics for setting up of layer 2?  Are applications sitting over
> > layer 3 so demanding / fussy that the need very precise details?
> A layer 2 management entity (at either end of the L2 connection) would
> be responsible for establishing the layer 2 connection using 
> the layer 2
> specific protocol. If you look at UMTS, this protocol has a 
> large number
> of parameters; the aim of which is to allow spectrum 
> efficiency which is
> _the_key_concern_ for cellular. So, it is not the layer 3 that is
> demanding, it is the need to make the most of the spectrum 
> (read as best
> QoS possible for lowest possible cost).
> 
> The layer 2 can trade off some characteristics against others:
> eg.- to get a lower delay, you may accept a higher bit error rate
> - in some cases you want the radio link to build in more error
> correction (possible increase in delay, but much better 
> characteristics
> than end-to-end error recovery). In other cases you want to 
> have packets
> delivered even with errors to get lowest delay (eg a speech 
> application
> can be tolerant to errors in codec bits).
> 
> There are many of these that need to be set. If you only provide the
> typical parameters from layer 3 (eg. traffic rate, delay) 
> then the layer
> 2 management function cannot identify the optimal (ie 
> cheapest that best
> meets your needs) bearer. That is because fixed networks typically
> assume error rates are low enough to be ignored, and it is _only_
> bandwidth, delay and congestion loss that determine QoS. For cellular,
> we believe there are more factors that affect QoS, and there are more
> details. 
> 
> We have two drafts which 
> 1) identify the problem
> http://search.ietf.org/internet-drafts/draft-fodor-intserv-wir
eless-issues-00.txt
and
2) give an indication of the parameters we are considering 
http://search.ietf.org/internet-drafts/draft-fodor-intserv-wireless-params-0
0.txt
 
These drafts look at Intserv, and are not tailored to NSIS though. We
are currently working on a new draft discussing the cellular network
problem focused more towards NSIS.
/brian

> My feeling is that we should generalize the layer 3 needs, and
> that layer 2 (or the service provider) can interpret them to
> its needs.  
> 
> 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 Jan 28 15:05:27 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07463
	for <nsis-archive@odin.ietf.org>; Mon, 28 Jan 2002 15:05:27 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id PAA02900
	for nsis-archive@odin.ietf.org; Mon, 28 Jan 2002 15:05: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 OAA02094;
	Mon, 28 Jan 2002 14:55: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 OAA02063
	for <nsis@optimus.ietf.org>; Mon, 28 Jan 2002 14:55:45 -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 OAA07249
	for <nsis@ietf.org>; Mon, 28 Jan 2002 14:55:42 -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 g0SILYT04473;
	Mon, 28 Jan 2002 12:21:35 -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 g0SIInO05614;
	Mon, 28 Jan 2002 12:18:51 -0600 (CST)
Received: by TRIMAIL2.ad.tri.sbc.com with Internet Mail Service (5.5.2653.19)
	id <ZND3JQK7>; Mon, 28 Jan 2002 12:19:16 -0600
Message-ID: <905A1C4ABF353F4C8CC16FA9F53DD0D638B9BD@TRIMAIL2.ad.tri.sbc.com>
From: "Schneider, Marco" <schneider@tri.sbc.com>
To: "'brunner@ccrle.nec.de'" <brunner@ccrle.nec.de>,
        Elwyn Davies
	 <elwynd@nortelnetworks.com>,
        "Nsis (E-mail)" <nsis@ietf.org>
Subject: RE: [NSIS] Tying the requests to the flows exploiting them
Date: Mon, 28 Jan 2002 12:19:15 -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 Marcus, Elwynd:

This is an interesting point. Has anyone advocated generating a token by
encrypting successively at each domain in a destination to source direction.


Marco 

> -----Original Message-----
> From: Marcus Brunner [mailto:brunner@ccrle.nec.de]
> Sent: Friday, January 25, 2002 10:50 AM
> To: Elwyn Davies; Nsis (E-mail)
> Subject: Re: [NSIS] Tying the requests to the flows exploiting them
> 
> 
> Elwynd,
> 
> This is a very critical point, and we have been thinking 
> about it for quite 
> some time, but found no solution which is suitable (some or 
> to expensive in 
> terms of a overhead, others are only peodo secure :-). It is 
> getting very 
> important at the time a user pays for QoS (as you said).
> 
> I think it boils down to the problem, that an source IP 
> address does not 
> tell you something about the user sittin behind.
> 
> Marcus
> 
> --On Friday, January 18, 2002 5:45 PM +0000 Elwyn Davies 
> <elwynd@nortelnetworks.com> wrote:
> 
> >
> > Hi.
> >
> > Nsis is targeting the setup of QoS paths across multiple domains
> > potentially belonging to several organisations that don't trust each
> > other.  This has been reflected in the proposals for the internal
> > operation of the protocol where extensive security requirements are
> > proposed (Sec 5.8).  What appears to be missing are equivalently
> > stringent means for ensuring that domains that authorise a 
> QoS path can
> > tell that the packets using that path are actually the ones 
> that should
> > be using it.
> >
> > In the simpler world of Intserv and Diffserv, requested QoS 
> is invoked by
> > simple pattern matching on some combination of the packet 
> header fields,
> > but even here thare has been a good deal of heart searching 
> about how to
> > ensure that only the right packets can exploit better 
> treatment from a
> > network (sub-text: only get what they paid for).  To do 
> this properly
> > seems to need two things:
> >
> > - The QoS protocol must be able to carry back to the end 
> host making the
> > request from each QoS domain, a seed for unforgeable tokens 
> which can be
> > attached to packets belonging to flow(s) which are to 
> exploit the QoS
> > path setup by the request.
> >
> > - The end host must be able to generate and attach suitable 
> unforgeable
> > tokens to each packet in a flow that should receive the requested
> > treatment, which may then be tested by each QoS domain 
> through which the
> > packet passes.
> >
> > Regards,
> > Elwyn
> >
> > 
> --------------------------------------------------------------
> -----------
> > ---------
> >
> > Elwyn B Davies
> >
> >         Routing and Addressing Strategy Prime
> >         Portfolio Integration                   Solutions Ready
> >
> >         Nortel Networks plc                     Email:
> > elwynd@nortelnetworks.com          Harlow Laboratories
> > ESN                     6-742-5498          London Road, Harlow,
> > Direct Line             +44-1279-405498          Essex, CM17 9NA, UK
> > Fax                     +44-1279-402047          Registered Office:
> > Maidenhead Office Park, Westacott Way,          Company No. 3937799
> > Maidenhead, Berkshire, SSL6 3QH
> > 
> --------------------------------------------------------------
> -----------
> > ---  This message may contain information proprietary to 
> Nortel Networks
> > plc so any  unauthorised disclosure, copying or distribution of its
> > contents is strictly prohibited.
> > 
> --------------------------------------------------------------
> -----------
> > ---  "The Folly is mostly mine"
> > and the opinions are mine and not those of my employer.
> > 
> ==============================================================
> ===========
> > =========
> >
> >
> >
> 
> 
> 
> --------------------------------------
> 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 Jan 29 04:55: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 EAA29013
	for <nsis-archive@odin.ietf.org>; Tue, 29 Jan 2002 04:55:02 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id EAA19667
	for nsis-archive@odin.ietf.org; Tue, 29 Jan 2002 04:55: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 EAA19341;
	Tue, 29 Jan 2002 04: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 EAA19312
	for <nsis@optimus.ietf.org>; Tue, 29 Jan 2002 04:45:22 -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 EAA28936
	for <nsis@ietf.org>; Tue, 29 Jan 2002 04:45:18 -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 g0T9jMj47674;
	Tue, 29 Jan 2002 10:45: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 7FDCFC05B; Tue, 29 Jan 2002 10:44:34 +0100 (CET)
Date: Tue, 29 Jan 2002 10:56:32 +0100
From: Marcus Brunner <brunner@ccrle.nec.de>
Reply-To: brunner@ccrle.nec.de
To: "Romascanu, Dan (Dan)" <dromasca@avaya.com>,
        "Georgios Karagiannis (ELN)" <Georgios.Karagiannis@eln.ericsson.se>
Cc: nsis@ietf.org
Message-ID: <3966553.1012301792@[192.168.102.79]>
In-Reply-To: <AAB4B3D3CF0F454F98272CBE187FDE2FF54154@IS0004AVEXU1.global.avaya.com>
References:  <AAB4B3D3CF0F454F98272CBE187FDE2FF54154@IS0004AVEXU1.global.avay
 a.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
Subject: [NSIS] RE: Independence of signalling and data path (was RE: [NSIS]
 Two		kindsof  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

However, I think today are enough means available to seperate control 
traffic from user traffic.

MArcus

--On Monday, January 28, 2002 3:50 PM +0200 "Romascanu, Dan (Dan)" 
<dromasca@avaya.com> wrote:

>> Thus, in GENERAL the path followed by signaling
>> messages and the path followed by user data packets (associated
>> to these signaling messages) MUST BE THE SAME!!
>>
>>
> Interestingly enough, I am right now involved in a thread in a different
> standards group, where customers (service providers) argue strongly that
> any control plane protocol should not consume bandwidth at the expense
> of the customer traffic. Their argument is that it is not possible to
> provide a coherent set of deterministic services if an non-deterministic
> amount of the customer bandwidth is consumed by the control plane.
>
> Regards,
>
> Dan
>



--------------------------------------
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 Jan 29 05:34: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 FAA29476
	for <nsis-archive@odin.ietf.org>; Tue, 29 Jan 2002 05:34:23 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id FAA21740
	for nsis-archive@odin.ietf.org; Tue, 29 Jan 2002 05:34:26 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA21128;
	Tue, 29 Jan 2002 05:24: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 FAA21059
	for <nsis@optimus.ietf.org>; Tue, 29 Jan 2002 05:24:43 -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 FAA29373
	for <nsis@ietf.org>; Tue, 29 Jan 2002 05:24:39 -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 g0TAOmj47919;
	Tue, 29 Jan 2002 11:24:48 +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 F39D1C05B; Tue, 29 Jan 2002 11:24:06 +0100 (CET)
Date: Tue, 29 Jan 2002 11:36:05 +0100
From: Marcus Brunner <brunner@ccrle.nec.de>
Reply-To: brunner@ccrle.nec.de
To: "Georgios Karagiannis (ELN)" <Georgios.Karagiannis@eln.ericsson.se>
Cc: nsis@ietf.org
Message-ID: <6339245.1012304165@[192.168.102.79]>
In-Reply-To: <E244E44D6AB85E40AEEF7EAABE3545FA8233CB@enleent104.nl.eu.ericsson.se>
References:  <E244E44D6AB85E40AEEF7EAABE3545FA8233CB@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: Independence of signalling and data path (was RE: [NSIS]
 Two			kindsof  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,

see inline

--On Monday, January 28, 2002 2:45 PM +0100 "Georgios Karagiannis (ELN)" 
<Georgios.Karagiannis@eln.ericsson.se> wrote:

> Hi Marcus
>
>
> [MB]>> So, I think you much in line with that req. The protocol
> [MB]>> from host to BB does not depend on the data path
> [MB}>> completly. What the constrain for the
> [MB]>> communication are is a different question.
>
> I will repeat what was already said in my previous e-mail:
>
> This is only true when the following CONSIDEARTIONS are
> fulfilled:
>
> * BB's or QoS controllers are used;

-> QoS controllers are no BBs in our understanding, the hop by hop 
signalling is a special case, where each hop has a QoS controller and QoS 
initiator functionality runing.

> * the end-host should know the address of the first hop Bandwidth Broker;

An end-host needs to know quite a bit of servers/nodes anyway. I even think 
there are solutions (e.g. AAA servers), where the first hop router is 
forwarding the signalling messages to the right place.

> * the BBs should be aware (know) the addresses of neighboring BBs;

Sure, you need interdoamin routing anyway.

> * BB's or QoS controllers should be able to relate
>    the QoS signaling to the data path;
>

yes true, I think this is the core functionality of a signalling protocol. 
Only depends on the information available in the signaling message.

>
>  In GENERAL the above CONSIDERATIONS are very difficult to
>  fulfill. Please note that we need a NSIS protocol that can
>  be applied for GENERAL cases. Of course YOUR
>  SCENARIO, but OTHER TYPES as well will be INCLUDED.
>

IMO, with the QoS initator and QoS controller framework we excaclty target 
a more general case then the hop-by-hop signalling.

> Thus, in GENERAL the path followed by signaling
> messages and the path followed by user data packets (associated
> to these signaling messages) MUST BE THE SAME!!
>

No, I do not agree.


>
> Solution on how signaling messages and user data
> packets can follow the same path:
> The signaling messages will
> follow the same path as the user data packets when for example,
> the IP destination address of the signaling messages is the same
> as the IP destination address of the user data packets.

Not necessarly (but normally packet with the same destination likely take 
the same path)

> Typical IP routing protocols will route both signaling messages
> and user data packets that have the same IP destination address through
> the same path. RSVPv1 uses something similar (on the PATH messages
> and user data packets having the same flow ID);
>
> [MB]>> And whether, the
> [MB]>> protocol work
> [MB]>> between ehost, eedge, ehop, all of them can be controllers
> [MB]>> and initiators
> [MB] on the other side. So they do not require data and signalling
> [MB] on the same path.
>
> What do you mean, would you like to have a NSIS protocol version
> that starts at one hop router and terminates at the next first hop router.
> This protocol will be very slow, very complex, and in my opinion
> not useful!
>

You have to be more specific on slow and complex.
If you mean with slow the signalling delay (I think you are better of not 
performing some actions in each hop)

The complextity in terms CPU heavily depends on the complexity of the state 
machine, which defionitly not defined yet. But you are definitly right, 
that it needs to be simple.

Marcus

>
> Best regards,
> Georgios
>
>
>
>
> -----Original Message-----
> From: Marcus Brunner [mailto:brunner@ccrle.nec.de]
> Sent: maandag 28 januari 2002 14:37
> To: Georgios Karagiannis (ELN)
> Cc: nsis@ietf.org
> Subject: RE: Independence of signalling and data path (was RE: [NSIS]
> Two kindsof requirements)
>
>
> Georgios,
>
> So, I think you much in line with that req. The protocol from host to BB
> does not depend on the data path completly. What the constrain for the
> communication are is a different question. And whether, the protocol work
> between ehost, eedge, ehop, all of them can be controllers and initiators
> on the other side. So they do not require data and signalling on the same
> path.
>
> Marcus
>
> --On Monday, January 28, 2002 1:32 PM +0100 "Georgios Karagiannis (ELN)"
> <Georgios.Karagiannis@eln.ericsson.se> wrote:
>
>> Hi Marcus
>>
>> Please see my comments/remarks in line:
>>
>> [MB]>> I am not sure, what exactly you mean by
>> [MB]>> the "host to proxy" version of the
>> [MB]>> protocol, but the main problem lies in mobil
>> [MB]>> environments, where I currently see a problem.
>>
>> Please let me explain how I see the QoS scenario
>> that you are thinking of by using the QoS framework that
>> was proposed by me some time ago.
>>
>>
>>          NSIS protocol              NSIS protocol       NSIS protocol
>>          (host - host)               (host - host)      (host - host)
>>| -----|   (first-part)
>>| |-----|(second-part)|-----|(third-part|-----|
>>| ehost|<-------------------->|ehost|<----------->|ehost|---------->|ehos
>>| t| -----|                      |-----|             |-----|
>>| |-----|
>>|     |                      |     |             |     |           | 
|
>>| -----|            |-----|   |-----|             |-----|
>>| |-----| eedge|            |eedge|   |eedge|             |eedge|
>>| |eedge| -----|            |-----|   |-----|             |-----|
>>| |-----|
>>|     |            |     |   |     |             |     |           | 
|
>>| -----|   |----|   |-----|   |-----|   |----|    |-----|   |----|
>>| |-----| ehop |   |ehop|   |ehop |   |ehop |   |ehop|    |ehop |
>>| |ehop|  |ehop | -----|   |----|   |-----|   |-----|   |----|    |-----|
>>| |----|  |-----|
>> end-host1 interior   edge      BB1      interior   BB2    interior
>> end-host2          w/in domain                   w/in domain       w/in
>> domain
>>
>>    ehost = everyhost
>>    eedge = everyedge
>>    ehop  = everyhop
>>
>> NSIS protocol (host - host): is a NSIS protocol version
>> that is:
>>   *  started at a host (could be an-end host or a
>>      Bandwidth Broker (BB))
>>   * terminated at a host (could be an-end host or a
>>      Bandwidth Broker (BB))
>>
>> In the above figure the end to end QoS signaling solution
>> is provided by three NSIS protocol parts.
>>   * the first-part is started at end-host1 and is
>>     terminated at BB1 (Note that the end-host1 must know the
>>     address of BB1);
>>   * the second-part is started at BB1 and is terminated
>>     at BB2(Note that the BB1 must know the
>>     address of BB2);
>>   * the third part is started at BB2 and is terminated at
>>     end-host2 (Note that the BB2 must know the
>>     address of endhost2);
>>
>>
>> For this scenario the NSIS protocol decomposition is as follows:
>>
>>  * A "host" could be an end host or a Bandwidth Broker (BB).
>>    It can process and use the "everyhost", "everyedge", and "everyhop"
>>    protocol components. However, in this scenario (that uses BBs),
>>    the "everyedge" and "everyhop" components may not be used.
>>    Therefore the QoS framework
>>    will look as depicted in figure above.
>>
>>  * An "edge" can be a Diffserv edge, MPLS edge, etc.  It can
>>    process and use the "everyedge", and "everyhop" protocol
>>    components. However, in this scenario (that uses BBs),
>>    the "everyedge" and "everyhop" components may not be
>>    used (or checked), since they will
>>    be  not set (e.g., empty).
>>    The "everyhost" protocol component is not
>>    processed (used or checked) but is carried onward.
>>
>>  * An "interior within domain" can be any router within
>>    a domain.  It can process and use only the "everyhop"
>>    protocol component. However, in this scenario
>>    (that uses BBs), "everyhop" component may not be
>>    used (or checked), since it will
>>    be not set (e.g., empty). The "everyhost" and "everyedge"
>>    protocol components are not processed (used or checked)
>>    but are carried onward.
>>
>>
>> PLEASE NOTE that in my opinion, this scenario is only useful
>> when you will consider that:
>> * BB's or QoS controllers are used;
>> * the end-host should know the address of the first hop Bandwidth Broker;
>> * the BBs should be aware (know) the addresses of neighboring BBs;
>> * BB's or QoS controllers should be able to relate
>>   the QoS signaling to the data path;
>>
>>
>> In general the above considerations are very difficult to
>> fulfill. Please note that we need a NSIS protocol that can
>> be applied in general. Of course your
>> scenario, but other types as well will be included.
>>
>> I think that the example explained above
>> is providing a possible solution to your problem.
>>
>> [MB] What is in your opinion the problem of requiring
>> [MB] independent signalling and data pathes?
>>
>> First of all: I will just try to explain what this independence means.
>> It means that the NSIS signaling messages my follow a different path
>> then the user data packets (associated to these NSIS signaling
>> messages).
>>
>> Second:  the problem of this independence is that the NSIS protocol
>> in most of the cases is useless.
>> Thus, for example, if the NSIS signaling messages will
>> signal QoS information to an edge node, and the user
>> data packets (associated to this QoS information)
>> will not pass through the same edge node, then
>> the NSIS protocol in most of the cases is useless.
>>
>> Please note that when the signaling path is independent than
>> the user data path, then the NSIS protocol will only be useful
>> when:
>>
>> * BB's or QoS controllers are used;
>> * the end-host should know the address of the first hop Bandwidth Broker;
>> * the BBs should be aware (know) the addresses of neighbouring BBs;
>> * BB's or QoS controllers should be able to relate
>>   the QoS signalling to the data path;
>>
>>
>> Solution on how signaling messages and user data
>> packets can follow the same path:
>> The signaling messages will
>> follow the same path as the user data packets when for example,
>> the IP destination address of the signaling messages is the same
>> as the IP destination address of the user data packets.
>> Typical IP routing protocols will route both signaling messages
>> and user data packets that have the same IP destination address through
>> the same path. RSVPv1 uses something similar (on the PATH messages
>> and user data packets having the same flow ID);
>>
>>
>>
>> Best regards,
>> Georgios
>>
>>
>> -----Original Message-----
>> From: Marcus Brunner [mailto:brunner@ccrle.nec.de]
>> Sent: maandag 28 januari 2002 12:04
>> To: Georgios Karagiannis (ELN); 'fu@ee.tu-berlin.de'
>> Cc: nsis@ietf.org
>> Subject: RE: Independence of signalling and data path (was RE: [NSIS]
>> Two kindsof requirements)
>>
>>
>> Georgios,
>>
>> I am not sure, what exactly you mean by the "host to proxy" version of
>> the  protocol, but the main problem lies in mobil environments, where I
>> currently see a problem.
>>
>> What is in your opinion the problem of requiring independent signalling
>> and  data pathes?
>>
>> Marcus
>>
>> --On Monday, January 28, 2002 9:52 AM +0100 "Georgios Karagiannis (ELN)"
>> <Georgios.Karagiannis@eln.ericsson.se> wrote:
>>
>>> Hi Xiaoming and Marcus
>>>
>>> If you would like to have a QoS communication between a
>>> QoS initiator and a QoS controller you could
>>> then use the "host to proxy" version of the NSIS protocol.
>>>
>>> You could then accomplish exactly the same functionality
>>> without requiring that the signaling path is independent from
>>> the data path.
>>>
>>> Best regards,
>>> Georgios
>>>
>>> -----Original Message-----
>>> From: Xiaoming Fu [mailto:fu@ee.tu-berlin.de]
>>> Sent: vrijdag 25 januari 2002 19:40
>>> To: brunner@ccrle.nec.de
>>> Cc: Georgios Karagiannis (ELN); nsis@ietf.org
>>> Subject: Re: Independence of signalling and data path (was RE: [NSIS]
>>> Two kindsof requirements)
>>>
>>>
>>> Marcus,
>>>
>>> Marcus Brunner wrote:
>>>>
>>>> I you want to see SIP in you can sure. But that was our intention.
>>>>
>>>> I  personally think, that the signalling path should not be bound to
>>>> the data path. Whether you need to know the location of the QoS
>>>> controller heavility depends on the specific protocols defined (and
>>>> might be regard implementation dependent)
>>>
>>> Yeap. e.g., when BB is used signaling may be needed between BBs of
>>> adjacent  QoS domains.	
>>>
>>> Xiaoming
>>>
>>>>
>>>> Marcus
>>>>
>>>> --On Friday, January 25, 2002 5:04 PM +0100 "Georgios Karagiannis
>>>> (ELN)" <Georgios.Karagiannis@eln.ericsson.se> wrote:
>>>>
>>>> > Hi Marcus
>>>> >
>>>> > yes, but from what I understood from your draft
>>>> > you assume that the QoS initiator will have to know the
>>>> > location of the QoS controller and that the
>>>> > signaling path may follow a different path than
>>>> > the user data. It seems SIP to me.
>>>> >
>>>> > Best Regards,
>>>> > Georgios
>>>> >
>>>> >
>>>> > -----Original Message-----
>>>> > From: Marcus Brunner [mailto:brunner@ccrle.nec.de]
>>>> > Sent: vrijdag 25 januari 2002 17:09
>>>> > To: Georgios Karagiannis (ELN); 'Schneider, Marco'
>>>> > Cc: nsis@ietf.org
>>>> > Subject: RE: [NSIS] Two kinds of requirements
>>>> >
>>>> >
>>>> > Looks nice for fixed network. However, as soon as mobility is
>>>> > involved it gets more difficult. That was the reason that in our
>>>> > framewrok we talk about QoS initiator and QoS controller, instead of
>>>> > teh componenets where the componenets are sitting (which we find not
>>>> > really relevant)
>>>> >
>>>> > Marcus
>>>> >
>>>> > --On Tuesday, January 22, 2002 10:39 AM +0100 "Georgios Karagiannis
>>>> > (ELN)"  <Georgios.Karagiannis@eln.ericsson.se> wrote:
>>>> >
>>>> >> Hi Marco
>>>> >>
>>>> >> The possible NSIS protocol components that can be
>>>> >> used on the different NSIS protocol types are the following:
>>>> >>
>>>> >>  * used components in "end host to end host" NSIS scenario:
>>>> >>       [everyhost], [everyedge], [everyhop]
>>>> >>
>>>> >>  * used components in "end host to proxy" NSIS scenario:
>>>> >>       [everyhost], [everyedge], [everyhop]
>>>> >>
>>>> >>  * used components in "end host to edge" NSIS scenario:
>>>> >>       [everyedge], [everyhop]
>>>> >>
>>>> >>  * used components in "edge to edge" NSIS scenario:
>>>> >>       [everyedge], [everyhop]
>>>> >>
>>>> >> Regarding the priority, we should decide it after the requirements,
>>>> >> architecture and framework drafts are done!
>>>> >>
>>>> >> Best regards,
>>>> >> Georgios
>>>> >>
>>>> >> -----Original Message-----
>>>> >> From: Schneider, Marco [mailto:schneider@tri.sbc.com]
>>>> >> Sent: dinsdag 22 januari 2002 1:03
>>>> >> To: 'Georgios Karagiannis (ELN)'; 'dick.rr.knight@bt.com'
>>>> >> Cc: nsis@ietf.org
>>>> >> Subject: RE: [NSIS] Two kinds of requirements
>>>> >>
>>>> >>
>>>> >> Hi Georgios, All
>>>> >>
>>>> >> If by x -- y you mean a protocol that runs directly between x and y
>>>> >> (e.g. end host -- end host, end host -- proxy...) then strictly
>>>> >> speaking we are discussing four  functionally distinct interfaces
>>>> >> and thus four functionally distinct protocols(possibly three if we
>>>> >> group end host -- proxy and  end host -- edge together). In my
>>>> >> opinion: First we need to decide which of these interfaces are in
>>>> >> scope. Second we need to decide which one(s) we will address first.
>>>> >> Third we need to define the requirements for each for each of the
>>>> >> interfaces independently.
>>>> >>
>>>> >> With respect to scope and priority, I think we need to address in
>>>> >> order: 1) end host -- edge/proxy
>>>> >> 2) domain edge -- domain edge
>>>> >>
>>>> >>
>>>> >> Marco
>>>> >>
>>>> >>
>>>> >> -----Original Message-----
>>>> >> From: Georgios Karagiannis (ELN)
>>>> >> [mailto:Georgios.Karagiannis@eln.ericsson.se]
>>>> >> Sent: Monday, January 21, 2002 4:30 AM
>>>> >> To: 'dick.rr.knight@bt.com'
>>>> >> Cc: nsis@ietf.org
>>>> >> Subject: RE: [NSIS] Two kinds of requirements
>>>> >>
>>>> >>
>>>> >>
>>>> >> Hi Dick
>>>> >>
>>>> >> Please see my comment in line:
>>>> >> [DK]>> I do agree that it need not be processed on a per hop basis
>>>> >> as it can [DK]>> transverse a domain with a single QoS mechanism.
>>>> >> That mechanism, be it
>>>> >> [DK]>> diffserv or intserv, PNNI, RSVP, or even over-provisioning,
>>>> >> takes care of
>>>> >> [DK]>> the policing and the "path" establishment within the domain.
>>>> >>
>>>> >> Please note that at the moment there are scenarios that will need to
>>>> >> process the [everyhop] component. Some of these scenarios are the
>>>> >> Radio Access
>>>> >> Network and Mobile IP,..
>>>> >> Therefore, the [everyhop] component should be supported by the NSIS
>>>> >> protocol.
>>>> >> However a "host" or a "edge" should be able to activated or not.
>>>> >>
>>>> >> Furthermore, in my opinion the NSIS protocol should be:
>>>> >> end host - end host: the NSIS protocol is terminated at end hosts;
>>>> >> end host - proxy: the NSIS protocol is terminated at end host and
>>>> >> proxy; end host - edge: the NSIS protocol is terminated at end end
>>>> >> host and edge; edge - edge: the NSIS protocol is terminated at egdes
>>>> >> of one/multiple domains;
>>>> >>
>>>> >>
>>>> >> Best regards,
>>>> >> Georgios
>>>> >>
>>>> >>
>>>> >> -----Original Message-----
>>>> >> From: Schneider, Marco [mailto:schneider@tri.sbc.com]
>>>> >> Sent: 18 January 2002 20:10
>>>> >> To: 'Roy, Radhika R, ALASO'; Gary Kenward; Loughney John
>>>> >> (NRC/Helsinki); brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
>>>> >> dick.rr.knight@bt.com
>>>> >> Cc: nsis@ietf.org
>>>> >> Subject: RE: [NSIS] Two kinds of requirements
>>>> >>
>>>> >>
>>>> >> Hi Roy,
>>>> >>
>>>> >> Below is the original text from your reponse to Gary Kenward.
>>>> >> Hopefully the context is clear.
>>>> >>
>>>> >> "[Roy, Radhika R, ALARC]  I would say that it is the QOS needs of
>>>> >> the application (e.g., SIP-based VoIP) that the user likes to
>>>> >> express (as opposed to "service"). Similarly, instead of network
>>>> >> services, we would say network layer QOS services (e.g., RSVP,
>>>> >> DiffServ, MPLS). We would develop the end-to-end (application
>>>> >> layer) QOS signaling protocol (say, NSIS QOS). Now, there needs to
>>>> >> have some kinds of standards how NSIS QOS will be mapped over RSVP,
>>>> >> DiffServ, MPLS, etc."
>>>> >>
>>>> >> So by End-to-End you mean between directly between two "users". This
>>>> >> is session level signaling and I don't believe the signaling part is
>>>> >> within the scope of this working group. An application level QOS
>>>> >> specification may be.
>>>> >>
>>>> >> After a session level agreement on QOS, the host/client/customer
>>>> >> will need to signal an actual reservation request to the network
>>>> >> for the necessary QOS agreed to at the session level. This is the
>>>> >> protocol that we need to work on.
>>>> >>
>>>> >> This approach is discussed in the SIP draft "SIP Extensions for
>>>> >> Media Authorization" (draft-ietf-sip-call-auth-03.txt) and the RAP
>>>> >> draft "Framework for session set-up with media authorization"
>>>> >> (draft-ietf-rap-session-auth-02.txt).
>>>> >>
>>>> >> Marco Schneider
>>>> >>
>>>> >> -----Original Message-----
>>>> >> From: Roy, Radhika R, ALASO [mailto:rrroy@att.com]
>>>> >> Sent: Friday, January 18, 2002 9:18 AM
>>>> >> To: Schneider, Marco; Gary Kenward; Loughney John (NRC/Helsinki);
>>>> >> brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
>>>> >> dick.rr.knight@bt.com
>>>> >> Cc: nsis@ietf.org
>>>> >> Subject: RE: [NSIS] Two kinds of requirements
>>>> >>
>>>> >>
>>>> >> Defined below [RRR]
>>>> >>
>>>> >> -----Original Message-----
>>>> >> From: Schneider, Marco [mailto:schneider@tri.sbc.com]
>>>> >> Sent: Thursday, January 17, 2002 8:47 PM
>>>> >> To: Roy, Radhika R, ALASO; Gary Kenward; Loughney John
>>>> >> (NRC/Helsinki); brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
>>>> >> dick.rr.knight@bt.com
>>>> >> Cc: nsis@ietf.org
>>>> >> Subject: RE: [NSIS] Two kinds of requirements
>>>> >>
>>>> >>
>>>> >> Hi Roy,
>>>> >>
>>>> >> Can you please define what you mean by "End-to-End Application Layer
>>>> >> QOS Signaling". Thanks.
>>>> >>
>>>> >> [RRR] Suppose an user is initiation a SIP call to another user with
>>>> >> audio, video, and data. The use needs to express the needs of QOS
>>>> >> for audio, video, and data to another user.
>>>> >>
>>>> >> [RRR] The signaling mechanism that allows to express the QOS
>>>> >> parameters of audio, video, and data is termed as the "End-to-End
>>>> >> Application Layer QOS Signaling."
>>>> >>
>>>> >> Marco Schneider
>>>> >>
>>>> >> _______________________________________________
>>>> >> 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
>>>> >>
>>>> >
>>>> >
>>>> >
>>>> > --------------------------------------
>>>> > Dr. Marcus Brunner
>>>> > Network Laboratories
>>>> > NEC Europe Ltd.
>>>> >
>>>> > E-Mail: brunner@ccrle.nec.de
>>>> > WWW:    http://www.ccrle.nec.de/
>>>> > personal home page: http://www.brubers.org/marcus
>>>> >
>>>> >
>>>> > _______________________________________________
>>>> > nsis mailing list
>>>> > nsis@ietf.org
>>>> > https://www1.ietf.org/mailman/listinfo/nsis
>>>> >
>>>>
>>>> --------------------------------------
>>>> Dr. Marcus Brunner
>>>> Network Laboratories
>>>> NEC Europe Ltd.
>>>>
>>>> E-Mail: brunner@ccrle.nec.de
>>>> WWW:    http://www.ccrle.nec.de/
>>>> personal home page: http://www.brubers.org/marcus
>>>>
>>>> _______________________________________________
>>>> nsis mailing list
>>>> nsis@ietf.org
>>>> https://www1.ietf.org/mailman/listinfo/nsis
>>>
>>
>>
>>
>> --------------------------------------
>> Dr. Marcus Brunner
>> Network Laboratories
>> NEC Europe Ltd.
>>
>> E-Mail: brunner@ccrle.nec.de
>> WWW:    http://www.ccrle.nec.de/
>> personal home page: http://www.brubers.org/marcus
>>
>
>
>
> --------------------------------------
> Dr. Marcus Brunner
> Network Laboratories
> NEC Europe Ltd.
>
> E-Mail: brunner@ccrle.nec.de
> WWW:    http://www.ccrle.nec.de/
> personal home page: http://www.brubers.org/marcus
>



--------------------------------------
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 Jan 29 05:47: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 FAA29622
	for <nsis-archive@odin.ietf.org>; Tue, 29 Jan 2002 05:47:21 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id FAA22169
	for nsis-archive@odin.ietf.org; Tue, 29 Jan 2002 05:47: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 FAA21919;
	Tue, 29 Jan 2002 05:38: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 FAA21885
	for <nsis@optimus.ietf.org>; Tue, 29 Jan 2002 05:38:12 -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 FAA29521
	for <nsis@ietf.org>; Tue, 29 Jan 2002 05:38:07 -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 g0TAcCj48003;
	Tue, 29 Jan 2002 11:38:12 +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 D1E63C05B; Tue, 29 Jan 2002 11:37:30 +0100 (CET)
Date: Tue, 29 Jan 2002 11:49:29 +0100
From: Marcus Brunner <brunner@ccrle.nec.de>
Reply-To: brunner@ccrle.nec.de
To: Glenn Morrow <gmorrow@nortelnetworks.com>,
        "Georgios Karagiannis (ELN)" <Georgios.Karagiannis@eln.ericsson.se>,
        "'fu@ee.tu-berlin.de'" <fu@ee.tu-berlin.de>
Cc: nsis@ietf.org
Subject: RE: [NSIS] RE: Independence of signalling and data path (was RE:
 	[NSIS] Two	kindsof  requirements)
Message-ID: <7143051.1012304969@[192.168.102.79]>
In-Reply-To: <933FADF5E673D411B8A30002A5608A0E01B4E80B@zrc2c012.us.nortel.com>
References:  <933FADF5E673D411B8A30002A5608A0E01B4E80B@zrc2c012.us.nortel.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



--On Monday, January 28, 2002 11:09 AM -0600 Glenn Morrow 
<gmorrow@nortelnetworks.com> wrote:

>
> Marcus,
>
> Here is my opinion on the path-directed or separation question.
>
> It seems to me that some parts of the network will benefit from separate
> paths for signaling and bearer data; whereas other parts will not benefit
> and will actually be complicated by such a separation.

Glenn, I am not argueing to seperate it always, but for the freedom to 
seperate, depending on the circumstances. As you said a network might 
profit. There also scenarios especially in mobile environamnts and for fast 
re-routing to backup path (with QoS) which some technologies do.

>
> The parts that could benefit from a separation are expensive shared media
> hops such as cellular and perhaps cable.
>
> The parts that will not benefit in my opinion is everything else. If
> signaling does not follow the path then the signaling nodes will have to
> know a great deal of information about routes and routing policies. They
> will have to be disclosed either via configuration or cross signaling,
> the routing tables, LSPs, VCs, policies and updates. This seems to create
> a rather large mess in terms of administrative costs, race conditions,
> mismatches in policy and routes between routers and these controllers
> etc..
>

Knowing about the network in needed anyway thats way we have routing 
protocols running etc.

> Mandatory separation would also eliminate the ability to bundle or
> piggyback signaling with bearer data.
>

I think I am more saying unifying in niot mandatory.

> Sometimes it is beneficial to separate and sometimes it is not. The
> architecture could allow for both at different parts of the network;
> however, I think the separation is a specific layer 2 optimization issue;
> whereas path-directed would be more geared to a general solution for the
> connectionless network problem space.
>

Exactly, I would like to be open for different solutions.

Marcus

> Glenn



--------------------------------------
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 Jan 29 12:58: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 MAA11409
	for <nsis-archive@odin.ietf.org>; Tue, 29 Jan 2002 12:58:47 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id MAA17978
	for nsis-archive@odin.ietf.org; Tue, 29 Jan 2002 12:58: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 MAA17497;
	Tue, 29 Jan 2002 12:48: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 MAA17467
	for <nsis@optimus.ietf.org>; Tue, 29 Jan 2002 12:48:45 -0500 (EST)
Received: from arb-exchange1.cetaceannetworks.com ([63.127.199.209])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11031
	for <nsis@ietf.org>; Tue, 29 Jan 2002 12:48:43 -0500 (EST)
Received: by mail.cetaceannetworks.com with Internet Mail Service (5.5.2653.19)
	id <DWXB7MS1>; Tue, 29 Jan 2002 12:45:29 -0500
Message-ID: <6D8664171C38D511B5AD0002B325CE6633ECB7@mail.cetaceannetworks.com>
From: "Freytsis, Ilya" <ifreytsis@cetacean.com>
To: "'brunner@ccrle.nec.de'" <brunner@ccrle.nec.de>
Cc: "'nsis@ietf.org'" <nsis@ietf.org>
Subject: [NSIS] RE: Independence of signalling and data path 
Date: Tue, 29 Jan 2002 12:45:26 -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

Marcus, 

Let me add my 2cents into this discussion:

It looks to me that this discussion got very heated because it is at the
very border between general QoS signaling and specific QoS technology in use
(by the domain). The fact that you mentioned such terms as "Controller" and
"BB" indicates to me that you have a particular technology in mind that
based on this kind of entities. Tell me how the node at the edge of the RSVP
or DiffServe domain can get such an idea as a BB that governs the
neighboring domain. On the other hand the framework advocated by Georgios
somewhat implies the use of the hop-by-hop QoS technology (and probably for
this reason is opposed by some people including myself) that relies on
signaling and data path being the same.
The way to resolve this conflict in my mind is something along the following
lines:
1. The general NSIS signaling being used between the host and the edge and
between the edges of the neighboring domains (based on different QoS
technology) should follow the same path as data (or lay out the path for the
data if you wish).
2. It is up to the edge nodes that understand used within domain QoS
technology to communicate to the BB or controller and translate NSIS generic
signaling into something specific for this domain. Obviously the generic
NSIS signaling has to be recreated at the domain egress edge.
3. In this scenario the host can be enabled with the particular QoS
technology and use specific signaling for communication with the first
domain or can use generic NSIS signaling.
4. The communication between neighboring domains using the same QoS
technology can be done in the specific for the technology fashion though
translation to NSIS and back will be always available if for whatever reason
those domains prefer it.

In other words I am suggesting the following global analogy: 
If you view the domain with a QoS technology as a virtual router than NSIS
signaling used between those routers follows the same path as data. What
happens within the router is not a NSIS business.

Ilya Freytsis

Date: Tue, 29 Jan 2002 11:36:05 +0100
From: Marcus Brunner <brunner@ccrle.nec.de>
Reply-To: brunner@ccrle.nec.de
To: "Georgios Karagiannis (ELN)" <Georgios.Karagiannis@eln.ericsson.se>
Cc: nsis@ietf.org
n.se>
Subject: [NSIS] RE: Independence of signalling and data path (was RE: [NSIS]
Two			kindsof  requirements)

Georgios,

see inline

--On Monday, January 28, 2002 2:45 PM +0100 "Georgios Karagiannis (ELN)" 
<Georgios.Karagiannis@eln.ericsson.se> wrote:

> Hi Marcus
>
>
> [MB]>> So, I think you much in line with that req. The protocol
> [MB]>> from host to BB does not depend on the data path
> [MB}>> completly. What the constrain for the
> [MB]>> communication are is a different question.
>
> I will repeat what was already said in my previous e-mail:
>
> This is only true when the following CONSIDEARTIONS are
> fulfilled:
>
> * BB's or QoS controllers are used;

-> QoS controllers are no BBs in our understanding, the hop by hop 
signalling is a special case, where each hop has a QoS controller and QoS 
initiator functionality runing.

> * the end-host should know the address of the first hop Bandwidth Broker;

An end-host needs to know quite a bit of servers/nodes anyway. I even think 
there are solutions (e.g. AAA servers), where the first hop router is 
forwarding the signalling messages to the right place.

> * the BBs should be aware (know) the addresses of neighboring BBs;

Sure, you need interdoamin routing anyway.

> * BB's or QoS controllers should be able to relate
>    the QoS signaling to the data path;
>

yes true, I think this is the core functionality of a signalling protocol. 
Only depends on the information available in the signaling message.

>
>  In GENERAL the above CONSIDERATIONS are very difficult to
>  fulfill. Please note that we need a NSIS protocol that can
>  be applied for GENERAL cases. Of course YOUR
>  SCENARIO, but OTHER TYPES as well will be INCLUDED.
>

IMO, with the QoS initator and QoS controller framework we excaclty target 
a more general case then the hop-by-hop signalling.

> Thus, in GENERAL the path followed by signaling
> messages and the path followed by user data packets (associated
> to these signaling messages) MUST BE THE SAME!!
>

No, I do not agree.


>
> Solution on how signaling messages and user data
> packets can follow the same path:
> The signaling messages will
> follow the same path as the user data packets when for example,
> the IP destination address of the signaling messages is the same
> as the IP destination address of the user data packets.

Not necessarly (but normally packet with the same destination likely take 
the same path)

> Typical IP routing protocols will route both signaling messages
> and user data packets that have the same IP destination address through
> the same path. RSVPv1 uses something similar (on the PATH messages
> and user data packets having the same flow ID);
>
> [MB]>> And whether, the
> [MB]>> protocol work
> [MB]>> between ehost, eedge, ehop, all of them can be controllers
> [MB]>> and initiators
> [MB] on the other side. So they do not require data and signalling
> [MB] on the same path.
>
> What do you mean, would you like to have a NSIS protocol version
> that starts at one hop router and terminates at the next first hop router.
> This protocol will be very slow, very complex, and in my opinion
> not useful!
>

You have to be more specific on slow and complex.
If you mean with slow the signalling delay (I think you are better of not 
performing some actions in each hop)

The complextity in terms CPU heavily depends on the complexity of the state 
machine, which defionitly not defined yet. But you are definitly right, 
that it needs to be simple.

Marcus

>
> Best regards,
> Georgios
>
>
>
>


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



From daemon@optimus.ietf.org  Tue Jan 29 13:36: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 NAA13046
	for <nsis-archive@odin.ietf.org>; Tue, 29 Jan 2002 13:36:00 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id NAA21088
	for nsis-archive@odin.ietf.org; Tue, 29 Jan 2002 13:36: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 NAA20090;
	Tue, 29 Jan 2002 13:25: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 NAA20055
	for <nsis@optimus.ietf.org>; Tue, 29 Jan 2002 13:25:08 -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 NAA12517
	for <nsis@ietf.org>; Tue, 29 Jan 2002 13:25:05 -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 g0TIRGT09956;
	Tue, 29 Jan 2002 12:27:16 -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 g0TIOT224916;
	Tue, 29 Jan 2002 12:24:29 -0600 (CST)
Received: by TRIMAIL2.ad.tri.sbc.com with Internet Mail Service (5.5.2653.19)
	id <ZND3JV6W>; Tue, 29 Jan 2002 12:24:57 -0600
Message-ID: <905A1C4ABF353F4C8CC16FA9F53DD0D6322452@TRIMAIL2.ad.tri.sbc.com>
From: "Chen, Weijing" <wchen@tri.sbc.com>
To: "'Freytsis, Ilya'" <ifreytsis@cetacean.com>,
        "'brunner@ccrle.nec.de'"
	 <brunner@ccrle.nec.de>
Cc: "'nsis@ietf.org'" <nsis@ietf.org>
Subject: RE: [NSIS] RE: Independence of signalling and data path 
Date: Tue, 29 Jan 2002 12:24:52 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: nsis-admin@ietf.org
Errors-To: nsis-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Next Steps in Signaling <nsis.ietf.org>
X-BeenThere: nsis@ietf.org

Very well put, Ilya.


--
Weijing Chen
SBC Technology Resources
9505 Arboretum Blvd.
Austin, TX 78759
512 372 5710
wchen@tri.sbc.com



-----Original Message-----
From: Freytsis, Ilya [mailto:ifreytsis@cetacean.com] 
Sent: Tuesday, January 29, 2002 11:45 AM
To: 'brunner@ccrle.nec.de'
Cc: 'nsis@ietf.org'
Subject: [NSIS] RE: Independence of signalling and data path 

Marcus, 

Let me add my 2cents into this discussion:

It looks to me that this discussion got very heated because it is at the
very border between general QoS signaling and specific QoS technology in use
(by the domain). The fact that you mentioned such terms as "Controller" and
"BB" indicates to me that you have a particular technology in mind that
based on this kind of entities. Tell me how the node at the edge of the RSVP
or DiffServe domain can get such an idea as a BB that governs the
neighboring domain. On the other hand the framework advocated by Georgios
somewhat implies the use of the hop-by-hop QoS technology (and probably for
this reason is opposed by some people including myself) that relies on
signaling and data path being the same.
The way to resolve this conflict in my mind is something along the following
lines:
1. The general NSIS signaling being used between the host and the edge and
between the edges of the neighboring domains (based on different QoS
technology) should follow the same path as data (or lay out the path for the
data if you wish).
2. It is up to the edge nodes that understand used within domain QoS
technology to communicate to the BB or controller and translate NSIS generic
signaling into something specific for this domain. Obviously the generic
NSIS signaling has to be recreated at the domain egress edge.
3. In this scenario the host can be enabled with the particular QoS
technology and use specific signaling for communication with the first
domain or can use generic NSIS signaling.
4. The communication between neighboring domains using the same QoS
technology can be done in the specific for the technology fashion though
translation to NSIS and back will be always available if for whatever reason
those domains prefer it.

In other words I am suggesting the following global analogy: 
If you view the domain with a QoS technology as a virtual router than NSIS
signaling used between those routers follows the same path as data. What
happens within the router is not a NSIS business.

Ilya Freytsis

Date: Tue, 29 Jan 2002 11:36:05 +0100
From: Marcus Brunner <brunner@ccrle.nec.de>
Reply-To: brunner@ccrle.nec.de
To: "Georgios Karagiannis (ELN)" <Georgios.Karagiannis@eln.ericsson.se>
Cc: nsis@ietf.org
n.se>
Subject: [NSIS] RE: Independence of signalling and data path (was RE: [NSIS]
Two			kindsof  requirements)

Georgios,

see inline

--On Monday, January 28, 2002 2:45 PM +0100 "Georgios Karagiannis (ELN)" 
<Georgios.Karagiannis@eln.ericsson.se> wrote:

> Hi Marcus
>
>
> [MB]>> So, I think you much in line with that req. The protocol
> [MB]>> from host to BB does not depend on the data path
> [MB}>> completly. What the constrain for the
> [MB]>> communication are is a different question.
>
> I will repeat what was already said in my previous e-mail:
>
> This is only true when the following CONSIDEARTIONS are
> fulfilled:
>
> * BB's or QoS controllers are used;

-> QoS controllers are no BBs in our understanding, the hop by hop 
signalling is a special case, where each hop has a QoS controller and QoS 
initiator functionality runing.

> * the end-host should know the address of the first hop Bandwidth Broker;

An end-host needs to know quite a bit of servers/nodes anyway. I even think 
there are solutions (e.g. AAA servers), where the first hop router is 
forwarding the signalling messages to the right place.

> * the BBs should be aware (know) the addresses of neighboring BBs;

Sure, you need interdoamin routing anyway.

> * BB's or QoS controllers should be able to relate
>    the QoS signaling to the data path;
>

yes true, I think this is the core functionality of a signalling protocol. 
Only depends on the information available in the signaling message.

>
>  In GENERAL the above CONSIDERATIONS are very difficult to
>  fulfill. Please note that we need a NSIS protocol that can
>  be applied for GENERAL cases. Of course YOUR
>  SCENARIO, but OTHER TYPES as well will be INCLUDED.
>

IMO, with the QoS initator and QoS controller framework we excaclty target 
a more general case then the hop-by-hop signalling.

> Thus, in GENERAL the path followed by signaling
> messages and the path followed by user data packets (associated
> to these signaling messages) MUST BE THE SAME!!
>

No, I do not agree.


>
> Solution on how signaling messages and user data
> packets can follow the same path:
> The signaling messages will
> follow the same path as the user data packets when for example,
> the IP destination address of the signaling messages is the same
> as the IP destination address of the user data packets.

Not necessarly (but normally packet with the same destination likely take 
the same path)

> Typical IP routing protocols will route both signaling messages
> and user data packets that have the same IP destination address through
> the same path. RSVPv1 uses something similar (on the PATH messages
> and user data packets having the same flow ID);
>
> [MB]>> And whether, the
> [MB]>> protocol work
> [MB]>> between ehost, eedge, ehop, all of them can be controllers
> [MB]>> and initiators
> [MB] on the other side. So they do not require data and signalling
> [MB] on the same path.
>
> What do you mean, would you like to have a NSIS protocol version
> that starts at one hop router and terminates at the next first hop router.
> This protocol will be very slow, very complex, and in my opinion
> not useful!
>

You have to be more specific on slow and complex.
If you mean with slow the signalling delay (I think you are better of not 
performing some actions in each hop)

The complextity in terms CPU heavily depends on the complexity of the state 
machine, which defionitly not defined yet. But you are definitly right, 
that it needs to be simple.

Marcus

>
> Best regards,
> Georgios
>
>
>
>


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

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



From daemon@ns.ietf.org  Tue Jan 29 16:42: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 QAA21728
	for <nsis-archive@odin.ietf.org>; Tue, 29 Jan 2002 16:42:01 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id QAA01807
	for nsis-archive@odin.ietf.org; Tue, 29 Jan 2002 16:42: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 QAA00570;
	Tue, 29 Jan 2002 16:25: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 QAA00539
	for <nsis@ns.ietf.org>; Tue, 29 Jan 2002 16:25:21 -0500 (EST)
Received: from sierra.seas.upenn.edu (root@sierra.seas.upenn.edu [158.130.64.180])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21316
	for <nsis@ietf.org>; Tue, 29 Jan 2002 16:25:17 -0500 (EST)
Received: from cs.columbia.edu (DHCP64-23.SEAS.UPENN.EDU [158.130.64.102])
	by sierra.seas.upenn.edu (8.9.3/8.9.3) with ESMTP id QAA04168;
	Tue, 29 Jan 2002 16:25:14 -0500 (EST)
Message-ID: <3C571341.6080902@cs.columbia.edu>
Date: Tue, 29 Jan 2002 16:25:21 -0500
From: Paulo Mendes <mendes@cs.columbia.edu>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1
X-Accept-Language: en-us
MIME-Version: 1.0
To: Ping Pan <pingpan@juniper.net>
CC: fu@ee.tu-berlin.de, David.Partain@ericsson.com, NSIS <nsis@ietf.org>
Subject: Re: [NSIS] Framework & requirements part of the "Two kinds of  requirements" thread
References: <0GQD001M6YBEYP@mbb1.ericsson.se> <3C4EF853.B10F8796@ee.tu-berlin.de> <3C4F0560.20508@juniper.net> <3C508301.7040206@cs.columbia.edu> <3C50942E.3080104@juniper.net>
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 Ping

Sorry the delayed answer... Comments are below [PM]

Ping Pan wrote:

> Paulo,
> 
> How are you!

 >
 >

> Paulo Mendes wrote:
> 
>>> Also, let's be careful with adaptive applications. They look very 
>>> nice on paper, but when you see what type of switches are used 
>>> interfacing between voice networks and the Internet, you gotta be 
>>> kidding me to insist on adaptiveness for your traffic....
>>
>>
>>
>>
>> [PM] I don't know about others, but when I speak about adaptive 
>> applications I'm thinking of 100% IP networks.
>>
> 
> 
> The problem is that much of the voice traffic flowing over the Internet 
> has nothing to do with the native Internet applications. Many providers 
> setup tunnels through their backbones and transport non-IP packets. The 
> access points are not pure IP boxes. They may be some ancient and 
> expensive Luent switches. If you ask the switches to run some fancy 
> adaptive schemes to all the traffic, they may crash.


I don't see the point of this example.. If a provider wants to setup 
tunnels to transport non-IP traffic between non-IP applications using 
not pure IP access points, that is not a concern of the IP world...


>>> Currently, most of the backbone networks are over-provisioned, so no 
>>> serious signaling is required yet. End-to-end signaling is very 
>>> attractive to the end users, but the providers will not allow the 
>>> users to tell the routers how much to reserve. In fact, I doubt the 
>>> providers will listen to anything that end-user are throwing at them. 
>>> So other than some end-to-end measurement-based approach, I don't see 
>>> e2e signaling will fly in the present network.
>>
>> [PM] Allow me to disagree... Are you mentioning US over-provided 
>> networks, or networks in other geographic locations? And even if 
>> you're only thinking in an US Internet, can you tell me how can this 
>> over-provision take place?
> 
> (I thought I wrote a paper on this in my past life....:-)) 


Yes, I know, that why your pro over-provisioning comments were strange 
to me :-)

> Yes, all 
> backbones have "hot" spots, and have congestion. But the backbone 
> problems can be (or have been) addressed via RSVP-TE. Yes, we have 
> short-time outage in the backbone due to frequent upgrade and router 
> crash. That's why we have worked very hard on backbone traffic 
> redundency (fast reroute, graceful restart.....) issues. So far, I have 
> a pretty good feeling on resource management within the backbone. The 
> focus is now on the edge and the access. I am hoping NSIS is the place 
> to do it.


Here I agree with you.. We need edge-to-edge resource management and 
each provider should manage its domain resources.

 
>> I agree that network providers can't engineer their network to satisfy 
>> every single client reclamation. That's why clients (receivers) with 
>> adaptive applications are useful to network providers. The network 
>> notify about their capabilities and the clients deal with it (adapt, 
>> leave session, ...).
> 
> 
> 
> The "receivers" can be some monitoring boxes arranged by the providers 
> to monitor the traffic in/out of the network. If things are not OK, 
> these boxes may play some rotuing tricks to redirect traffic from the 
> edge. I am not sure they are regular users.


Well.. When I said receiver I meant a final receiver of information, an 
application. Your point is different. A provider is free to monitor and 
re-route traffic inside its domain. However re-route traffic from 
neighbour provider A  to a provider B, isn't so ease. To start the 
contracts with providers A and B could not allow just re-routing..
So probably a provider should be happy to know that their receivers 
(clients, applications) can adapt to quality oscillations freeing the 
provider to the expensive job of re-routing traffic. This was my only 
point... The idea that a network provider can completely ignore their 
clients (provider of information or consumers of information) is wrong, 
IMHO.


>>> Finally, the providers are motivated by money to provide any 
>>> additional service. Unless the traffic that they are carrying worth 
>>> something, they will never deploy some extra "stuff" inside the 
>>> network. So what's worth money? ....
>>
>>
>> [PM] Okey.. But if network providers don't develop new services how 
>> can they expect clients to use them, if they don't exist?
>>
> 
> 
> I have just listed some of the services below. IMHO, the current state 
> of the Internet is not about "new" services, or "new" economy to that 
> matter. The Internet is a new media to transport traffic, like we have 
> been doing via post office, SNA, phone networks, Frame/ATM networks.... 
> The trick is to send the same old information efficiently.... Plus the 
> Internet needs to evolve itself to carry traffic some future 
> applications when they come..


I agree that the *old* services quality should be assured. However we 
already have *new* services that need support from the network, so its 
time to Internet to evolve (and NSIS is trying to help), since consumers 
will not keep buying services with poor quality.. To the list you 
presented I can add broadcast video services, like the timid ones we can 
see based upon the RealNetworks not scalable multi-rate technology and 
the so mentioned 3G services.

>>> - voice traffic! I am not only talking about VoIP; I am talking all 
>>> the voice traffic that use the Internet infrastructure.
>>>
>>> - wireless traffic: users packets are not landed inside the backbone, 
>>> so the access network needs to do more to those flows.
>>>
>>> - VPN (an over-used term :-)): but some users want to have QoS 
>>> reservation even though they are sending any traffic. Not for any 
>>> technical reason, it's a business reason. Have you seen the amount of 
>>> traffic in a SNA network, and how much they have been charged? :-)
>>>
> 
> - Ping


Cheers,


Paulo



-- 
| Paulo Mendes
| www.cs.columbia.edu/~mendes


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



From daemon@ns.ietf.org  Tue Jan 29 17:02: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 RAA22291
	for <nsis-archive@odin.ietf.org>; Tue, 29 Jan 2002 17:02:29 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id RAA03147
	for nsis-archive@odin.ietf.org; Tue, 29 Jan 2002 17:02: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 QAA02066;
	Tue, 29 Jan 2002 16:46: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 QAA02035
	for <nsis@ns.ietf.org>; Tue, 29 Jan 2002 16:46:24 -0500 (EST)
Received: from sierra.seas.upenn.edu (root@sierra.seas.upenn.edu [158.130.64.180])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21857
	for <nsis@ietf.org>; Tue, 29 Jan 2002 16:46:19 -0500 (EST)
Received: from cs.columbia.edu (DHCP64-23.SEAS.UPENN.EDU [158.130.64.102])
	by sierra.seas.upenn.edu (8.9.3/8.9.3) with ESMTP id QAA06815;
	Tue, 29 Jan 2002 16:46:20 -0500 (EST)
Message-ID: <3C571833.8040704@cs.columbia.edu>
Date: Tue, 29 Jan 2002 16:46:27 -0500
From: Paulo Mendes <mendes@cs.columbia.edu>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1
X-Accept-Language: en-us
MIME-Version: 1.0
To: dick.rr.knight@bt.com
CC: nsis@ietf.org
Subject: Re: [NSIS] Requirements for NSIS
References: <451D45016C2CD2119DA50000F8FE7F07080E5A8A@mlngcbnt01.hc.bt.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

Hello

Since most of the threads in this mailing list are being discussed for 
some time, I also agree that some point of the situation about NSIS 
requirements should be made, and this is a good start..

I agree that the points Dick mention in this e-mail about supporting: 
QoS signalling requests from the end-user, adaptive application and 
multicast are relevant to be included in the NSIS requirements list.

Cheers
Paulo

dick.rr.knight@bt.com wrote:

> First of all, I must apologise if any of this is already covered, I have
> "skimmed" the last two days emails.
>  
> We have had some very nice chats. Now we need to move forward.
> 
> Here are some observations against some recent posts:
> 
> john.loughney@nokia.com wrote (in reply to pingpan@juniper.net)
> Hi Ping,
> 
> 
>>Before we define end-to-end, edge-to-edge and 
>>domain-to-domain, ask the 
>>following:
>>
>>- why do we signal in the first place?
>>- where do we need to signal?
>>- will signaling work in provider's networks?
>>
>>We signal because there is no QoS when we are using some inter-active 
>>real-time applications. Since most of the Internet traffic is 
>>not within the scope of this "inter-active" and "real-time", let's not 
>>consider a kitchen-sink signaling protocol.
>>
> 
> I agree.  You are asking very good questions and these are
> the items we should focus on.
> 
> John
> --------------
> 
> Dick Knight:
> Good questions. But then, why is Internet Traffic not within scope? Why are
> only "inter-active" and "real-time" within scope?
> 
> Businesses will pay money for "IP VPN" between geographical locations, using
> service provider networks.
> They want the same sort of responsiveness they get on their LAN. So wouldn't
> QoS enable IP VPN sell?
> Why have a different solution for that?
> 
> REQUIREMENT: NSIS should support QoS signalling requests from the end-user
> REGARDLESS of the application.
> --
> ADAPTIVE Applications.
> (too much discussion to extract)
> We all agree that:
> 	The wireless part of the mobile access network needs adaptive
> solutions. These are application, network and sceanrio dependent. Much
> needed, but not part of NSIS.
> HOWEVER, NSIS should support adaptive applications, and I think the
> consensus is moving to ... by the support for negotiation and
> re-negotiation. It is still the application that controls the negotiation in
> NSIS, but (one example) triggered by a network congestion indication in the
> application flow packets (e.g. RTCP packets).
> 
> If we carry on with the adaptive thread we will re-invent TCP throttling,
> ISUP ACC, and Q.2931 GFC (or even ^S ^Q interactions in RS232).
> --
> 
> john.loughney@nokia.com wrote (in reply to mendes@cs.columbia.edu):
> 
>>What happens with one-to-many applications like video-on-demand or 
>>
>>>InternetTV? In this case you can't establish a session level QoS 
>>>agreement between provider and clients before the session 
>>>starts (and so before the reservation of resources) because you would 
>>>not know all your clients at that time.
>>>
>>Currently, I do not see this as a major part of NSIS.  I think this
>>should be held for later consideration.  I do not see that VOD or
>>Internet TV as burning issues.  I'm hoping we focus on one-to-one
>>signaling.
>>
> 
> Dick Knight:
> 	VoD may or may not be muticast, it is undefined. Internet TV (and
> radio) is.
> The problem is that support for multicast/multi-enduser cannot be added
> later. It is like
> security (and even QoS!) these things are easier designed in in the first
> place.
> So we ought to have multicast at the back of our minds and at aleast put
> some "hooks for the future" in.
> 
> REQUIREMENT: NSIS needs to be extensible to multicast applications and
> "connections" (streams?).
> --
> 
> More basic requirements that have not been addressed:
> NSIS signalling shall be .... Robust, reliable, secure, simple.
> NSIS signalling shall be ... able to request the Establishment, Negotiation,
> Maintenance, Modification and Release of communications streams (or
> connections?) between two or more end-users. Such requests shall be acted
> upon by all end-users and networks supporting the NSIS signalling, as
> depicted in the framework document ....
> 
> 
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis
> 


-- 
| Paulo Mendes
| www.cs.columbia.edu/~mendes


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



From daemon@ns.ietf.org  Tue Jan 29 17:14: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 RAA22595
	for <nsis-archive@odin.ietf.org>; Tue, 29 Jan 2002 17:14:12 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id RAA03678
	for nsis-archive@odin.ietf.org; Tue, 29 Jan 2002 17:14: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 RAA03228;
	Tue, 29 Jan 2002 17:02: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 RAA03159
	for <nsis@ns.ietf.org>; Tue, 29 Jan 2002 17:02:49 -0500 (EST)
Received: from sierra.seas.upenn.edu (root@sierra.seas.upenn.edu [158.130.64.180])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22319
	for <nsis@ietf.org>; Tue, 29 Jan 2002 17:02:45 -0500 (EST)
Received: from cs.columbia.edu (DHCP64-23.SEAS.UPENN.EDU [158.130.64.102])
	by sierra.seas.upenn.edu (8.9.3/8.9.3) with ESMTP id QAA05317;
	Tue, 29 Jan 2002 16:34:13 -0500 (EST)
Message-ID: <3C57155C.5010905@cs.columbia.edu>
Date: Tue, 29 Jan 2002 16:34:20 -0500
From: Paulo Mendes <mendes@cs.columbia.edu>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1
X-Accept-Language: en-us
MIME-Version: 1.0
To: dick.rr.knight@bt.com
CC: rrroy@att.com, schneider@tri.sbc.com, gkenward@nortelnetworks.com,
        john.loughney@nokia.com, brunner@ccrle.nec.de, ykahana@comgates.co.il,
        Ruediger.Geib@t-systems.com, nsis@ietf.org
Subject: Re: [NSIS] Two kinds of requirements (one-many applications)
References: <451D45016C2CD2119DA50000F8FE7F07080E5A88@mlngcbnt01.hc.bt.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

HI Dick

If I didn't misunderstood you, you also exemplified that a admission 
control of type "take it or leave it" is very limited. right?

About the number of clients.. Who knows.. Probably depends on the 
service quality :-)

Cheers,

Paulo

dick.rr.knight@bt.com wrote:

> See my comment below:
> 
> -----Original Message-----
> From: Paulo Mendes [mailto:mendes@cs.columbia.edu]
> Sent: 24 January 2002 20:24
> To: dick.rr.knight@bt.com
> Cc: rrroy@att.com; schneider@tri.sbc.com; gkenward@nortelnetworks.com;
> john.loughney@nokia.com; brunner@ccrle.nec.de; ykahana@comgates.co.il;
> Ruediger.Geib@t-systems.com; nsis@ietf.org
> Subject: Re: [NSIS] Two kinds of requirements
> 
> 
> 
> 
> dick.rr.knight@bt.com wrote:
> 
> 
>>Nice one. I was waiting for this.
>>
>>So .. another new requirement. To support one-to-many applications.
>>
> 
> 
> Yeap.. I say this is another requirement. I think that if we don't keep 
> in mind one-to-many applications we'll specialize NSIS functionality to 
> one-to-one cases, and then it would be hard to use NSIS with other type 
> of applications...
> 
> Probably one-to-one requirements could be seen as a sub-group of one-to-many
> requirements.
> 
> 
> 
>>There are two aspects to this:
>>1. The easy case. In internet TV, a provider (source of the TV) is
>>available. The first client uses NSIS to negotiate QoS with the network
>>
> and
> 
>>the source. Assuming the negotiation is successful a "connection" is
>>established. The second client then attepts to receive the TV. On
>>
> initiating
> 
>>the NSIS negotiation of QoS, they get a "take it or leave it" result of
>>
> the
> 
>>first client's negotiation. Anything else is not scalable.
>>2. A business conference will be established, with a known (limited)
>>
> number
> 
>>of clients. The provider can initiate the negotiation with the clients to
>>achieve the best possible QoS using the least resources.
>>
>>The first case is no extra requirements above an IP telephony call. The
>>second requires multiparty negotiation at establishment.
>>
> 
> 
> 
> I don't think this "take it of leave it" approach is the best one. For 
> example, if the first client has a low quality requirement all the other 
> clients can refuse join the session if they have a high quality expectation.
> I think that a more flexible approach is needed. For example, the 
> content provider should negotiate with the network provider a minimum 
> quality level for the session, since he doesn't want to provide services 
> with lower quality than that. After this, every client that joins the 
> session can accept that level of quality or they can try to re-negotiate 
>    with the network an increase of quality.
> 
> Cheers
> Paulo
> 
> [Dick Knight]: Think of an extreme example. The president of the USA makes a
> press release that he is going to make an important announcement concerning
> [war; peace; world finances; aliens landing - something that almost
> *everyone* in the world would like to hear about]. The announcement will
> take place at 2pm EST, and of course will be multicast with to the NSIS
> QoS-enabled internet. If the signalling sets up a QoS connection, in advance
> of anyone connecting, where does it get set-up to? Suppose we wait for the
> first client, use their QoS requirements (assuming they are above the White
> House's minimum and below the whitehouse's maximum). Then the next client
> was a bit better quality, and I am suggesting that is only achievable if the
> White House sends the information in the appropriate format to the quality
> requested. Now what happens if *every* client does that. Looks awfully
> similar to a DOS attack?
> 
> If this example is too extreme (we handle only less clients) - then what is
> the limit - 10 clients? 100? 1000? How do we decide how many?
> 
> 
>>Dick
>>
>>-----Original Message-----
>>From: Paulo Mendes [mailto:mendes@cs.columbia.edu]
>>Sent: 23 January 2002 01:21
>>To: Roy, Radhika R, ALASO
>>Cc: Schneider, Marco; Gary Kenward; Loughney John (NRC/Helsinki);
>>brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
>>dick.rr.knight@bt.com; nsis@ietf.org
>>Subject: Re: [NSIS] Two kinds of requirements
>>
>>
>>If I understood correctly NSIS should be a QoS signalling protocol 
>>useful to all applications, right?
>>
>>However it seems that this division between Application Layer QoS 
>>signalling (NSIS QoS) and posterior reservation request to the network 
>>for the necessary QoS agreed to at the session level only works for 
>>one-to-one applications, like IP telephony.
>>
>>What happens with one-to-many applications like video-on-demand or 
>>InternetTV? In this case you can't establish a session level QoS 
>>agreement between provider and clients before the session starts (and so 
>>before the reservation of resources) because you would not know all your 
>>clients at that time.
>>
>>Paulo Mendes
>>
>>
>>
>>
>>Roy, Radhika R, ALASO wrote:
>>
>>
>>
>>>Hi, Marco:
>>>
>>>Let me try to clarify from your point of view.
>>>
>>>It seems to agree that there needs to be a session level QOS agreement.
>>>
>>>
>>Let us analyze what is this. To make an agreement, we need to send some
>>messages between the end points. This may be termed as "signaling."
>>
>>
>>>A session expresses its QOS for its "application" that may consist of
>>>
>>>
>>media: audio, video, and/or data.
>>
>>
>>>In general, the above two items can be expressed as "Application Layer QOS
>>>
>>>
>>signaling."
>>
>>
>>>I think that we are agreeing on technical points.
>>>
>>>Best regards,
>>>Radhika R. Roy
>>>
>>>-----Original Message-----
>>>From: Schneider, Marco [mailto:schneider@tri.sbc.com]
>>>Sent: Friday, January 18, 2002 3:10 PM
>>>To: Roy, Radhika R, ALASO; Gary Kenward; Loughney John (NRC/Helsinki);
>>>brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
>>>dick.rr.knight@bt.com
>>>Cc: nsis@ietf.org
>>>Subject: RE: [NSIS] Two kinds of requirements
>>>
>>>
>>>Hi Roy,
>>>
>>>Below is the original text from your reponse to Gary Kenward. Hopefully
>>>
>>>
>>the
>>
>>
>>>context is clear.
>>>
>>>"[Roy, Radhika R, ALARC]  I would say that it is the QOS needs of the
>>>application (e.g., SIP-based VoIP) that the user likes to express (as
>>>opposed to "service"). Similarly, instead of network services, we would
>>>
>>>
>>say
>>
>>
>>>network layer QOS services (e.g., RSVP, DiffServ, MPLS). We would develop
>>>the end-to-end (application layer) QOS signaling protocol (say, NSIS QOS).
>>>Now, there needs to have some kinds of standards how NSIS QOS will be
>>>
>>>
>>mapped
>>
>>
>>>over RSVP, DiffServ, MPLS, etc."
>>>
>>>So by End-to-End you mean between directly between two "users". This is
>>>session level signaling and I don't believe the signaling part is within
>>>
>>>
>>the
>>
>>
>>>scope of this working group. An application level QOS specification may
>>>
>>>
>>be. 
>>
>>
>>>After a session level agreement on QOS, the host/client/customer will need
>>>to signal an actual reservation request to the network for the necessary
>>>
>>>
>>QOS
>>
>>
>>>agreed to at the session level. This is the protocol that we need to work
>>>on. 
>>>
>>>This approach is discussed in the SIP draft "SIP Extensions for Media
>>>Authorization" (draft-ietf-sip-call-auth-03.txt) and the RAP draft
>>>"Framework for session set-up with media authorization"
>>>(draft-ietf-rap-session-auth-02.txt).
>>>
>>>Marco Schneider
>>>
>>>-----Original Message-----
>>>From: Roy, Radhika R, ALASO [mailto:rrroy@att.com]
>>>Sent: Friday, January 18, 2002 9:18 AM
>>>To: Schneider, Marco; Gary Kenward; Loughney John (NRC/Helsinki);
>>>brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
>>>dick.rr.knight@bt.com
>>>Cc: nsis@ietf.org
>>>Subject: RE: [NSIS] Two kinds of requirements
>>>
>>>
>>>Defined below [RRR]
>>>
>>>-----Original Message-----
>>>From: Schneider, Marco [mailto:schneider@tri.sbc.com]
>>>Sent: Thursday, January 17, 2002 8:47 PM
>>>To: Roy, Radhika R, ALASO; Gary Kenward; Loughney John (NRC/Helsinki);
>>>brunner@ccrle.nec.de; Yaron Kahana; Geib, Ruediger;
>>>dick.rr.knight@bt.com
>>>Cc: nsis@ietf.org
>>>Subject: RE: [NSIS] Two kinds of requirements
>>>
>>>
>>>Hi Roy,
>>>
>>>Can you please define what you mean by "End-to-End Application Layer QOS
>>>Signaling". Thanks.
>>>
>>>[RRR] Suppose an user is initiation a SIP call to another user with audio,
>>>video, and data. The use needs to express the needs of QOS for audio,
>>>
>>>
>>video,
>>
>>
>>>and data to another user. 
>>>
>>>[RRR] The signaling mechanism that allows to express the QOS parameters of
>>>audio, video, and data is termed as the "End-to-End Application Layer QOS
>>>Signaling."
>>>
>>>Marco Schneider
>>>
>>>_______________________________________________
>>>nsis mailing list
>>>nsis@ietf.org
>>>https://www1.ietf.org/mailman/listinfo/nsis
>>>
>>>
>>>
>>
> 
> 


-- 
| Paulo Mendes
| www.cs.columbia.edu/~mendes


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



From daemon@ns.ietf.org  Tue Jan 29 17:24: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 RAA22915
	for <nsis-archive@odin.ietf.org>; Tue, 29 Jan 2002 17:24:04 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id RAA04041
	for nsis-archive@odin.ietf.org; Tue, 29 Jan 2002 17:24: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 RAA03659;
	Tue, 29 Jan 2002 17:14: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 RAA03634
	for <nsis@ns.ietf.org>; Tue, 29 Jan 2002 17:14:13 -0500 (EST)
Received: from sierra.seas.upenn.edu (root@sierra.seas.upenn.edu [158.130.64.180])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22590
	for <nsis@ietf.org>; Tue, 29 Jan 2002 17:14:09 -0500 (EST)
Received: from cs.columbia.edu (DHCP64-23.SEAS.UPENN.EDU [158.130.64.102])
	by sierra.seas.upenn.edu (8.9.3/8.9.3) with ESMTP id RAA10012;
	Tue, 29 Jan 2002 17:14:04 -0500 (EST)
Message-ID: <3C571EB2.90600@cs.columbia.edu>
Date: Tue, 29 Jan 2002 17:14:10 -0500
From: Paulo Mendes <mendes@cs.columbia.edu>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1
X-Accept-Language: en-us
MIME-Version: 1.0
To: "Freytsis, Ilya" <ifreytsis@cetacean.com>
CC: "'brunner@ccrle.nec.de'" <brunner@ccrle.nec.de>,
        "'nsis@ietf.org'" <nsis@ietf.org>
Subject: Re: [NSIS] RE: Independence of signalling and data path
References: <6D8664171C38D511B5AD0002B325CE6633ECB7@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

Hello

Well.. This seems more clear to me, but I still have some doubts :).

So, does this means that NSIS only needs two versions: host-edge and 
edge-edge? And that the hop-hop inside each domain is a concern of each 
network provider and not NSIS?

If I understood correctly resources management entities inside each 
domain (BB or other) don't need a host-host NSIS *version* to 
communicate, being the inter-domain communication made by the edge-edge 
NSIS *version*. Is this right?

Cheers
Paulo

Freytsis, Ilya wrote:

> Marcus, 
> 
> Let me add my 2cents into this discussion:
> 
> It looks to me that this discussion got very heated because it is at the
> very border between general QoS signaling and specific QoS technology in use
> (by the domain). The fact that you mentioned such terms as "Controller" and
> "BB" indicates to me that you have a particular technology in mind that
> based on this kind of entities. Tell me how the node at the edge of the RSVP
> or DiffServe domain can get such an idea as a BB that governs the
> neighboring domain. On the other hand the framework advocated by Georgios
> somewhat implies the use of the hop-by-hop QoS technology (and probably for
> this reason is opposed by some people including myself) that relies on
> signaling and data path being the same.
> The way to resolve this conflict in my mind is something along the following
> lines:
> 1. The general NSIS signaling being used between the host and the edge and
> between the edges of the neighboring domains (based on different QoS
> technology) should follow the same path as data (or lay out the path for the
> data if you wish).
> 2. It is up to the edge nodes that understand used within domain QoS
> technology to communicate to the BB or controller and translate NSIS generic
> signaling into something specific for this domain. Obviously the generic
> NSIS signaling has to be recreated at the domain egress edge.
> 3. In this scenario the host can be enabled with the particular QoS
> technology and use specific signaling for communication with the first
> domain or can use generic NSIS signaling.
> 4. The communication between neighboring domains using the same QoS
> technology can be done in the specific for the technology fashion though
> translation to NSIS and back will be always available if for whatever reason
> those domains prefer it.
> 
> In other words I am suggesting the following global analogy: 
> If you view the domain with a QoS technology as a virtual router than NSIS
> signaling used between those routers follows the same path as data. What
> happens within the router is not a NSIS business.
> 
> Ilya Freytsis
> 
> Date: Tue, 29 Jan 2002 11:36:05 +0100
> From: Marcus Brunner <brunner@ccrle.nec.de>
> Reply-To: brunner@ccrle.nec.de
> To: "Georgios Karagiannis (ELN)" <Georgios.Karagiannis@eln.ericsson.se>
> Cc: nsis@ietf.org
> n.se>
> Subject: [NSIS] RE: Independence of signalling and data path (was RE: [NSIS]
> Two			kindsof  requirements)
> 
> Georgios,
> 
> see inline
> 
> --On Monday, January 28, 2002 2:45 PM +0100 "Georgios Karagiannis (ELN)" 
> <Georgios.Karagiannis@eln.ericsson.se> wrote:
> 
> 
>>Hi Marcus
>>
>>
>>[MB]>> So, I think you much in line with that req. The protocol
>>[MB]>> from host to BB does not depend on the data path
>>[MB}>> completly. What the constrain for the
>>[MB]>> communication are is a different question.
>>
>>I will repeat what was already said in my previous e-mail:
>>
>>This is only true when the following CONSIDEARTIONS are
>>fulfilled:
>>
>>* BB's or QoS controllers are used;
>>
> 
> -> QoS controllers are no BBs in our understanding, the hop by hop 
> signalling is a special case, where each hop has a QoS controller and QoS 
> initiator functionality runing.
> 
> 
>>* the end-host should know the address of the first hop Bandwidth Broker;
>>
> 
> An end-host needs to know quite a bit of servers/nodes anyway. I even think 
> there are solutions (e.g. AAA servers), where the first hop router is 
> forwarding the signalling messages to the right place.
> 
> 
>>* the BBs should be aware (know) the addresses of neighboring BBs;
>>
> 
> Sure, you need interdoamin routing anyway.
> 
> 
>>* BB's or QoS controllers should be able to relate
>>   the QoS signaling to the data path;
>>
>>
> 
> yes true, I think this is the core functionality of a signalling protocol. 
> Only depends on the information available in the signaling message.
> 
> 
>> In GENERAL the above CONSIDERATIONS are very difficult to
>> fulfill. Please note that we need a NSIS protocol that can
>> be applied for GENERAL cases. Of course YOUR
>> SCENARIO, but OTHER TYPES as well will be INCLUDED.
>>
>>
> 
> IMO, with the QoS initator and QoS controller framework we excaclty target 
> a more general case then the hop-by-hop signalling.
> 
> 
>>Thus, in GENERAL the path followed by signaling
>>messages and the path followed by user data packets (associated
>>to these signaling messages) MUST BE THE SAME!!
>>
>>
> 
> No, I do not agree.
> 
> 
> 
>>Solution on how signaling messages and user data
>>packets can follow the same path:
>>The signaling messages will
>>follow the same path as the user data packets when for example,
>>the IP destination address of the signaling messages is the same
>>as the IP destination address of the user data packets.
>>
> 
> Not necessarly (but normally packet with the same destination likely take 
> the same path)
> 
> 
>>Typical IP routing protocols will route both signaling messages
>>and user data packets that have the same IP destination address through
>>the same path. RSVPv1 uses something similar (on the PATH messages
>>and user data packets having the same flow ID);
>>
>>[MB]>> And whether, the
>>[MB]>> protocol work
>>[MB]>> between ehost, eedge, ehop, all of them can be controllers
>>[MB]>> and initiators
>>[MB] on the other side. So they do not require data and signalling
>>[MB] on the same path.
>>
>>What do you mean, would you like to have a NSIS protocol version
>>that starts at one hop router and terminates at the next first hop router.
>>This protocol will be very slow, very complex, and in my opinion
>>not useful!
>>
>>
> 
> You have to be more specific on slow and complex.
> If you mean with slow the signalling delay (I think you are better of not 
> performing some actions in each hop)
> 
> The complextity in terms CPU heavily depends on the complexity of the state 
> machine, which defionitly not defined yet. But you are definitly right, 
> that it needs to be simple.
> 
> Marcus
> 
> 
>>Best regards,
>>Georgios
>>
>>
>>
>>
>>
> 
> 
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis
> 


-- 
| Paulo Mendes
| www.cs.columbia.edu/~mendes


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



From daemon@ns.ietf.org  Tue Jan 29 17:41: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 RAA23382
	for <nsis-archive@odin.ietf.org>; Tue, 29 Jan 2002 17:41:39 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id RAA05101
	for nsis-archive@odin.ietf.org; Tue, 29 Jan 2002 17:41: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 RAA04239;
	Tue, 29 Jan 2002 17:29: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 RAA04208
	for <nsis@ns.ietf.org>; Tue, 29 Jan 2002 17:29:42 -0500 (EST)
Received: from arb-exchange1.cetaceannetworks.com ([63.127.199.218])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23077
	for <nsis@ietf.org>; Tue, 29 Jan 2002 17:29:39 -0500 (EST)
Received: by mail.cetaceannetworks.com with Internet Mail Service (5.5.2653.19)
	id <DWXB7NH8>; Tue, 29 Jan 2002 17:26:23 -0500
Message-ID: <6D8664171C38D511B5AD0002B325CE6633ECBD@mail.cetaceannetworks.com>
From: "Freytsis, Ilya" <ifreytsis@cetacean.com>
To: "'Paulo Mendes'" <mendes@cs.columbia.edu>,
        "Freytsis, Ilya"
	 <ifreytsis@cetacean.com>
Cc: "'brunner@ccrle.nec.de'" <brunner@ccrle.nec.de>,
        "'nsis@ietf.org'"
	 <nsis@ietf.org>
Subject: RE: [NSIS] RE: Independence of signalling and data path
Date: Tue, 29 Jan 2002 17:26:19 -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

Yes, Paulo. That is exactly what I am proposing. 

I can add that resource management entities of the same nature (technology)
within domain MAY use NSIS to communicate directly to each other as a
protocol of choice but it is really up to that particular technology to
decide (it may use SIP if it finds that SIP fits better) and should not
effect NSIS protocol(s). The same can be said about interaction between
hosts enabled with unique for the domain QoS technology (they may have even
special hardware required for this).

Ilya

-----Original Message-----
From: Paulo Mendes [mailto:mendes@cs.columbia.edu]
Sent: Tuesday, January 29, 2002 5:14 PM
To: Freytsis, Ilya
Cc: 'brunner@ccrle.nec.de'; 'nsis@ietf.org'
Subject: Re: [NSIS] RE: Independence of signalling and data path

Hello

Well.. This seems more clear to me, but I still have some doubts :).

So, does this means that NSIS only needs two versions: host-edge and
edge-edge? And that the hop-hop inside each domain is a concern of each
network provider and not NSIS?

If I understood correctly resources management entities inside each
domain (BB or other) don't need a host-host NSIS *version* to
communicate, being the inter-domain communication made by the edge-edge
NSIS *version*. Is this right?

Cheers
Paulo

Freytsis, Ilya wrote:

> Marcus,
>
> Let me add my 2cents into this discussion:
>
> It looks to me that this discussion got very heated because it is at the
> very border between general QoS signaling and specific QoS technology in
use
> (by the domain). The fact that you mentioned such terms as "Controller"
and
> "BB" indicates to me that you have a particular technology in mind that
> based on this kind of entities. Tell me how the node at the edge of the
RSVP
> or DiffServe domain can get such an idea as a BB that governs the
> neighboring domain. On the other hand the framework advocated by Georgios
> somewhat implies the use of the hop-by-hop QoS technology (and probably
for
> this reason is opposed by some people including myself) that relies on
> signaling and data path being the same.
> The way to resolve this conflict in my mind is something along the
following
> lines:
> 1. The general NSIS signaling being used between the host and the edge and
> between the edges of the neighboring domains (based on different QoS
> technology) should follow the same path as data (or lay out the path for
the
> data if you wish).
> 2. It is up to the edge nodes that understand used within domain QoS
> technology to communicate to the BB or controller and translate NSIS
generic
> signaling into something specific for this domain. Obviously the generic
> NSIS signaling has to be recreated at the domain egress edge.
> 3. In this scenario the host can be enabled with the particular QoS
> technology and use specific signaling for communication with the first
> domain or can use generic NSIS signaling.
> 4. The communication between neighboring domains using the same QoS
> technology can be done in the specific for the technology fashion though
> translation to NSIS and back will be always available if for whatever
reason
> those domains prefer it.
>
> In other words I am suggesting the following global analogy:
> If you view the domain with a QoS technology as a virtual router than NSIS
> signaling used between those routers follows the same path as data. What
> happens within the router is not a NSIS business.
>
> Ilya Freytsis
>
> Date: Tue, 29 Jan 2002 11:36:05 +0100
> From: Marcus Brunner <brunner@ccrle.nec.de>
> Reply-To: brunner@ccrle.nec.de
> To: "Georgios Karagiannis (ELN)" <Georgios.Karagiannis@eln.ericsson.se>
> Cc: nsis@ietf.org
> n.se>
> Subject: [NSIS] RE: Independence of signalling and data path (was RE:
[NSIS]
> Two                   kindsof  requirements)
>
> Georgios,
>
> see inline
>
> --On Monday, January 28, 2002 2:45 PM +0100 "Georgios Karagiannis (ELN)"
> <Georgios.Karagiannis@eln.ericsson.se> wrote:
>
>
>>Hi Marcus
>>
>>
>>[MB]>> So, I think you much in line with that req. The protocol
>>[MB]>> from host to BB does not depend on the data path
>>[MB}>> completly. What the constrain for the
>>[MB]>> communication are is a different question.
>>
>>I will repeat what was already said in my previous e-mail:
>>
>>This is only true when the following CONSIDEARTIONS are
>>fulfilled:
>>
>>* BB's or QoS controllers are used;
>>
>
> -> QoS controllers are no BBs in our understanding, the hop by hop
> signalling is a special case, where each hop has a QoS controller and QoS
> initiator functionality runing.
>
>
>>* the end-host should know the address of the first hop Bandwidth Broker;
>>
>
> An end-host needs to know quite a bit of servers/nodes anyway. I even
think
> there are solutions (e.g. AAA servers), where the first hop router is
> forwarding the signalling messages to the right place.
>
>
>>* the BBs should be aware (know) the addresses of neighboring BBs;
>>
>
> Sure, you need interdoamin routing anyway.
>
>
>>* BB's or QoS controllers should be able to relate
>>   the QoS signaling to the data path;
>>
>>
>
> yes true, I think this is the core functionality of a signalling protocol.
> Only depends on the information available in the signaling message.
>
>
>> In GENERAL the above CONSIDERATIONS are very difficult to
>> fulfill. Please note that we need a NSIS protocol that can
>> be applied for GENERAL cases. Of course YOUR
>> SCENARIO, but OTHER TYPES as well will be INCLUDED.
>>
>>
>
> IMO, with the QoS initator and QoS controller framework we excaclty target
> a more general case then the hop-by-hop signalling.
>
>
>>Thus, in GENERAL the path followed by signaling
>>messages and the path followed by user data packets (associated
>>to these signaling messages) MUST BE THE SAME!!
>>
>>
>
> No, I do not agree.
>
>
>
>>Solution on how signaling messages and user data
>>packets can follow the same path:
>>The signaling messages will
>>follow the same path as the user data packets when for example,
>>the IP destination address of the signaling messages is the same
>>as the IP destination address of the user data packets.
>>
>
> Not necessarly (but normally packet with the same destination likely take
> the same path)
>
>
>>Typical IP routing protocols will route both signaling messages
>>and user data packets that have the same IP destination address through
>>the same path. RSVPv1 uses something similar (on the PATH messages
>>and user data packets having the same flow ID);
>>
>>[MB]>> And whether, the
>>[MB]>> protocol work
>>[MB]>> between ehost, eedge, ehop, all of them can be controllers
>>[MB]>> and initiators
>>[MB] on the other side. So they do not require data and signalling
>>[MB] on the same path.
>>
>>What do you mean, would you like to have a NSIS protocol version
>>that starts at one hop router and terminates at the next first hop router.
>>This protocol will be very slow, very complex, and in my opinion
>>not useful!
>>
>>
>
> You have to be more specific on slow and complex.
> If you mean with slow the signalling delay (I think you are better of not
> performing some actions in each hop)
>
> The complextity in terms CPU heavily depends on the complexity of the
state
> machine, which defionitly not defined yet. But you are definitly right,
> that it needs to be simple.
>
> Marcus
>
>
>>Best regards,
>>Georgios
>>
>>
>>
>>
>>
>
>
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis
>


--
| Paulo Mendes
| www.cs.columbia.edu/~mendes

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



From daemon@ns.ietf.org  Tue Jan 29 18:05: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 SAA23798
	for <nsis-archive@odin.ietf.org>; Tue, 29 Jan 2002 18:05:01 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id SAA06344
	for nsis-archive@odin.ietf.org; Tue, 29 Jan 2002 18:05: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 RAA05613;
	Tue, 29 Jan 2002 17:54:42 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA05584
	for <nsis@ns.ietf.org>; Tue, 29 Jan 2002 17:54:39 -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 RAA23655
	for <nsis@ietf.org>; Tue, 29 Jan 2002 17:54:32 -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 g0TMujT11255;
	Tue, 29 Jan 2002 16:56:45 -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 g0TMs1c05280;
	Tue, 29 Jan 2002 16:54:01 -0600 (CST)
Received: by TRIMAIL2.ad.tri.sbc.com with Internet Mail Service (5.5.2653.19)
	id <ZND3JXR5>; Tue, 29 Jan 2002 16:54:28 -0600
Message-ID: <905A1C4ABF353F4C8CC16FA9F53DD0D6322455@TRIMAIL2.ad.tri.sbc.com>
From: "Chen, Weijing" <wchen@tri.sbc.com>
To: "'Freytsis, Ilya'" <ifreytsis@cetacean.com>,
        "'Paulo Mendes'"
	 <mendes@cs.columbia.edu>
Cc: "'brunner@ccrle.nec.de'" <brunner@ccrle.nec.de>,
        "'nsis@ietf.org'"
	 <nsis@ietf.org>
Subject: RE: [NSIS] RE: Independence of signalling and data path
Date: Tue, 29 Jan 2002 16:54:26 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: nsis-admin@ietf.org
Errors-To: nsis-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Next Steps in Signaling <nsis.ietf.org>
X-BeenThere: nsis@ietf.org

Agreed here with Ilya. This is always our line of thinking about what NSIS
is.

And I would like to bring the following diagram again:

                   |-----|   |----|   |-----|  
                   |ehop |<->|ehop|<->|ehop |   
                   |-----|   |----|   |-----| 
                   |     |            |     |
                   |-----|            |-----|
                   |glue |            |glue |
                   |-----|            |-----|
                   |     |            |     |
|-----|            |-----|            |-----|            |-----|
|ehost|<---------->|ehost|<---------->|ehost|<---------->|ehost|
|-----|            |-----|            |-----|            |-----|
 host                edge     hop      edge                host
          user/             domains              user/
          network           (intra)              network
          NSIS                                   NSIS


and with NSIS applicable for inter-domain:


|----|   |-----|            |-----|   |----|
|ehop|<->|ehop |            |ehop |<->|ehop|
|----|   |-----|            |-----|   |----|
         |     |            |     |
         |-----|            |-----|
         |glue |            |glue |
         |-----|            |-----|
         |     |            |     |
         |-----|            |-----|
         |eedge|<---------->|eedge|
         |-----|            |-----|   
hop       edge                edge      hop
                  domains             
                  (inter)
                   NSIS


--
Weijing Chen
SBC Technology Resources
9505 Arboretum Blvd.
Austin, TX 78759
512 372 5710
wchen@tri.sbc.com



-----Original Message-----
From: Freytsis, Ilya [mailto:ifreytsis@cetacean.com] 
Sent: Tuesday, January 29, 2002 4:26 PM
To: 'Paulo Mendes'; Freytsis, Ilya
Cc: 'brunner@ccrle.nec.de'; 'nsis@ietf.org'
Subject: RE: [NSIS] RE: Independence of signalling and data path

Yes, Paulo. That is exactly what I am proposing. 

I can add that resource management entities of the same nature (technology)
within domain MAY use NSIS to communicate directly to each other as a
protocol of choice but it is really up to that particular technology to
decide (it may use SIP if it finds that SIP fits better) and should not
effect NSIS protocol(s). The same can be said about interaction between
hosts enabled with unique for the domain QoS technology (they may have even
special hardware required for this).

Ilya

-----Original Message-----
From: Paulo Mendes [mailto:mendes@cs.columbia.edu]
Sent: Tuesday, January 29, 2002 5:14 PM
To: Freytsis, Ilya
Cc: 'brunner@ccrle.nec.de'; 'nsis@ietf.org'
Subject: Re: [NSIS] RE: Independence of signalling and data path

Hello

Well.. This seems more clear to me, but I still have some doubts :).

So, does this means that NSIS only needs two versions: host-edge and
edge-edge? And that the hop-hop inside each domain is a concern of each
network provider and not NSIS?

If I understood correctly resources management entities inside each
domain (BB or other) don't need a host-host NSIS *version* to
communicate, being the inter-domain communication made by the edge-edge
NSIS *version*. Is this right?

Cheers
Paulo

Freytsis, Ilya wrote:

> Marcus,
>
> Let me add my 2cents into this discussion:
>
> It looks to me that this discussion got very heated because it is at the
> very border between general QoS signaling and specific QoS technology in
use
> (by the domain). The fact that you mentioned such terms as "Controller"
and
> "BB" indicates to me that you have a particular technology in mind that
> based on this kind of entities. Tell me how the node at the edge of the
RSVP
> or DiffServe domain can get such an idea as a BB that governs the
> neighboring domain. On the other hand the framework advocated by Georgios
> somewhat implies the use of the hop-by-hop QoS technology (and probably
for
> this reason is opposed by some people including myself) that relies on
> signaling and data path being the same.
> The way to resolve this conflict in my mind is something along the
following
> lines:
> 1. The general NSIS signaling being used between the host and the edge and
> between the edges of the neighboring domains (based on different QoS
> technology) should follow the same path as data (or lay out the path for
the
> data if you wish).
> 2. It is up to the edge nodes that understand used within domain QoS
> technology to communicate to the BB or controller and translate NSIS
generic
> signaling into something specific for this domain. Obviously the generic
> NSIS signaling has to be recreated at the domain egress edge.
> 3. In this scenario the host can be enabled with the particular QoS
> technology and use specific signaling for communication with the first
> domain or can use generic NSIS signaling.
> 4. The communication between neighboring domains using the same QoS
> technology can be done in the specific for the technology fashion though
> translation to NSIS and back will be always available if for whatever
reason
> those domains prefer it.
>
> In other words I am suggesting the following global analogy:
> If you view the domain with a QoS technology as a virtual router than NSIS
> signaling used between those routers follows the same path as data. What
> happens within the router is not a NSIS business.
>
> Ilya Freytsis
>
> Date: Tue, 29 Jan 2002 11:36:05 +0100
> From: Marcus Brunner <brunner@ccrle.nec.de>
> Reply-To: brunner@ccrle.nec.de
> To: "Georgios Karagiannis (ELN)" <Georgios.Karagiannis@eln.ericsson.se>
> Cc: nsis@ietf.org
> n.se>
> Subject: [NSIS] RE: Independence of signalling and data path (was RE:
[NSIS]
> Two                   kindsof  requirements)
>
> Georgios,
>
> see inline
>
> --On Monday, January 28, 2002 2:45 PM +0100 "Georgios Karagiannis (ELN)"
> <Georgios.Karagiannis@eln.ericsson.se> wrote:
>
>
>>Hi Marcus
>>
>>
>>[MB]>> So, I think you much in line with that req. The protocol
>>[MB]>> from host to BB does not depend on the data path
>>[MB}>> completly. What the constrain for the
>>[MB]>> communication are is a different question.
>>
>>I will repeat what was already said in my previous e-mail:
>>
>>This is only true when the following CONSIDEARTIONS are
>>fulfilled:
>>
>>* BB's or QoS controllers are used;
>>
>
> -> QoS controllers are no BBs in our understanding, the hop by hop
> signalling is a special case, where each hop has a QoS controller and QoS
> initiator functionality runing.
>
>
>>* the end-host should know the address of the first hop Bandwidth Broker;
>>
>
> An end-host needs to know quite a bit of servers/nodes anyway. I even
think
> there are solutions (e.g. AAA servers), where the first hop router is
> forwarding the signalling messages to the right place.
>
>
>>* the BBs should be aware (know) the addresses of neighboring BBs;
>>
>
> Sure, you need interdoamin routing anyway.
>
>
>>* BB's or QoS controllers should be able to relate
>>   the QoS signaling to the data path;
>>
>>
>
> yes true, I think this is the core functionality of a signalling protocol.
> Only depends on the information available in the signaling message.
>
>
>> In GENERAL the above CONSIDERATIONS are very difficult to
>> fulfill. Please note that we need a NSIS protocol that can
>> be applied for GENERAL cases. Of course YOUR
>> SCENARIO, but OTHER TYPES as well will be INCLUDED.
>>
>>
>
> IMO, with the QoS initator and QoS controller framework we excaclty target
> a more general case then the hop-by-hop signalling.
>
>
>>Thus, in GENERAL the path followed by signaling
>>messages and the path followed by user data packets (associated
>>to these signaling messages) MUST BE THE SAME!!
>>
>>
>
> No, I do not agree.
>
>
>
>>Solution on how signaling messages and user data
>>packets can follow the same path:
>>The signaling messages will
>>follow the same path as the user data packets when for example,
>>the IP destination address of the signaling messages is the same
>>as the IP destination address of the user data packets.
>>
>
> Not necessarly (but normally packet with the same destination likely take
> the same path)
>
>
>>Typical IP routing protocols will route both signaling messages
>>and user data packets that have the same IP destination address through
>>the same path. RSVPv1 uses something similar (on the PATH messages
>>and user data packets having the same flow ID);
>>
>>[MB]>> And whether, the
>>[MB]>> protocol work
>>[MB]>> between ehost, eedge, ehop, all of them can be controllers
>>[MB]>> and initiators
>>[MB] on the other side. So they do not require data and signalling
>>[MB] on the same path.
>>
>>What do you mean, would you like to have a NSIS protocol version
>>that starts at one hop router and terminates at the next first hop router.
>>This protocol will be very slow, very complex, and in my opinion
>>not useful!
>>
>>
>
> You have to be more specific on slow and complex.
> If you mean with slow the signalling delay (I think you are better of not
> performing some actions in each hop)
>
> The complextity in terms CPU heavily depends on the complexity of the
state
> machine, which defionitly not defined yet. But you are definitly right,
> that it needs to be simple.
>
> Marcus
>
>
>>Best regards,
>>Georgios
>>
>>
>>
>>
>>
>
>
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis
>


--
| Paulo Mendes
| www.cs.columbia.edu/~mendes

_______________________________________________
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  Tue Jan 29 18:21: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 SAA24095
	for <nsis-archive@odin.ietf.org>; Tue, 29 Jan 2002 18:21:15 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id SAA07043
	for nsis-archive@odin.ietf.org; Tue, 29 Jan 2002 18: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 SAA06662;
	Tue, 29 Jan 2002 18:12: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 SAA06593
	for <nsis@ns.ietf.org>; Tue, 29 Jan 2002 18:11:58 -0500 (EST)
Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23887
	for <nsis@ietf.org>; Tue, 29 Jan 2002 18:11:55 -0500 (EST)
From: Hemant.Chaskar@nokia.com
Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85])
	by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g0TNDeQ01379
	for <nsis@ietf.org>; Tue, 29 Jan 2002 17:13:40 -0600 (CST)
Received: from daebh002.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T58bfa4000aac12f255079@davir02nok.americas.nokia.com>;
 Tue, 29 Jan 2002 17:11:58 -0600
Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Tue, 29 Jan 2002 17:11:03 -0600
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [NSIS] RE: Independence of signalling and data path
Date: Tue, 29 Jan 2002 18:11:02 -0500
Message-ID: <E320A8529CF07E4C967ECC2F380B0CF9064C0D@bsebe001.NOE.Nokia.com>
Thread-Topic: [NSIS] RE: Independence of signalling and data path
Thread-Index: AcGpF/9HYMZxyEidSGKzywQnrs/LNgAAdsbg
To: <wchen@tri.sbc.com>
Cc: <nsis@ietf.org>
X-OriginalArrivalTime: 29 Jan 2002 23:11:03.0564 (UTC) FILETIME=[391EACC0:01C1A91A]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id SAA06594
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:

IMHO, an important point to be stressed when talking inter-domain is that only "host-specific" interdomain signalling (of course, if required) needs to be covered by NSIS. Other inter-domain signalling issues such as TE, BB signaling, policy should be out of NSIS scope.

Hemant 

-----Original Message-----
From: ext Chen, Weijing [mailto:wchen@tri.sbc.com]
Sent: Tuesday, January 29, 2002 5:54 PM
To: 'Freytsis, Ilya'; 'Paulo Mendes'
Cc: 'brunner@ccrle.nec.de'; 'nsis@ietf.org'
Subject: RE: [NSIS] RE: Independence of signalling and data path


Agreed here with Ilya. This is always our line of thinking about what NSIS
is.

And I would like to bring the following diagram again:

                   |-----|   |----|   |-----|  
                   |ehop |<->|ehop|<->|ehop |   
                   |-----|   |----|   |-----| 
                   |     |            |     |
                   |-----|            |-----|
                   |glue |            |glue |
                   |-----|            |-----|
                   |     |            |     |
|-----|            |-----|            |-----|            |-----|
|ehost|<---------->|ehost|<---------->|ehost|<---------->|ehost|
|-----|            |-----|            |-----|            |-----|
 host                edge     hop      edge                host
          user/             domains              user/
          network           (intra)              network
          NSIS                                   NSIS


and with NSIS applicable for inter-domain:


|----|   |-----|            |-----|   |----|
|ehop|<->|ehop |            |ehop |<->|ehop|
|----|   |-----|            |-----|   |----|
         |     |            |     |
         |-----|            |-----|
         |glue |            |glue |
         |-----|            |-----|
         |     |            |     |
         |-----|            |-----|
         |eedge|<---------->|eedge|
         |-----|            |-----|   
hop       edge                edge      hop
                  domains             
                  (inter)
                   NSIS


--
Weijing Chen
SBC Technology Resources
9505 Arboretum Blvd.
Austin, TX 78759
512 372 5710
wchen@tri.sbc.com



-----Original Message-----
From: Freytsis, Ilya [mailto:ifreytsis@cetacean.com] 
Sent: Tuesday, January 29, 2002 4:26 PM
To: 'Paulo Mendes'; Freytsis, Ilya
Cc: 'brunner@ccrle.nec.de'; 'nsis@ietf.org'
Subject: RE: [NSIS] RE: Independence of signalling and data path

Yes, Paulo. That is exactly what I am proposing. 

I can add that resource management entities of the same nature (technology)
within domain MAY use NSIS to communicate directly to each other as a
protocol of choice but it is really up to that particular technology to
decide (it may use SIP if it finds that SIP fits better) and should not
effect NSIS protocol(s). The same can be said about interaction between
hosts enabled with unique for the domain QoS technology (they may have even
special hardware required for this).

Ilya

-----Original Message-----
From: Paulo Mendes [mailto:mendes@cs.columbia.edu]
Sent: Tuesday, January 29, 2002 5:14 PM
To: Freytsis, Ilya
Cc: 'brunner@ccrle.nec.de'; 'nsis@ietf.org'
Subject: Re: [NSIS] RE: Independence of signalling and data path

Hello

Well.. This seems more clear to me, but I still have some doubts :).

So, does this means that NSIS only needs two versions: host-edge and
edge-edge? And that the hop-hop inside each domain is a concern of each
network provider and not NSIS?

If I understood correctly resources management entities inside each
domain (BB or other) don't need a host-host NSIS *version* to
communicate, being the inter-domain communication made by the edge-edge
NSIS *version*. Is this right?

Cheers
Paulo

Freytsis, Ilya wrote:

> Marcus,
>
> Let me add my 2cents into this discussion:
>
> It looks to me that this discussion got very heated because it is at the
> very border between general QoS signaling and specific QoS technology in
use
> (by the domain). The fact that you mentioned such terms as "Controller"
and
> "BB" indicates to me that you have a particular technology in mind that
> based on this kind of entities. Tell me how the node at the edge of the
RSVP
> or DiffServe domain can get such an idea as a BB that governs the
> neighboring domain. On the other hand the framework advocated by Georgios
> somewhat implies the use of the hop-by-hop QoS technology (and probably
for
> this reason is opposed by some people including myself) that relies on
> signaling and data path being the same.
> The way to resolve this conflict in my mind is something along the
following
> lines:
> 1. The general NSIS signaling being used between the host and the edge and
> between the edges of the neighboring domains (based on different QoS
> technology) should follow the same path as data (or lay out the path for
the
> data if you wish).
> 2. It is up to the edge nodes that understand used within domain QoS
> technology to communicate to the BB or controller and translate NSIS
generic
> signaling into something specific for this domain. Obviously the generic
> NSIS signaling has to be recreated at the domain egress edge.
> 3. In this scenario the host can be enabled with the particular QoS
> technology and use specific signaling for communication with the first
> domain or can use generic NSIS signaling.
> 4. The communication between neighboring domains using the same QoS
> technology can be done in the specific for the technology fashion though
> translation to NSIS and back will be always available if for whatever
reason
> those domains prefer it.
>
> In other words I am suggesting the following global analogy:
> If you view the domain with a QoS technology as a virtual router than NSIS
> signaling used between those routers follows the same path as data. What
> happens within the router is not a NSIS business.
>
> Ilya Freytsis
>
> Date: Tue, 29 Jan 2002 11:36:05 +0100
> From: Marcus Brunner <brunner@ccrle.nec.de>
> Reply-To: brunner@ccrle.nec.de
> To: "Georgios Karagiannis (ELN)" <Georgios.Karagiannis@eln.ericsson.se>
> Cc: nsis@ietf.org
> n.se>
> Subject: [NSIS] RE: Independence of signalling and data path (was RE:
[NSIS]
> Two                   kindsof  requirements)
>
> Georgios,
>
> see inline
>
> --On Monday, January 28, 2002 2:45 PM +0100 "Georgios Karagiannis (ELN)"
> <Georgios.Karagiannis@eln.ericsson.se> wrote:
>
>
>>Hi Marcus
>>
>>
>>[MB]>> So, I think you much in line with that req. The protocol
>>[MB]>> from host to BB does not depend on the data path
>>[MB}>> completly. What the constrain for the
>>[MB]>> communication are is a different question.
>>
>>I will repeat what was already said in my previous e-mail:
>>
>>This is only true when the following CONSIDEARTIONS are
>>fulfilled:
>>
>>* BB's or QoS controllers are used;
>>
>
> -> QoS controllers are no BBs in our understanding, the hop by hop
> signalling is a special case, where each hop has a QoS controller and QoS
> initiator functionality runing.
>
>
>>* the end-host should know the address of the first hop Bandwidth Broker;
>>
>
> An end-host needs to know quite a bit of servers/nodes anyway. I even
think
> there are solutions (e.g. AAA servers), where the first hop router is
> forwarding the signalling messages to the right place.
>
>
>>* the BBs should be aware (know) the addresses of neighboring BBs;
>>
>
> Sure, you need interdoamin routing anyway.
>
>
>>* BB's or QoS controllers should be able to relate
>>   the QoS signaling to the data path;
>>
>>
>
> yes true, I think this is the core functionality of a signalling protocol.
> Only depends on the information available in the signaling message.
>
>
>> In GENERAL the above CONSIDERATIONS are very difficult to
>> fulfill. Please note that we need a NSIS protocol that can
>> be applied for GENERAL cases. Of course YOUR
>> SCENARIO, but OTHER TYPES as well will be INCLUDED.
>>
>>
>
> IMO, with the QoS initator and QoS controller framework we excaclty target
> a more general case then the hop-by-hop signalling.
>
>
>>Thus, in GENERAL the path followed by signaling
>>messages and the path followed by user data packets (associated
>>to these signaling messages) MUST BE THE SAME!!
>>
>>
>
> No, I do not agree.
>
>
>
>>Solution on how signaling messages and user data
>>packets can follow the same path:
>>The signaling messages will
>>follow the same path as the user data packets when for example,
>>the IP destination address of the signaling messages is the same
>>as the IP destination address of the user data packets.
>>
>
> Not necessarly (but normally packet with the same destination likely take
> the same path)
>
>
>>Typical IP routing protocols will route both signaling messages
>>and user data packets that have the same IP destination address through
>>the same path. RSVPv1 uses something similar (on the PATH messages
>>and user data packets having the same flow ID);
>>
>>[MB]>> And whether, the
>>[MB]>> protocol work
>>[MB]>> between ehost, eedge, ehop, all of them can be controllers
>>[MB]>> and initiators
>>[MB] on the other side. So they do not require data and signalling
>>[MB] on the same path.
>>
>>What do you mean, would you like to have a NSIS protocol version
>>that starts at one hop router and terminates at the next first hop router.
>>This protocol will be very slow, very complex, and in my opinion
>>not useful!
>>
>>
>
> You have to be more specific on slow and complex.
> If you mean with slow the signalling delay (I think you are better of not
> performing some actions in each hop)
>
> The complextity in terms CPU heavily depends on the complexity of the
state
> machine, which defionitly not defined yet. But you are definitly right,
> that it needs to be simple.
>
> Marcus
>
>
>>Best regards,
>>Georgios
>>
>>
>>
>>
>>
>
>
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis
>


--
| Paulo Mendes
| www.cs.columbia.edu/~mendes

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

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

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



From daemon@ns.ietf.org  Tue Jan 29 18:23: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 SAA24138
	for <nsis-archive@odin.ietf.org>; Tue, 29 Jan 2002 18:23:28 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id SAA07136
	for nsis-archive@odin.ietf.org; Tue, 29 Jan 2002 18:23: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 SAA06801;
	Tue, 29 Jan 2002 18:13:58 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA06768
	for <nsis@ns.ietf.org>; Tue, 29 Jan 2002 18:13:56 -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 SAA23935
	for <nsis@ietf.org>; Tue, 29 Jan 2002 18:13:52 -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 g0TNG5T11372;
	Tue, 29 Jan 2002 17:16:05 -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 g0TNDLB05993;
	Tue, 29 Jan 2002 17:13:21 -0600 (CST)
Received: by TRIMAIL2.ad.tri.sbc.com with Internet Mail Service (5.5.2653.19)
	id <ZND3JXVM>; Tue, 29 Jan 2002 17:13:48 -0600
Message-ID: <905A1C4ABF353F4C8CC16FA9F53DD0D6322456@TRIMAIL2.ad.tri.sbc.com>
From: "Chen, Weijing" <wchen@tri.sbc.com>
To: "'Hemant.Chaskar@nokia.com'" <Hemant.Chaskar@nokia.com>
Cc: nsis@ietf.org
Subject: RE: [NSIS] RE: Independence of signalling and data path
Date: Tue, 29 Jan 2002 17:13:44 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: nsis-admin@ietf.org
Errors-To: nsis-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Next Steps in Signaling <nsis.ietf.org>
X-BeenThere: nsis@ietf.org

You are right, Hemant.


--
Weijing Chen
SBC Technology Resources
9505 Arboretum Blvd.
Austin, TX 78759
512 372 5710
wchen@tri.sbc.com



-----Original Message-----
From: Hemant.Chaskar@nokia.com [mailto:Hemant.Chaskar@nokia.com] 
Sent: Tuesday, January 29, 2002 5:11 PM
To: Chen, Weijing
Cc: nsis@ietf.org
Subject: RE: [NSIS] RE: Independence of signalling and data path

Hi:

IMHO, an important point to be stressed when talking inter-domain is that
only "host-specific" interdomain signalling (of course, if required) needs
to be covered by NSIS. Other inter-domain signalling issues such as TE, BB
signaling, policy should be out of NSIS scope.

Hemant 

-----Original Message-----
From: ext Chen, Weijing [mailto:wchen@tri.sbc.com]
Sent: Tuesday, January 29, 2002 5:54 PM
To: 'Freytsis, Ilya'; 'Paulo Mendes'
Cc: 'brunner@ccrle.nec.de'; 'nsis@ietf.org'
Subject: RE: [NSIS] RE: Independence of signalling and data path


Agreed here with Ilya. This is always our line of thinking about what NSIS
is.

And I would like to bring the following diagram again:

                   |-----|   |----|   |-----|  
                   |ehop |<->|ehop|<->|ehop |   
                   |-----|   |----|   |-----| 
                   |     |            |     |
                   |-----|            |-----|
                   |glue |            |glue |
                   |-----|            |-----|
                   |     |            |     |
|-----|            |-----|            |-----|            |-----|
|ehost|<---------->|ehost|<---------->|ehost|<---------->|ehost|
|-----|            |-----|            |-----|            |-----|
 host                edge     hop      edge                host
          user/             domains              user/
          network           (intra)              network
          NSIS                                   NSIS


and with NSIS applicable for inter-domain:


|----|   |-----|            |-----|   |----|
|ehop|<->|ehop |            |ehop |<->|ehop|
|----|   |-----|            |-----|   |----|
         |     |            |     |
         |-----|            |-----|
         |glue |            |glue |
         |-----|            |-----|
         |     |            |     |
         |-----|            |-----|
         |eedge|<---------->|eedge|
         |-----|            |-----|   
hop       edge                edge      hop
                  domains             
                  (inter)
                   NSIS


--
Weijing Chen
SBC Technology Resources
9505 Arboretum Blvd.
Austin, TX 78759
512 372 5710
wchen@tri.sbc.com



-----Original Message-----
From: Freytsis, Ilya [mailto:ifreytsis@cetacean.com] 
Sent: Tuesday, January 29, 2002 4:26 PM
To: 'Paulo Mendes'; Freytsis, Ilya
Cc: 'brunner@ccrle.nec.de'; 'nsis@ietf.org'
Subject: RE: [NSIS] RE: Independence of signalling and data path

Yes, Paulo. That is exactly what I am proposing. 

I can add that resource management entities of the same nature (technology)
within domain MAY use NSIS to communicate directly to each other as a
protocol of choice but it is really up to that particular technology to
decide (it may use SIP if it finds that SIP fits better) and should not
effect NSIS protocol(s). The same can be said about interaction between
hosts enabled with unique for the domain QoS technology (they may have even
special hardware required for this).

Ilya

-----Original Message-----
From: Paulo Mendes [mailto:mendes@cs.columbia.edu]
Sent: Tuesday, January 29, 2002 5:14 PM
To: Freytsis, Ilya
Cc: 'brunner@ccrle.nec.de'; 'nsis@ietf.org'
Subject: Re: [NSIS] RE: Independence of signalling and data path

Hello

Well.. This seems more clear to me, but I still have some doubts :).

So, does this means that NSIS only needs two versions: host-edge and
edge-edge? And that the hop-hop inside each domain is a concern of each
network provider and not NSIS?

If I understood correctly resources management entities inside each
domain (BB or other) don't need a host-host NSIS *version* to
communicate, being the inter-domain communication made by the edge-edge
NSIS *version*. Is this right?

Cheers
Paulo

Freytsis, Ilya wrote:

> Marcus,
>
> Let me add my 2cents into this discussion:
>
> It looks to me that this discussion got very heated because it is at the
> very border between general QoS signaling and specific QoS technology in
use
> (by the domain). The fact that you mentioned such terms as "Controller"
and
> "BB" indicates to me that you have a particular technology in mind that
> based on this kind of entities. Tell me how the node at the edge of the
RSVP
> or DiffServe domain can get such an idea as a BB that governs the
> neighboring domain. On the other hand the framework advocated by Georgios
> somewhat implies the use of the hop-by-hop QoS technology (and probably
for
> this reason is opposed by some people including myself) that relies on
> signaling and data path being the same.
> The way to resolve this conflict in my mind is something along the
following
> lines:
> 1. The general NSIS signaling being used between the host and the edge and
> between the edges of the neighboring domains (based on different QoS
> technology) should follow the same path as data (or lay out the path for
the
> data if you wish).
> 2. It is up to the edge nodes that understand used within domain QoS
> technology to communicate to the BB or controller and translate NSIS
generic
> signaling into something specific for this domain. Obviously the generic
> NSIS signaling has to be recreated at the domain egress edge.
> 3. In this scenario the host can be enabled with the particular QoS
> technology and use specific signaling for communication with the first
> domain or can use generic NSIS signaling.
> 4. The communication between neighboring domains using the same QoS
> technology can be done in the specific for the technology fashion though
> translation to NSIS and back will be always available if for whatever
reason
> those domains prefer it.
>
> In other words I am suggesting the following global analogy:
> If you view the domain with a QoS technology as a virtual router than NSIS
> signaling used between those routers follows the same path as data. What
> happens within the router is not a NSIS business.
>
> Ilya Freytsis
>
> Date: Tue, 29 Jan 2002 11:36:05 +0100
> From: Marcus Brunner <brunner@ccrle.nec.de>
> Reply-To: brunner@ccrle.nec.de
> To: "Georgios Karagiannis (ELN)" <Georgios.Karagiannis@eln.ericsson.se>
> Cc: nsis@ietf.org
> n.se>
> Subject: [NSIS] RE: Independence of signalling and data path (was RE:
[NSIS]
> Two                   kindsof  requirements)
>
> Georgios,
>
> see inline
>
> --On Monday, January 28, 2002 2:45 PM +0100 "Georgios Karagiannis (ELN)"
> <Georgios.Karagiannis@eln.ericsson.se> wrote:
>
>
>>Hi Marcus
>>
>>
>>[MB]>> So, I think you much in line with that req. The protocol
>>[MB]>> from host to BB does not depend on the data path
>>[MB}>> completly. What the constrain for the
>>[MB]>> communication are is a different question.
>>
>>I will repeat what was already said in my previous e-mail:
>>
>>This is only true when the following CONSIDEARTIONS are
>>fulfilled:
>>
>>* BB's or QoS controllers are used;
>>
>
> -> QoS controllers are no BBs in our understanding, the hop by hop
> signalling is a special case, where each hop has a QoS controller and QoS
> initiator functionality runing.
>
>
>>* the end-host should know the address of the first hop Bandwidth Broker;
>>
>
> An end-host needs to know quite a bit of servers/nodes anyway. I even
think
> there are solutions (e.g. AAA servers), where the first hop router is
> forwarding the signalling messages to the right place.
>
>
>>* the BBs should be aware (know) the addresses of neighboring BBs;
>>
>
> Sure, you need interdoamin routing anyway.
>
>
>>* BB's or QoS controllers should be able to relate
>>   the QoS signaling to the data path;
>>
>>
>
> yes true, I think this is the core functionality of a signalling protocol.
> Only depends on the information available in the signaling message.
>
>
>> In GENERAL the above CONSIDERATIONS are very difficult to
>> fulfill. Please note that we need a NSIS protocol that can
>> be applied for GENERAL cases. Of course YOUR
>> SCENARIO, but OTHER TYPES as well will be INCLUDED.
>>
>>
>
> IMO, with the QoS initator and QoS controller framework we excaclty target
> a more general case then the hop-by-hop signalling.
>
>
>>Thus, in GENERAL the path followed by signaling
>>messages and the path followed by user data packets (associated
>>to these signaling messages) MUST BE THE SAME!!
>>
>>
>
> No, I do not agree.
>
>
>
>>Solution on how signaling messages and user data
>>packets can follow the same path:
>>The signaling messages will
>>follow the same path as the user data packets when for example,
>>the IP destination address of the signaling messages is the same
>>as the IP destination address of the user data packets.
>>
>
> Not necessarly (but normally packet with the same destination likely take
> the same path)
>
>
>>Typical IP routing protocols will route both signaling messages
>>and user data packets that have the same IP destination address through
>>the same path. RSVPv1 uses something similar (on the PATH messages
>>and user data packets having the same flow ID);
>>
>>[MB]>> And whether, the
>>[MB]>> protocol work
>>[MB]>> between ehost, eedge, ehop, all of them can be controllers
>>[MB]>> and initiators
>>[MB] on the other side. So they do not require data and signalling
>>[MB] on the same path.
>>
>>What do you mean, would you like to have a NSIS protocol version
>>that starts at one hop router and terminates at the next first hop router.
>>This protocol will be very slow, very complex, and in my opinion
>>not useful!
>>
>>
>
> You have to be more specific on slow and complex.
> If you mean with slow the signalling delay (I think you are better of not
> performing some actions in each hop)
>
> The complextity in terms CPU heavily depends on the complexity of the
state
> machine, which defionitly not defined yet. But you are definitly right,
> that it needs to be simple.
>
> Marcus
>
>
>>Best regards,
>>Georgios
>>
>>
>>
>>
>>
>
>
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis
>


--
| Paulo Mendes
| www.cs.columbia.edu/~mendes

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

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

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



From daemon@ns.ietf.org  Wed Jan 30 02:50: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 CAA11956
	for <nsis-archive@odin.ietf.org>; Wed, 30 Jan 2002 02:50:19 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id CAA08094
	for nsis-archive@odin.ietf.org; Wed, 30 Jan 2002 02:50: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 CAA07604;
	Wed, 30 Jan 2002 02:36: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 CAA07573
	for <nsis@ns.ietf.org>; Wed, 30 Jan 2002 02:36:26 -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 CAA11805
	for <nsis@ietf.org>; Wed, 30 Jan 2002 02:36:24 -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 g0U7aTZ13810
	for <nsis@ietf.org>; Wed, 30 Jan 2002 09:36:29 +0200 (EET)
Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T58c3294764ac158f23076@esvir03nok.nokia.com>;
 Wed, 30 Jan 2002 09:36:24 +0200
Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779);
	 Wed, 30 Jan 2002 09:36:23 +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 signalling and data path 
Date: Wed, 30 Jan 2002 09:36:23 +0200
Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF5D94EB@esebe004.NOE.Nokia.com>
Thread-Topic: [NSIS] RE: Independence of signalling and data path 
Thread-Index: AcGo7UCvtIb5/OnpT+2aV97Ieu+G1gAc4SKQ
To: <ifreytsis@cetacean.com>, <brunner@ccrle.nec.de>
Cc: <nsis@ietf.org>
X-OriginalArrivalTime: 30 Jan 2002 07:36:24.0133 (UTC) FILETIME=[D1965750:01C1A960]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id CAA07574
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 Ilya,

> In other words I am suggesting the following global analogy: 
> If you view the domain with a QoS technology as a virtual 
> router than NSIS
> signaling used between those routers follows the same path as 
> data. What happens within the router is not a NSIS business.

I think that is a good analogy.  

John

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



From daemon@ns.ietf.org  Wed Jan 30 03:11: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 DAA12315
	for <nsis-archive@odin.ietf.org>; Wed, 30 Jan 2002 03:11:15 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id DAA09512
	for nsis-archive@odin.ietf.org; Wed, 30 Jan 2002 03:11: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 DAA08593;
	Wed, 30 Jan 2002 03:00: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 CAA08548
	for <nsis@ns.ietf.org>; Wed, 30 Jan 2002 02:59:59 -0500 (EST)
Received: from mail1.telekom.de ([62.225.183.235])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12078
	for <nsis@ietf.org>; Wed, 30 Jan 2002 02:59:57 -0500 (EST)
Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Wed, 30 Jan 2002 08:57:31 +0100
Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19)
	id <DVHT6DMF>; Wed, 30 Jan 2002 08:58:54 +0100
Message-Id: <DFD875E85664D3118FA6080006277DE70362C870@U8PN2>
From: "Geib, Ruediger" <Ruediger.Geib@t-systems.com>
To: ifreytsis@cetacean.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] RE: Independence of signalling and data path 
Date: Wed, 30 Jan 2002 08:59:13 +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 CAA08549
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 Ilya

> It looks to me that this discussion got very heated because 
> it is at the very border between general QoS signaling and
> specific QoS technology in use (by the domain). The fact
> that you mentioned such terms as "Controller" and "BB" 
> indicates to me that you have a particular technology in 
> mind that based on this kind of entities. 

Sorry, I don't think that this is a question of technology, this is a question of architecture. As both solutions, centralized reservation control and decentralized reservation control, have their merits I wouldn't want to restrict standardisation on one. The generic NSIS features should be supported by both. Interworking then becomes an issue. If we call the one attempt "BB" and the other "Router", the following Interworkings apply:
BB - BB
Router - Router
BB - Router
Only the third one requires some more work. If NSIS succeeds in a generic signalling specification, such an interworking shouldn't be difficult.

Regards, Rüdiger  

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



From daemon@optimus.ietf.org  Wed Jan 30 10:21: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 KAA22025
	for <nsis-archive@odin.ietf.org>; Wed, 30 Jan 2002 10:21:34 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id KAA02574
	for nsis-archive@odin.ietf.org; Wed, 30 Jan 2002 10:21: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 KAA02048;
	Wed, 30 Jan 2002 10:11: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 KAA02021
	for <nsis@optimus.ietf.org>; Wed, 30 Jan 2002 10:11:13 -0500 (EST)
Received: from arb-exchange1.cetaceannetworks.com ([63.127.199.195])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21627
	for <nsis@ietf.org>; Wed, 30 Jan 2002 10:11:09 -0500 (EST)
Received: by mail.cetaceannetworks.com with Internet Mail Service (5.5.2653.19)
	id <DWXB73AQ>; Wed, 30 Jan 2002 10:07:55 -0500
Message-ID: <6D8664171C38D511B5AD0002B325CE6633ECC6@mail.cetaceannetworks.com>
From: "Freytsis, Ilya" <ifreytsis@cetacean.com>
To: "'Geib, Ruediger'" <Ruediger.Geib@t-systems.com>,
        "Freytsis, Ilya"
	 <ifreytsis@cetacean.com>
Cc: nsis@ietf.org
Subject: RE: [NSIS] RE: Independence of signalling and data path 
Date: Wed, 30 Jan 2002 10:07:54 -0500
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 KAA02022
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

Rüdiger,

I think there is a big difference between idea of "router" and "BB". Router
is one of the most generic ideas in the IP world while "BB" can be much more
tightly coupled with the bandwidth management technology in use. For that
reason I believe it would be much easier to standardize router-router
interworkings and leave router-BB (within the same domain) and BB-BB
(inter-domain) in the realm of specific technology. On the other hands if
we'll be able to find a common ground between different technologies for the
BB-BB interface I definitely would not object to include it into NSIS.

Regards,
Ilya  

-----Original Message-----
From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com]
Sent: Wednesday, January 30, 2002 2:59 AM
To: ifreytsis@cetacean.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] RE: Independence of signalling and data path 

Hello Ilya

> It looks to me that this discussion got very heated because
> it is at the very border between general QoS signaling and
> specific QoS technology in use (by the domain). The fact
> that you mentioned such terms as "Controller" and "BB"
> indicates to me that you have a particular technology in
> mind that based on this kind of entities.

Sorry, I don't think that this is a question of technology, this is a
question of architecture. As both solutions, centralized reservation control
and decentralized reservation control, have their merits I wouldn't want to
restrict standardisation on one. The generic NSIS features should be
supported by both. Interworking then becomes an issue. If we call the one
attempt "BB" and the other "Router", the following Interworkings apply:
BB - BB
Router - Router
BB - Router
Only the third one requires some more work. If NSIS succeeds in a generic
signalling specification, such an interworking shouldn't be difficult.

Regards, Rüdiger 

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



From daemon@optimus.ietf.org  Thu Jan 31 03:29: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 DAA22038
	for <nsis-archive@odin.ietf.org>; Thu, 31 Jan 2002 03:29:55 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id DAA01427
	for nsis-archive@odin.ietf.org; Thu, 31 Jan 2002 03:29: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 DAA00912;
	Thu, 31 Jan 2002 03:17: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 DAA00879
	for <nsis@optimus.ietf.org>; Thu, 31 Jan 2002 03:17:02 -0500 (EST)
Received: from mail1.telekom.de ([62.225.183.235])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21858
	for <nsis@ietf.org>; Thu, 31 Jan 2002 03:16:59 -0500 (EST)
Received: from g8pbq.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Thu, 31 Jan 2002 09:14:43 +0100
Received: by G8PBQ.blf01.telekom.de with Internet Mail Service (5.5.2653.19)
	id <D0CX51R6>; Thu, 31 Jan 2002 09:16:26 +0100
Message-Id: <DFD875E85664D3118FA6080006277DE70362C87D@U8PN2>
From: "Geib, Ruediger" <Ruediger.Geib@t-systems.com>
To: ifreytsis@cetacean.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] RE: Independence of signalling and data path 
Date: Thu, 31 Jan 2002 09:16:24 +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 DAA00880
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

Ilya,

Internet2's Simple Inter Domain Bandwidth Broker Signaling specification is 80% complete and I know of at least two research labs implementing it. As far as I know, Fred Baker of Cisco recommended to forward this work to IETF. I don't understand where you see a technological challenge.

To prevent the NSIS participants from getting me wrong: I don't and won't try to throw Internet2's specification on NSIS. I think it's another good input for discussion and lessons learned there may help to make NSIS a success. This statement applies independant of the architecture an NSIS protocol will work with.

Those who are interested in Internet2's results, check
http://qbone.internet2.edu/bb/index.shtml
You'll find an architecture, encodings and some state diagrams. However the work is not complete and some required improvements are easily visible (like address encoding). To the best of my knowledge, Internet2 will not complete the work (it has been a volunteer effort and the volunteers were running out of time).   

Regards, Rüdiger



> Rüdiger,
> 
> I think there is a big difference between idea of "router" 
> and "BB". Router is one of the most generic ideas in the
> IP world while "BB" can be much more tightly coupled
> with the bandwidth management technology in use. For that
> reason I believe it would be much easier to standardize router-router
> interworkings and leave router-BB (within the same domain) and BB-BB
> (inter-domain) in the realm of specific technology. On the 
> other hands if we'll be able to find a common ground between different 
> technologies for the BB-BB interface I definitely would not object
> to include it into NSIS.
> 
> Regards,
> Ilya  
> 
> -----Original Message-----
> From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com]
> Sent: Wednesday, January 30, 2002 2:59 AM
> To: ifreytsis@cetacean.com
> Cc: nsis@ietf.org
> Subject: RE: [NSIS] RE: Independence of signalling and data path 
> 
> Hello Ilya
> 
> > It looks to me that this discussion got very heated because
> > it is at the very border between general QoS signaling and
> > specific QoS technology in use (by the domain). The fact
> > that you mentioned such terms as "Controller" and "BB"
> > indicates to me that you have a particular technology in
> > mind that based on this kind of entities.
> 
> Sorry, I don't think that this is a question of technology, this is a
> question of architecture. As both solutions, centralized 
> reservation control
> and decentralized reservation control, have their merits I 
> wouldn't want to
> restrict standardisation on one. The generic NSIS features should be
> supported by both. Interworking then becomes an issue. If we 
> call the one
> attempt "BB" and the other "Router", the following 
> Interworkings apply:
> BB - BB
> Router - Router
> BB - Router
> Only the third one requires some more work. If NSIS succeeds 
> in a generic
> signalling specification, such an interworking shouldn't be difficult.
> 
> Regards, Rüdiger 
> 

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



From daemon@optimus.ietf.org  Thu Jan 31 04: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 EAA22508
	for <nsis-archive@odin.ietf.org>; Thu, 31 Jan 2002 04:16:36 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id EAA03990
	for nsis-archive@odin.ietf.org; Thu, 31 Jan 2002 04: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 EAA03594;
	Thu, 31 Jan 2002 04:03: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 EAA03563
	for <nsis@optimus.ietf.org>; Thu, 31 Jan 2002 04:03:51 -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 EAA22374
	for <nsis@ietf.org>; Thu, 31 Jan 2002 04:03:46 -0500 (EST)
Received: from esealnt409.al.sw.ericsson.se (ESEALNT409.al.sw.ericsson.se [153.88.251.32])
	by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g0V93mX4010021
	for <nsis@ietf.org>; Thu, 31 Jan 2002 10:03:48 +0100 (MET)
Received: FROM esealnt747.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Thu Jan 31 10:03:47 2002 +0100
Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <YHKTMX8C>; Thu, 31 Jan 2002 10:03:30 +0100
Message-ID: <E244E44D6AB85E40AEEF7EAABE3545FA8233D7@enleent104.nl.eu.ericsson.se>
From: "Georgios Karagiannis (ELN)" <Georgios.Karagiannis@eln.ericsson.se>
To: "'Freytsis, Ilya'" <ifreytsis@cetacean.com>,
        "'brunner@ccrle.nec.de'"
	 <brunner@ccrle.nec.de>
Cc: "'nsis@ietf.org'" <nsis@ietf.org>
Subject: RE: [NSIS] RE: Independence of signalling and data path 
Date: Thu, 31 Jan 2002 10:03:28 +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 Ilya

Regarding your following statement:

[IF]>> In other words I am suggesting the following global analogy: 
[IF]>> If you view the domain with a QoS technology as a 
[IF]>> virtual router than NSIS
[IF]>> signaling used between those routers follows the same 
[IF]>> path as data. What
[IF]>> happens within the router is not a NSIS business.

I partially agree! 

I believe that the NSIS protocol when needed,
should be capable of operating within a QoS domain
(that is a QoS domain administrated by a provider).
However, if the QoS functionality is provided by a Bandwidth Broker
or the domain is overprovisioned then the signaling path and user data path
can be independent (not the same). Of course this can be chosen by the 
provider!

But when a provider would want to use the NSIS protocol within the 
domain for QoS support, then it should be possible to set (activate) 
the NSIS protocol such that the signaling path and user data path use the 
same path.

I agree with the rest of your statement!

Best Regards,
Georgios


-----Original Message-----
From: Freytsis, Ilya [mailto:ifreytsis@Cetacean.com]
Sent: dinsdag 29 januari 2002 18:45
To: 'brunner@ccrle.nec.de'
Cc: 'nsis@ietf.org'
Subject: [NSIS] RE: Independence of signalling and data path 


Marcus, 

Let me add my 2cents into this discussion:

It looks to me that this discussion got very heated because it is at the
very border between general QoS signaling and specific QoS technology in use
(by the domain). The fact that you mentioned such terms as "Controller" and
"BB" indicates to me that you have a particular technology in mind that
based on this kind of entities. Tell me how the node at the edge of the RSVP
or DiffServe domain can get such an idea as a BB that governs the
neighboring domain. On the other hand the framework advocated by Georgios
somewhat implies the use of the hop-by-hop QoS technology (and probably for
this reason is opposed by some people including myself) that relies on
signaling and data path being the same.
The way to resolve this conflict in my mind is something along the following
lines:
1. The general NSIS signaling being used between the host and the edge and
between the edges of the neighboring domains (based on different QoS
technology) should follow the same path as data (or lay out the path for the
data if you wish).
2. It is up to the edge nodes that understand used within domain QoS
technology to communicate to the BB or controller and translate NSIS generic
signaling into something specific for this domain. Obviously the generic
NSIS signaling has to be recreated at the domain egress edge.
3. In this scenario the host can be enabled with the particular QoS
technology and use specific signaling for communication with the first
domain or can use generic NSIS signaling.
4. The communication between neighboring domains using the same QoS
technology can be done in the specific for the technology fashion though
translation to NSIS and back will be always available if for whatever reason
those domains prefer it.

In other words I am suggesting the following global analogy: 
If you view the domain with a QoS technology as a virtual router than NSIS
signaling used between those routers follows the same path as data. What
happens within the router is not a NSIS business.

Ilya Freytsis

Date: Tue, 29 Jan 2002 11:36:05 +0100
From: Marcus Brunner <brunner@ccrle.nec.de>
Reply-To: brunner@ccrle.nec.de
To: "Georgios Karagiannis (ELN)" <Georgios.Karagiannis@eln.ericsson.se>
Cc: nsis@ietf.org
n.se>
Subject: [NSIS] RE: Independence of signalling and data path (was RE: [NSIS]
Two			kindsof  requirements)

Georgios,

see inline

--On Monday, January 28, 2002 2:45 PM +0100 "Georgios Karagiannis (ELN)" 
<Georgios.Karagiannis@eln.ericsson.se> wrote:

> Hi Marcus
>
>
> [MB]>> So, I think you much in line with that req. The protocol
> [MB]>> from host to BB does not depend on the data path
> [MB}>> completly. What the constrain for the
> [MB]>> communication are is a different question.
>
> I will repeat what was already said in my previous e-mail:
>
> This is only true when the following CONSIDEARTIONS are
> fulfilled:
>
> * BB's or QoS controllers are used;

-> QoS controllers are no BBs in our understanding, the hop by hop 
signalling is a special case, where each hop has a QoS controller and QoS 
initiator functionality runing.

> * the end-host should know the address of the first hop Bandwidth Broker;

An end-host needs to know quite a bit of servers/nodes anyway. I even think 
there are solutions (e.g. AAA servers), where the first hop router is 
forwarding the signalling messages to the right place.

> * the BBs should be aware (know) the addresses of neighboring BBs;

Sure, you need interdoamin routing anyway.

> * BB's or QoS controllers should be able to relate
>    the QoS signaling to the data path;
>

yes true, I think this is the core functionality of a signalling protocol. 
Only depends on the information available in the signaling message.

>
>  In GENERAL the above CONSIDERATIONS are very difficult to
>  fulfill. Please note that we need a NSIS protocol that can
>  be applied for GENERAL cases. Of course YOUR
>  SCENARIO, but OTHER TYPES as well will be INCLUDED.
>

IMO, with the QoS initator and QoS controller framework we excaclty target 
a more general case then the hop-by-hop signalling.

> Thus, in GENERAL the path followed by signaling
> messages and the path followed by user data packets (associated
> to these signaling messages) MUST BE THE SAME!!
>

No, I do not agree.


>
> Solution on how signaling messages and user data
> packets can follow the same path:
> The signaling messages will
> follow the same path as the user data packets when for example,
> the IP destination address of the signaling messages is the same
> as the IP destination address of the user data packets.

Not necessarly (but normally packet with the same destination likely take 
the same path)

> Typical IP routing protocols will route both signaling messages
> and user data packets that have the same IP destination address through
> the same path. RSVPv1 uses something similar (on the PATH messages
> and user data packets having the same flow ID);
>
> [MB]>> And whether, the
> [MB]>> protocol work
> [MB]>> between ehost, eedge, ehop, all of them can be controllers
> [MB]>> and initiators
> [MB] on the other side. So they do not require data and signalling
> [MB] on the same path.
>
> What do you mean, would you like to have a NSIS protocol version
> that starts at one hop router and terminates at the next first hop router.
> This protocol will be very slow, very complex, and in my opinion
> not useful!
>

You have to be more specific on slow and complex.
If you mean with slow the signalling delay (I think you are better of not 
performing some actions in each hop)

The complextity in terms CPU heavily depends on the complexity of the state 
machine, which defionitly not defined yet. But you are definitly right, 
that it needs to be simple.

Marcus

>
> Best regards,
> Georgios
>
>
>
>


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

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



From daemon@optimus.ietf.org  Thu Jan 31 07:31: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 HAA24530
	for <nsis-archive@odin.ietf.org>; Thu, 31 Jan 2002 07:31:11 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id HAA12722
	for nsis-archive@odin.ietf.org; Thu, 31 Jan 2002 07:31: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 HAA11907;
	Thu, 31 Jan 2002 07:18: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 HAA11877
	for <nsis@optimus.ietf.org>; Thu, 31 Jan 2002 07:18:13 -0500 (EST)
Received: from mbibipnt08.HC.BT.COM (saturn.bt.com [193.113.57.20])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24330
	for <nsis@ietf.org>; Thu, 31 Jan 2002 07:18:09 -0500 (EST)
From: dick.rr.knight@bt.com
Received: by mbibipnt08.hc.bt.com with Internet Mail Service (5.5.2650.21)
	id <D0P40Y0C>; Thu, 31 Jan 2002 12:17:47 -0000
Message-ID: <451D45016C2CD2119DA50000F8FE7F07080E5AA2@mlngcbnt01.hc.bt.com>
To: Georgios.Karagiannis@eln.ericsson.se, ifreytsis@cetacean.com,
        brunner@ccrle.nec.de
Cc: nsis@ietf.org
Subject: RE: [NSIS] RE: Independence of signalling and data path 
Date: Thu, 31 Jan 2002 12:17:25 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
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


I think that we are all moving to is a generic NSIS protocol that is
applicable to the Host-Edge and the Edge-Edge interfaces. The use of it
within a domain (hop-hop) must always be the decision of the domain
operator. This is because:
1. An operator of a domain will make their own decisions regarding protocol
selection
2. domain operators need a generalised QoS protocol for interconnect
3. Some approaches for QoS (at least the bandwidth part) do not require any
signalling (e.g. overprovision).

In case 3, it seems to me this is a specialised case of Edge-Edge. The two
edges in this case are within a single domain or technology type, and the
NSIS signalling protocol must traverse it in order to reach the next domain
or QoS technology type.

Dick


-----Original Message-----
From: Georgios Karagiannis (ELN)
[mailto:Georgios.Karagiannis@eln.ericsson.se]
Sent: 31 January 2002 09:03
To: 'Freytsis, Ilya'; 'brunner@ccrle.nec.de'
Cc: 'nsis@ietf.org'
Subject: RE: [NSIS] RE: Independence of signalling and data path 


Hi Ilya

Regarding your following statement:

[IF]>> In other words I am suggesting the following global analogy: 
[IF]>> If you view the domain with a QoS technology as a 
[IF]>> virtual router than NSIS
[IF]>> signaling used between those routers follows the same 
[IF]>> path as data. What
[IF]>> happens within the router is not a NSIS business.

I partially agree! 

I believe that the NSIS protocol when needed,
should be capable of operating within a QoS domain
(that is a QoS domain administrated by a provider).
However, if the QoS functionality is provided by a Bandwidth Broker
or the domain is overprovisioned then the signaling path and user data path
can be independent (not the same). Of course this can be chosen by the 
provider!

But when a provider would want to use the NSIS protocol within the 
domain for QoS support, then it should be possible to set (activate) 
the NSIS protocol such that the signaling path and user data path use the 
same path.

I agree with the rest of your statement!

Best Regards,
Georgios


-----Original Message-----
From: Freytsis, Ilya [mailto:ifreytsis@Cetacean.com]
Sent: dinsdag 29 januari 2002 18:45
To: 'brunner@ccrle.nec.de'
Cc: 'nsis@ietf.org'
Subject: [NSIS] RE: Independence of signalling and data path 


Marcus, 

Let me add my 2cents into this discussion:

It looks to me that this discussion got very heated because it is at the
very border between general QoS signaling and specific QoS technology in use
(by the domain). The fact that you mentioned such terms as "Controller" and
"BB" indicates to me that you have a particular technology in mind that
based on this kind of entities. Tell me how the node at the edge of the RSVP
or DiffServe domain can get such an idea as a BB that governs the
neighboring domain. On the other hand the framework advocated by Georgios
somewhat implies the use of the hop-by-hop QoS technology (and probably for
this reason is opposed by some people including myself) that relies on
signaling and data path being the same.
The way to resolve this conflict in my mind is something along the following
lines:
1. The general NSIS signaling being used between the host and the edge and
between the edges of the neighboring domains (based on different QoS
technology) should follow the same path as data (or lay out the path for the
data if you wish).
2. It is up to the edge nodes that understand used within domain QoS
technology to communicate to the BB or controller and translate NSIS generic
signaling into something specific for this domain. Obviously the generic
NSIS signaling has to be recreated at the domain egress edge.
3. In this scenario the host can be enabled with the particular QoS
technology and use specific signaling for communication with the first
domain or can use generic NSIS signaling.
4. The communication between neighboring domains using the same QoS
technology can be done in the specific for the technology fashion though
translation to NSIS and back will be always available if for whatever reason
those domains prefer it.

In other words I am suggesting the following global analogy: 
If you view the domain with a QoS technology as a virtual router than NSIS
signaling used between those routers follows the same path as data. What
happens within the router is not a NSIS business.

Ilya Freytsis

Date: Tue, 29 Jan 2002 11:36:05 +0100
From: Marcus Brunner <brunner@ccrle.nec.de>
Reply-To: brunner@ccrle.nec.de
To: "Georgios Karagiannis (ELN)" <Georgios.Karagiannis@eln.ericsson.se>
Cc: nsis@ietf.org
n.se>
Subject: [NSIS] RE: Independence of signalling and data path (was RE: [NSIS]
Two			kindsof  requirements)

Georgios,

see inline

--On Monday, January 28, 2002 2:45 PM +0100 "Georgios Karagiannis (ELN)" 
<Georgios.Karagiannis@eln.ericsson.se> wrote:

> Hi Marcus
>
>
> [MB]>> So, I think you much in line with that req. The protocol
> [MB]>> from host to BB does not depend on the data path
> [MB}>> completly. What the constrain for the
> [MB]>> communication are is a different question.
>
> I will repeat what was already said in my previous e-mail:
>
> This is only true when the following CONSIDEARTIONS are
> fulfilled:
>
> * BB's or QoS controllers are used;

-> QoS controllers are no BBs in our understanding, the hop by hop 
signalling is a special case, where each hop has a QoS controller and QoS 
initiator functionality runing.

> * the end-host should know the address of the first hop Bandwidth Broker;

An end-host needs to know quite a bit of servers/nodes anyway. I even think 
there are solutions (e.g. AAA servers), where the first hop router is 
forwarding the signalling messages to the right place.

> * the BBs should be aware (know) the addresses of neighboring BBs;

Sure, you need interdoamin routing anyway.

> * BB's or QoS controllers should be able to relate
>    the QoS signaling to the data path;
>

yes true, I think this is the core functionality of a signalling protocol. 
Only depends on the information available in the signaling message.

>
>  In GENERAL the above CONSIDERATIONS are very difficult to
>  fulfill. Please note that we need a NSIS protocol that can
>  be applied for GENERAL cases. Of course YOUR
>  SCENARIO, but OTHER TYPES as well will be INCLUDED.
>

IMO, with the QoS initator and QoS controller framework we excaclty target 
a more general case then the hop-by-hop signalling.

> Thus, in GENERAL the path followed by signaling
> messages and the path followed by user data packets (associated
> to these signaling messages) MUST BE THE SAME!!
>

No, I do not agree.


>
> Solution on how signaling messages and user data
> packets can follow the same path:
> The signaling messages will
> follow the same path as the user data packets when for example,
> the IP destination address of the signaling messages is the same
> as the IP destination address of the user data packets.

Not necessarly (but normally packet with the same destination likely take 
the same path)

> Typical IP routing protocols will route both signaling messages
> and user data packets that have the same IP destination address through
> the same path. RSVPv1 uses something similar (on the PATH messages
> and user data packets having the same flow ID);
>
> [MB]>> And whether, the
> [MB]>> protocol work
> [MB]>> between ehost, eedge, ehop, all of them can be controllers
> [MB]>> and initiators
> [MB] on the other side. So they do not require data and signalling
> [MB] on the same path.
>
> What do you mean, would you like to have a NSIS protocol version
> that starts at one hop router and terminates at the next first hop router.
> This protocol will be very slow, very complex, and in my opinion
> not useful!
>

You have to be more specific on slow and complex.
If you mean with slow the signalling delay (I think you are better of not 
performing some actions in each hop)

The complextity in terms CPU heavily depends on the complexity of the state 
machine, which defionitly not defined yet. But you are definitly right, 
that it needs to be simple.

Marcus

>
> Best regards,
> Georgios
>
>
>
>


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

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

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



From daemon@optimus.ietf.org  Thu Jan 31 07:34: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 HAA24604
	for <nsis-archive@odin.ietf.org>; Thu, 31 Jan 2002 07:34:36 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id HAA12839
	for nsis-archive@odin.ietf.org; Thu, 31 Jan 2002 07:34: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 HAA12152;
	Thu, 31 Jan 2002 07:21: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 HAA12121
	for <nsis@optimus.ietf.org>; Thu, 31 Jan 2002 07:21:54 -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 HAA24378
	for <nsis@ietf.org>; Thu, 31 Jan 2002 07:21:49 -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 g0VCM4i08498
	for <nsis@ietf.org>; Thu, 31 Jan 2002 14:22:04 +0200 (EET)
Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T58c954e0a5ac158f21081@esvir01nok.ntc.nokia.com>;
 Thu, 31 Jan 2002 14:21:45 +0200
Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779);
	 Thu, 31 Jan 2002 14:21: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] RE: Independence of signalling and data path 
Date: Thu, 31 Jan 2002 14:21:47 +0200
Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF5D9510@esebe004.NOE.Nokia.com>
Thread-Topic: [NSIS] RE: Independence of signalling and data path 
Thread-Index: AcGqUWqP3/fuKwDmTrG7+M5eImpwyAAABOSw
To: <dick.rr.knight@bt.com>
Cc: <nsis@ietf.org>
X-OriginalArrivalTime: 31 Jan 2002 12:21:47.0652 (UTC) FILETIME=[DA69BC40:01C1AA51]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id HAA12122
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 Dick,

> I think that we are all moving to is a generic NSIS protocol that is
> applicable to the Host-Edge and the Edge-Edge interfaces. The 
> use of it within a domain (hop-hop) must always be the decision of the 
> domain operator. 

I agree.  I think in the Framework document, we should fully
describe this.

> This is because:
> 1. An operator of a domain will make their own decisions 
> regarding protocol selection
> 2. domain operators need a generalised QoS protocol for interconnect
> 3. Some approaches for QoS (at least the bandwidth part) do 
> not require any signalling (e.g. overprovision).

Additionally, I would believe that besides over-provisioning,
some service providers might prefer to use 'contractual signaling'
(having a signed contract for a fixed pipe) for transit
networks.

> In case 3, it seems to me this is a specialised case of 
> Edge-Edge. The two edges in this case are within a single domain 
> or technology type, and the NSIS signalling protocol must traverse 
> it in order to reach the next domain or QoS technology type.

Agreed.

John

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



From daemon@optimus.ietf.org  Thu Jan 31 08: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 IAA25254
	for <nsis-archive@odin.ietf.org>; Thu, 31 Jan 2002 08:05:17 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id IAA14129
	for nsis-archive@odin.ietf.org; Thu, 31 Jan 2002 08:05: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 HAA13307;
	Thu, 31 Jan 2002 07:52: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 HAA13276
	for <nsis@optimus.ietf.org>; Thu, 31 Jan 2002 07:52:32 -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 HAA24984
	for <nsis@ietf.org>; Thu, 31 Jan 2002 07:52:28 -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 g0VCqXZ22648
	for <nsis@ietf.org>; Thu, 31 Jan 2002 14:52:33 +0200 (EET)
Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T58c97104c3ac158f23076@esvir03nok.nokia.com>;
 Thu, 31 Jan 2002 14:52:29 +0200
Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779);
	 Thu, 31 Jan 2002 14:52:29 +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 signalling and data path 
Date: Thu, 31 Jan 2002 14:52:28 +0200
Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF5D9517@esebe004.NOE.Nokia.com>
Thread-Topic: [NSIS] RE: Independence of signalling and data path 
Thread-Index: AcGqM+C2iIEOgmxXSr6EfeCucU2LhAAIfQfA
To: <ifreytsis@cetacean.com>
Cc: <nsis@ietf.org>
X-OriginalArrivalTime: 31 Jan 2002 12:52:29.0236 (UTC) FILETIME=[24152740:01C1AA56]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id HAA13277
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 there is a big difference between idea of "router" 
> and "BB". Router is one of the most generic ideas in the
> IP world while "BB" can be much more tightly coupled
> with the bandwidth management technology in use. For that
> reason I believe it would be much easier to standardize router-router
> interworkings and leave router-BB (within the same domain) and BB-BB
> (inter-domain) in the realm of specific technology. On the 
> other hands if we'll be able to find a common ground between different 
> technologies for the BB-BB interface I definitely would not object
> to include it into NSIS.

Perhaps we should use a more generic term, such as proxy.
This proxy could be light-weight & reside at an edge router, 
or at a bandwidth broker.  I think that we should stick
to a more generic term, because when discussing Bandwidth 
broakers, we come very close to actual reservation mechanisms.

John

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



From daemon@optimus.ietf.org  Thu Jan 31 09:15: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 JAA27184
	for <nsis-archive@odin.ietf.org>; Thu, 31 Jan 2002 09:15:04 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id JAA18201
	for nsis-archive@odin.ietf.org; Thu, 31 Jan 2002 09:15: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 JAA17434;
	Thu, 31 Jan 2002 09:05: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 JAA17403
	for <nsis@optimus.ietf.org>; Thu, 31 Jan 2002 09:05:29 -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 JAA26893
	for <nsis@ietf.org>; Thu, 31 Jan 2002 09:05:24 -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 g0VE5PX4029007
	for <nsis@ietf.org>; Thu, 31 Jan 2002 15:05:25 +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 <0GQT00A5C35168@mbb1.ericsson.se> for nsis@ietf.org; Thu,
 31 Jan 2002 15:05:25 +0100 (MET)
Date: Thu, 31 Jan 2002 15:06:25 +0100
From: David Partain <David.Partain@ericsson.com>
To: NSIS Mailing List <nsis@ietf.org>
Reply-to: David.Partain@ericsson.com
Message-id: <0GQT00A5D35168@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] summary of thread on data and signalling path
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,

Here I go again, trying to digest a Monster Thread...

The question posed is, "Do signalling and data need to follow the
same path in order to achieve what we're after with NSIS?"

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.

 - There are absolutely going to be cases where there will _not_
   be a centralized entity managing resources and that the
   signalling will be used as a tool for resource management.
   For various reasons (such as efficient use of expensive
   bandwidth), one will want to have fine-grained, fast,
   and very dynamic control of the resources in the network.

 - There are going to be cases where there will be neither
   signalling nor a centralized entity (overprovisioning).
   In this case, the question posed just doesn't matter :-)

There are other possibilities as well.

Perhaps I'm being repetitive, but it's seems to me that the
important issue is that the domain answers the question,
"May I have what I want?"  Whether it bases the answer on a
centralized entity saying, "Sure, have a good time" or based
upon hop-by-hop verification of resource availability and then
allocation is not really important.  It's the combination of
domain answers which is important.

I think this follows very closely with what Ilya Freytsis wrote
on Tuesday:  "If you view the domain with a QoS technology
as a virtual router than NSIS signaling used between those
routers follows the same path as data. What happens within
the router is not a NSIS business."

As I see it, NSIS must accept all of these possibilities.
I also believe that we need to have standardized ways of
implementing both approaches, not just a domain-specific
free-for-all.    We need to define the interaction between
higher-level NSIS signalling that answers The Domain Question,
which I think will follow the same path as data, and the work
that's done within the domain to answer that question.

The NSIS protocol must be one of the options available for
managing QoS within a domain, but of course a different solution
can be chosen.  That solution may not require that user and
signalling data follow the same path.  However, if the NSIS
protocol is used within the domain, this may be required.

Cheers,

dlp

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



From daemon@optimus.ietf.org  Thu Jan 31 10:07: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 KAA28696
	for <nsis-archive@odin.ietf.org>; Thu, 31 Jan 2002 10:07:01 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id KAA21964
	for nsis-archive@odin.ietf.org; Thu, 31 Jan 2002 10:07: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 JAA20722;
	Thu, 31 Jan 2002 09:57: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 JAA20689
	for <nsis@optimus.ietf.org>; Thu, 31 Jan 2002 09:57:09 -0500 (EST)
Received: from mbibipnt08.HC.BT.COM (saturn.bt.com [193.113.57.20])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28332
	for <nsis@ietf.org>; Thu, 31 Jan 2002 09:57:03 -0500 (EST)
From: dick.rr.knight@bt.com
Received: by mbibipnt08.hc.bt.com with Internet Mail Service (5.5.2650.21)
	id <D0PVAA60>; Thu, 31 Jan 2002 14:56:43 -0000
Message-ID: <451D45016C2CD2119DA50000F8FE7F07080E5AA4@mlngcbnt01.hc.bt.com>
To: David.Partain@ericsson.com, nsis@ietf.org
Subject: RE: [NSIS] summary of thread on data and signalling path
Date: Thu, 31 Jan 2002 14:56:26 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
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

A good summary, and a clear way forward to be captured into a Requirements
document.

Dick

-----Original Message-----
From: David Partain [mailto:David.Partain@ericsson.com]
Sent: 31 January 2002 14:06
To: NSIS Mailing List
Subject: [NSIS] summary of thread on data and signalling path


Hi all,

Here I go again, trying to digest a Monster Thread...

The question posed is, "Do signalling and data need to follow the
same path in order to achieve what we're after with NSIS?"

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.

 - There are absolutely going to be cases where there will _not_
   be a centralized entity managing resources and that the
   signalling will be used as a tool for resource management.
   For various reasons (such as efficient use of expensive
   bandwidth), one will want to have fine-grained, fast,
   and very dynamic control of the resources in the network.

 - There are going to be cases where there will be neither
   signalling nor a centralized entity (overprovisioning).
   In this case, the question posed just doesn't matter :-)

There are other possibilities as well.

Perhaps I'm being repetitive, but it's seems to me that the
important issue is that the domain answers the question,
"May I have what I want?"  Whether it bases the answer on a
centralized entity saying, "Sure, have a good time" or based
upon hop-by-hop verification of resource availability and then
allocation is not really important.  It's the combination of
domain answers which is important.

I think this follows very closely with what Ilya Freytsis wrote
on Tuesday:  "If you view the domain with a QoS technology
as a virtual router than NSIS signaling used between those
routers follows the same path as data. What happens within
the router is not a NSIS business."

As I see it, NSIS must accept all of these possibilities.
I also believe that we need to have standardized ways of
implementing both approaches, not just a domain-specific
free-for-all.    We need to define the interaction between
higher-level NSIS signalling that answers The Domain Question,
which I think will follow the same path as data, and the work
that's done within the domain to answer that question.

The NSIS protocol must be one of the options available for
managing QoS within a domain, but of course a different solution
can be chosen.  That solution may not require that user and
signalling data follow the same path.  However, if the NSIS
protocol is used within the domain, this may be required.

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  Thu Jan 31 11:21: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 LAA01791
	for <nsis-archive@odin.ietf.org>; Thu, 31 Jan 2002 11:20:50 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id LAA01283
	for nsis-archive@odin.ietf.org; Thu, 31 Jan 2002 11:20: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 LAA29926;
	Thu, 31 Jan 2002 11:10: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 LAA29852
	for <nsis@optimus.ietf.org>; Thu, 31 Jan 2002 11:10:49 -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 LAA01193
	for <nsis@ietf.org>; Thu, 31 Jan 2002 11:10:44 -0500 (EST)
Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56])
	by zcars0m9.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g0VGAC502035;
	Thu, 31 Jan 2002 11:10:13 -0500 (EST)
Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7])
	by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g0VGAA507723;
	Thu, 31 Jan 2002 11:10:10 -0500 (EST)
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19)
	id <D8QAVVX0>; Thu, 31 Jan 2002 11:10:09 -0500
Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA47DA@zcard031.ca.nortel.com>
From: "Gary Kenward"<gkenward@nortelnetworks.com>
To: "'dick.rr.knight@bt.com'" <dick.rr.knight@bt.com>,
        Georgios.Karagiannis@eln.ericsson.se, ifreytsis@cetacean.com,
        brunner@ccrle.nec.de
Cc: nsis@ietf.org
Subject: RE: [NSIS] RE: Independence of signalling and data path 
Date: Thu, 31 Jan 2002 11:10:09 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C1AA71.C134E4A0"
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_01C1AA71.C134E4A0
Content-Type: text/plain;
	charset="iso-8859-1"

Dick:

  Sounds reasonable. The only small addition, which is probably obvious, is
to be careful about the need to distinguish between host-to-edge and
edge-to-edge
interactions. At one level of abstraction, a client-server model is
applicable,
where the client is either a host or a network/bandwidth broker. Any
variations in
the solution that distinguishes host-to-edge from edge-to-edge thus needs to
be
justified against the added complexity. And, just to pursue that thought,
given the
activities going on in signalling compression, bandwidth efficiency across
the
host to network link should not be overly emphasized.

 I realize that this abstract will probably break down when we get to the
point
of looking at the specifics of each case. However, I am wondering if it is
possible
to construct the requirements for the more general client-server model? This
could
cut the number of requirements nearly in half, and the associated debate by
an
order of magnitude ;^).

 Just a thought.

Gary

> -----Original Message-----
> From: dick.rr.knight@bt.com [mailto:dick.rr.knight@bt.com]
> Sent: January 31, 2002 07:17
> To: Georgios.Karagiannis@eln.ericsson.se; ifreytsis@Cetacean.com;
> brunner@ccrle.nec.de
> Cc: nsis@ietf.org
> Subject: RE: [NSIS] RE: Independence of signalling and data path 
> 
> 
> 
> I think that we are all moving to is a generic NSIS protocol that is
> applicable to the Host-Edge and the Edge-Edge interfaces. The 
> use of it
> within a domain (hop-hop) must always be the decision of the domain
> operator. This is because:
> 1. An operator of a domain will make their own decisions 
> regarding protocol
> selection
> 2. domain operators need a generalised QoS protocol for interconnect
> 3. Some approaches for QoS (at least the bandwidth part) do 
> not require any
> signalling (e.g. overprovision).
> 
> In case 3, it seems to me this is a specialised case of 
> Edge-Edge. The two
> edges in this case are within a single domain or technology 
> type, and the
> NSIS signalling protocol must traverse it in order to reach 
> the next domain
> or QoS technology type.
> 
> Dick
> 
> 
> -----Original Message-----
> From: Georgios Karagiannis (ELN)
> [mailto:Georgios.Karagiannis@eln.ericsson.se]
> Sent: 31 January 2002 09:03
> To: 'Freytsis, Ilya'; 'brunner@ccrle.nec.de'
> Cc: 'nsis@ietf.org'
> Subject: RE: [NSIS] RE: Independence of signalling and data path 
> 
> 
> Hi Ilya
> 
> Regarding your following statement:
> 
> [IF]>> In other words I am suggesting the following global analogy: 
> [IF]>> If you view the domain with a QoS technology as a 
> [IF]>> virtual router than NSIS
> [IF]>> signaling used between those routers follows the same 
> [IF]>> path as data. What
> [IF]>> happens within the router is not a NSIS business.
> 
> I partially agree! 
> 
> I believe that the NSIS protocol when needed,
> should be capable of operating within a QoS domain
> (that is a QoS domain administrated by a provider).
> However, if the QoS functionality is provided by a Bandwidth Broker
> or the domain is overprovisioned then the signaling path and 
> user data path
> can be independent (not the same). Of course this can be 
> chosen by the 
> provider!
> 
> But when a provider would want to use the NSIS protocol within the 
> domain for QoS support, then it should be possible to set (activate) 
> the NSIS protocol such that the signaling path and user data 
> path use the 
> same path.
> 
> I agree with the rest of your statement!
> 
> Best Regards,
> Georgios
> 
> 
> -----Original Message-----
> From: Freytsis, Ilya [mailto:ifreytsis@Cetacean.com]
> Sent: dinsdag 29 januari 2002 18:45
> To: 'brunner@ccrle.nec.de'
> Cc: 'nsis@ietf.org'
> Subject: [NSIS] RE: Independence of signalling and data path 
> 
> 
> Marcus, 
> 
> Let me add my 2cents into this discussion:
> 
> It looks to me that this discussion got very heated because 
> it is at the
> very border between general QoS signaling and specific QoS 
> technology in use
> (by the domain). The fact that you mentioned such terms as 
> "Controller" and
> "BB" indicates to me that you have a particular technology in 
> mind that
> based on this kind of entities. Tell me how the node at the 
> edge of the RSVP
> or DiffServe domain can get such an idea as a BB that governs the
> neighboring domain. On the other hand the framework advocated 
> by Georgios
> somewhat implies the use of the hop-by-hop QoS technology 
> (and probably for
> this reason is opposed by some people including myself) that relies on
> signaling and data path being the same.
> The way to resolve this conflict in my mind is something 
> along the following
> lines:
> 1. The general NSIS signaling being used between the host and 
> the edge and
> between the edges of the neighboring domains (based on different QoS
> technology) should follow the same path as data (or lay out 
> the path for the
> data if you wish).
> 2. It is up to the edge nodes that understand used within domain QoS
> technology to communicate to the BB or controller and 
> translate NSIS generic
> signaling into something specific for this domain. Obviously 
> the generic
> NSIS signaling has to be recreated at the domain egress edge.
> 3. In this scenario the host can be enabled with the particular QoS
> technology and use specific signaling for communication with the first
> domain or can use generic NSIS signaling.
> 4. The communication between neighboring domains using the same QoS
> technology can be done in the specific for the technology 
> fashion though
> translation to NSIS and back will be always available if for 
> whatever reason
> those domains prefer it.
> 
> In other words I am suggesting the following global analogy: 
> If you view the domain with a QoS technology as a virtual 
> router than NSIS
> signaling used between those routers follows the same path as 
> data. What
> happens within the router is not a NSIS business.
> 
> Ilya Freytsis
> 
> Date: Tue, 29 Jan 2002 11:36:05 +0100
> From: Marcus Brunner <brunner@ccrle.nec.de>
> Reply-To: brunner@ccrle.nec.de
> To: "Georgios Karagiannis (ELN)" 
> <Georgios.Karagiannis@eln.ericsson.se>
> Cc: nsis@ietf.org
> n.se>
> Subject: [NSIS] RE: Independence of signalling and data path 
> (was RE: [NSIS]
> Two			kindsof  requirements)
> 
> Georgios,
> 
> see inline
> 
> --On Monday, January 28, 2002 2:45 PM +0100 "Georgios 
> Karagiannis (ELN)" 
> <Georgios.Karagiannis@eln.ericsson.se> wrote:
> 
> > Hi Marcus
> >
> >
> > [MB]>> So, I think you much in line with that req. The protocol
> > [MB]>> from host to BB does not depend on the data path
> > [MB}>> completly. What the constrain for the
> > [MB]>> communication are is a different question.
> >
> > I will repeat what was already said in my previous e-mail:
> >
> > This is only true when the following CONSIDEARTIONS are
> > fulfilled:
> >
> > * BB's or QoS controllers are used;
> 
> -> QoS controllers are no BBs in our understanding, the hop by hop 
> signalling is a special case, where each hop has a QoS 
> controller and QoS 
> initiator functionality runing.
> 
> > * the end-host should know the address of the first hop 
> Bandwidth Broker;
> 
> An end-host needs to know quite a bit of servers/nodes 
> anyway. I even think 
> there are solutions (e.g. AAA servers), where the first hop router is 
> forwarding the signalling messages to the right place.
> 
> > * the BBs should be aware (know) the addresses of neighboring BBs;
> 
> Sure, you need interdoamin routing anyway.
> 
> > * BB's or QoS controllers should be able to relate
> >    the QoS signaling to the data path;
> >
> 
> yes true, I think this is the core functionality of a 
> signalling protocol. 
> Only depends on the information available in the signaling message.
> 
> >
> >  In GENERAL the above CONSIDERATIONS are very difficult to
> >  fulfill. Please note that we need a NSIS protocol that can
> >  be applied for GENERAL cases. Of course YOUR
> >  SCENARIO, but OTHER TYPES as well will be INCLUDED.
> >
> 
> IMO, with the QoS initator and QoS controller framework we 
> excaclty target 
> a more general case then the hop-by-hop signalling.
> 
> > Thus, in GENERAL the path followed by signaling
> > messages and the path followed by user data packets (associated
> > to these signaling messages) MUST BE THE SAME!!
> >
> 
> No, I do not agree.
> 
> 
> >
> > Solution on how signaling messages and user data
> > packets can follow the same path:
> > The signaling messages will
> > follow the same path as the user data packets when for example,
> > the IP destination address of the signaling messages is the same
> > as the IP destination address of the user data packets.
> 
> Not necessarly (but normally packet with the same destination 
> likely take 
> the same path)
> 
> > Typical IP routing protocols will route both signaling messages
> > and user data packets that have the same IP destination 
> address through
> > the same path. RSVPv1 uses something similar (on the PATH messages
> > and user data packets having the same flow ID);
> >
> > [MB]>> And whether, the
> > [MB]>> protocol work
> > [MB]>> between ehost, eedge, ehop, all of them can be controllers
> > [MB]>> and initiators
> > [MB] on the other side. So they do not require data and signalling
> > [MB] on the same path.
> >
> > What do you mean, would you like to have a NSIS protocol version
> > that starts at one hop router and terminates at the next 
> first hop router.
> > This protocol will be very slow, very complex, and in my opinion
> > not useful!
> >
> 
> You have to be more specific on slow and complex.
> If you mean with slow the signalling delay (I think you are 
> better of not 
> performing some actions in each hop)
> 
> The complextity in terms CPU heavily depends on the 
> complexity of the state 
> machine, which defionitly not defined yet. But you are 
> definitly right, 
> that it needs to be simple.
> 
> Marcus
> 
> >
> > Best regards,
> > Georgios
> >
> >
> >
> >
> 
> 
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis
> 
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis
> 
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis
> 

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2654.89">
<TITLE>RE: [NSIS] RE: Independence of signalling and data path </TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Dick:</FONT>
</P>

<P><FONT SIZE=2>&nbsp; Sounds reasonable. The only small addition, which is probably obvious, is</FONT>
<BR><FONT SIZE=2>to be careful about the need to distinguish between host-to-edge and edge-to-edge</FONT>
<BR><FONT SIZE=2>interactions. At one level of abstraction, a client-server model is applicable,</FONT>
<BR><FONT SIZE=2>where the client is either a host or a network/bandwidth broker. Any variations in</FONT>
<BR><FONT SIZE=2>the solution that distinguishes host-to-edge from edge-to-edge thus needs to be</FONT>
<BR><FONT SIZE=2>justified against the added complexity. And, just to pursue that thought, given the</FONT>
<BR><FONT SIZE=2>activities going on in signalling compression, bandwidth efficiency across the</FONT>
<BR><FONT SIZE=2>host to network link should not be overly emphasized.</FONT>
</P>

<P><FONT SIZE=2>&nbsp;I realize that this abstract will probably break down when we get to the point</FONT>
<BR><FONT SIZE=2>of looking at the specifics of each case. However, I am wondering if it is possible</FONT>
<BR><FONT SIZE=2>to construct the requirements for the more general client-server model? This could</FONT>
<BR><FONT SIZE=2>cut the number of requirements nearly in half, and the associated debate by an</FONT>
<BR><FONT SIZE=2>order of magnitude ;^).</FONT>
</P>

<P><FONT SIZE=2>&nbsp;Just a thought.</FONT>
</P>

<P><FONT SIZE=2>Gary</FONT>
</P>

<P><FONT SIZE=2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; From: dick.rr.knight@bt.com [<A HREF="mailto:dick.rr.knight@bt.com">mailto:dick.rr.knight@bt.com</A>]</FONT>
<BR><FONT SIZE=2>&gt; Sent: January 31, 2002 07:17</FONT>
<BR><FONT SIZE=2>&gt; To: Georgios.Karagiannis@eln.ericsson.se; ifreytsis@Cetacean.com;</FONT>
<BR><FONT SIZE=2>&gt; brunner@ccrle.nec.de</FONT>
<BR><FONT SIZE=2>&gt; Cc: nsis@ietf.org</FONT>
<BR><FONT SIZE=2>&gt; Subject: RE: [NSIS] RE: Independence of signalling and data path </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; I think that we are all moving to is a generic NSIS protocol that is</FONT>
<BR><FONT SIZE=2>&gt; applicable to the Host-Edge and the Edge-Edge interfaces. The </FONT>
<BR><FONT SIZE=2>&gt; use of it</FONT>
<BR><FONT SIZE=2>&gt; within a domain (hop-hop) must always be the decision of the domain</FONT>
<BR><FONT SIZE=2>&gt; operator. This is because:</FONT>
<BR><FONT SIZE=2>&gt; 1. An operator of a domain will make their own decisions </FONT>
<BR><FONT SIZE=2>&gt; regarding protocol</FONT>
<BR><FONT SIZE=2>&gt; selection</FONT>
<BR><FONT SIZE=2>&gt; 2. domain operators need a generalised QoS protocol for interconnect</FONT>
<BR><FONT SIZE=2>&gt; 3. Some approaches for QoS (at least the bandwidth part) do </FONT>
<BR><FONT SIZE=2>&gt; not require any</FONT>
<BR><FONT SIZE=2>&gt; signalling (e.g. overprovision).</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; In case 3, it seems to me this is a specialised case of </FONT>
<BR><FONT SIZE=2>&gt; Edge-Edge. The two</FONT>
<BR><FONT SIZE=2>&gt; edges in this case are within a single domain or technology </FONT>
<BR><FONT SIZE=2>&gt; type, and the</FONT>
<BR><FONT SIZE=2>&gt; NSIS signalling protocol must traverse it in order to reach </FONT>
<BR><FONT SIZE=2>&gt; the next domain</FONT>
<BR><FONT SIZE=2>&gt; or QoS technology type.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Dick</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; From: Georgios Karagiannis (ELN)</FONT>
<BR><FONT SIZE=2>&gt; [<A HREF="mailto:Georgios.Karagiannis@eln.ericsson.se">mailto:Georgios.Karagiannis@eln.ericsson.se</A>]</FONT>
<BR><FONT SIZE=2>&gt; Sent: 31 January 2002 09:03</FONT>
<BR><FONT SIZE=2>&gt; To: 'Freytsis, Ilya'; 'brunner@ccrle.nec.de'</FONT>
<BR><FONT SIZE=2>&gt; Cc: 'nsis@ietf.org'</FONT>
<BR><FONT SIZE=2>&gt; Subject: RE: [NSIS] RE: Independence of signalling and data path </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Hi Ilya</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Regarding your following statement:</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; [IF]&gt;&gt; In other words I am suggesting the following global analogy: </FONT>
<BR><FONT SIZE=2>&gt; [IF]&gt;&gt; If you view the domain with a QoS technology as a </FONT>
<BR><FONT SIZE=2>&gt; [IF]&gt;&gt; virtual router than NSIS</FONT>
<BR><FONT SIZE=2>&gt; [IF]&gt;&gt; signaling used between those routers follows the same </FONT>
<BR><FONT SIZE=2>&gt; [IF]&gt;&gt; path as data. What</FONT>
<BR><FONT SIZE=2>&gt; [IF]&gt;&gt; happens within the router is not a NSIS business.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; I partially agree! </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; I believe that the NSIS protocol when needed,</FONT>
<BR><FONT SIZE=2>&gt; should be capable of operating within a QoS domain</FONT>
<BR><FONT SIZE=2>&gt; (that is a QoS domain administrated by a provider).</FONT>
<BR><FONT SIZE=2>&gt; However, if the QoS functionality is provided by a Bandwidth Broker</FONT>
<BR><FONT SIZE=2>&gt; or the domain is overprovisioned then the signaling path and </FONT>
<BR><FONT SIZE=2>&gt; user data path</FONT>
<BR><FONT SIZE=2>&gt; can be independent (not the same). Of course this can be </FONT>
<BR><FONT SIZE=2>&gt; chosen by the </FONT>
<BR><FONT SIZE=2>&gt; provider!</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; But when a provider would want to use the NSIS protocol within the </FONT>
<BR><FONT SIZE=2>&gt; domain for QoS support, then it should be possible to set (activate) </FONT>
<BR><FONT SIZE=2>&gt; the NSIS protocol such that the signaling path and user data </FONT>
<BR><FONT SIZE=2>&gt; path use the </FONT>
<BR><FONT SIZE=2>&gt; same path.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; I agree with the rest of your statement!</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Best Regards,</FONT>
<BR><FONT SIZE=2>&gt; Georgios</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; From: Freytsis, Ilya [<A HREF="mailto:ifreytsis@Cetacean.com">mailto:ifreytsis@Cetacean.com</A>]</FONT>
<BR><FONT SIZE=2>&gt; Sent: dinsdag 29 januari 2002 18:45</FONT>
<BR><FONT SIZE=2>&gt; To: 'brunner@ccrle.nec.de'</FONT>
<BR><FONT SIZE=2>&gt; Cc: 'nsis@ietf.org'</FONT>
<BR><FONT SIZE=2>&gt; Subject: [NSIS] RE: Independence of signalling and data path </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Marcus, </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Let me add my 2cents into this discussion:</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; It looks to me that this discussion got very heated because </FONT>
<BR><FONT SIZE=2>&gt; it is at the</FONT>
<BR><FONT SIZE=2>&gt; very border between general QoS signaling and specific QoS </FONT>
<BR><FONT SIZE=2>&gt; technology in use</FONT>
<BR><FONT SIZE=2>&gt; (by the domain). The fact that you mentioned such terms as </FONT>
<BR><FONT SIZE=2>&gt; &quot;Controller&quot; and</FONT>
<BR><FONT SIZE=2>&gt; &quot;BB&quot; indicates to me that you have a particular technology in </FONT>
<BR><FONT SIZE=2>&gt; mind that</FONT>
<BR><FONT SIZE=2>&gt; based on this kind of entities. Tell me how the node at the </FONT>
<BR><FONT SIZE=2>&gt; edge of the RSVP</FONT>
<BR><FONT SIZE=2>&gt; or DiffServe domain can get such an idea as a BB that governs the</FONT>
<BR><FONT SIZE=2>&gt; neighboring domain. On the other hand the framework advocated </FONT>
<BR><FONT SIZE=2>&gt; by Georgios</FONT>
<BR><FONT SIZE=2>&gt; somewhat implies the use of the hop-by-hop QoS technology </FONT>
<BR><FONT SIZE=2>&gt; (and probably for</FONT>
<BR><FONT SIZE=2>&gt; this reason is opposed by some people including myself) that relies on</FONT>
<BR><FONT SIZE=2>&gt; signaling and data path being the same.</FONT>
<BR><FONT SIZE=2>&gt; The way to resolve this conflict in my mind is something </FONT>
<BR><FONT SIZE=2>&gt; along the following</FONT>
<BR><FONT SIZE=2>&gt; lines:</FONT>
<BR><FONT SIZE=2>&gt; 1. The general NSIS signaling being used between the host and </FONT>
<BR><FONT SIZE=2>&gt; the edge and</FONT>
<BR><FONT SIZE=2>&gt; between the edges of the neighboring domains (based on different QoS</FONT>
<BR><FONT SIZE=2>&gt; technology) should follow the same path as data (or lay out </FONT>
<BR><FONT SIZE=2>&gt; the path for the</FONT>
<BR><FONT SIZE=2>&gt; data if you wish).</FONT>
<BR><FONT SIZE=2>&gt; 2. It is up to the edge nodes that understand used within domain QoS</FONT>
<BR><FONT SIZE=2>&gt; technology to communicate to the BB or controller and </FONT>
<BR><FONT SIZE=2>&gt; translate NSIS generic</FONT>
<BR><FONT SIZE=2>&gt; signaling into something specific for this domain. Obviously </FONT>
<BR><FONT SIZE=2>&gt; the generic</FONT>
<BR><FONT SIZE=2>&gt; NSIS signaling has to be recreated at the domain egress edge.</FONT>
<BR><FONT SIZE=2>&gt; 3. In this scenario the host can be enabled with the particular QoS</FONT>
<BR><FONT SIZE=2>&gt; technology and use specific signaling for communication with the first</FONT>
<BR><FONT SIZE=2>&gt; domain or can use generic NSIS signaling.</FONT>
<BR><FONT SIZE=2>&gt; 4. The communication between neighboring domains using the same QoS</FONT>
<BR><FONT SIZE=2>&gt; technology can be done in the specific for the technology </FONT>
<BR><FONT SIZE=2>&gt; fashion though</FONT>
<BR><FONT SIZE=2>&gt; translation to NSIS and back will be always available if for </FONT>
<BR><FONT SIZE=2>&gt; whatever reason</FONT>
<BR><FONT SIZE=2>&gt; those domains prefer it.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; In other words I am suggesting the following global analogy: </FONT>
<BR><FONT SIZE=2>&gt; If you view the domain with a QoS technology as a virtual </FONT>
<BR><FONT SIZE=2>&gt; router than NSIS</FONT>
<BR><FONT SIZE=2>&gt; signaling used between those routers follows the same path as </FONT>
<BR><FONT SIZE=2>&gt; data. What</FONT>
<BR><FONT SIZE=2>&gt; happens within the router is not a NSIS business.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Ilya Freytsis</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Date: Tue, 29 Jan 2002 11:36:05 +0100</FONT>
<BR><FONT SIZE=2>&gt; From: Marcus Brunner &lt;brunner@ccrle.nec.de&gt;</FONT>
<BR><FONT SIZE=2>&gt; Reply-To: brunner@ccrle.nec.de</FONT>
<BR><FONT SIZE=2>&gt; To: &quot;Georgios Karagiannis (ELN)&quot; </FONT>
<BR><FONT SIZE=2>&gt; &lt;Georgios.Karagiannis@eln.ericsson.se&gt;</FONT>
<BR><FONT SIZE=2>&gt; Cc: nsis@ietf.org</FONT>
<BR><FONT SIZE=2>&gt; n.se&gt;</FONT>
<BR><FONT SIZE=2>&gt; Subject: [NSIS] RE: Independence of signalling and data path </FONT>
<BR><FONT SIZE=2>&gt; (was RE: [NSIS]</FONT>
<BR><FONT SIZE=2>&gt; Two&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; kindsof&nbsp; requirements)</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Georgios,</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; see inline</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; --On Monday, January 28, 2002 2:45 PM +0100 &quot;Georgios </FONT>
<BR><FONT SIZE=2>&gt; Karagiannis (ELN)&quot; </FONT>
<BR><FONT SIZE=2>&gt; &lt;Georgios.Karagiannis@eln.ericsson.se&gt; wrote:</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; Hi Marcus</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; [MB]&gt;&gt; So, I think you much in line with that req. The protocol</FONT>
<BR><FONT SIZE=2>&gt; &gt; [MB]&gt;&gt; from host to BB does not depend on the data path</FONT>
<BR><FONT SIZE=2>&gt; &gt; [MB}&gt;&gt; completly. What the constrain for the</FONT>
<BR><FONT SIZE=2>&gt; &gt; [MB]&gt;&gt; communication are is a different question.</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; I will repeat what was already said in my previous e-mail:</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; This is only true when the following CONSIDEARTIONS are</FONT>
<BR><FONT SIZE=2>&gt; &gt; fulfilled:</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; * BB's or QoS controllers are used;</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; -&gt; QoS controllers are no BBs in our understanding, the hop by hop </FONT>
<BR><FONT SIZE=2>&gt; signalling is a special case, where each hop has a QoS </FONT>
<BR><FONT SIZE=2>&gt; controller and QoS </FONT>
<BR><FONT SIZE=2>&gt; initiator functionality runing.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; * the end-host should know the address of the first hop </FONT>
<BR><FONT SIZE=2>&gt; Bandwidth Broker;</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; An end-host needs to know quite a bit of servers/nodes </FONT>
<BR><FONT SIZE=2>&gt; anyway. I even think </FONT>
<BR><FONT SIZE=2>&gt; there are solutions (e.g. AAA servers), where the first hop router is </FONT>
<BR><FONT SIZE=2>&gt; forwarding the signalling messages to the right place.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; * the BBs should be aware (know) the addresses of neighboring BBs;</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Sure, you need interdoamin routing anyway.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; * BB's or QoS controllers should be able to relate</FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp; the QoS signaling to the data path;</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; yes true, I think this is the core functionality of a </FONT>
<BR><FONT SIZE=2>&gt; signalling protocol. </FONT>
<BR><FONT SIZE=2>&gt; Only depends on the information available in the signaling message.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp; In GENERAL the above CONSIDERATIONS are very difficult to</FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp; fulfill. Please note that we need a NSIS protocol that can</FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp; be applied for GENERAL cases. Of course YOUR</FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp; SCENARIO, but OTHER TYPES as well will be INCLUDED.</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; IMO, with the QoS initator and QoS controller framework we </FONT>
<BR><FONT SIZE=2>&gt; excaclty target </FONT>
<BR><FONT SIZE=2>&gt; a more general case then the hop-by-hop signalling.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; Thus, in GENERAL the path followed by signaling</FONT>
<BR><FONT SIZE=2>&gt; &gt; messages and the path followed by user data packets (associated</FONT>
<BR><FONT SIZE=2>&gt; &gt; to these signaling messages) MUST BE THE SAME!!</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; No, I do not agree.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; Solution on how signaling messages and user data</FONT>
<BR><FONT SIZE=2>&gt; &gt; packets can follow the same path:</FONT>
<BR><FONT SIZE=2>&gt; &gt; The signaling messages will</FONT>
<BR><FONT SIZE=2>&gt; &gt; follow the same path as the user data packets when for example,</FONT>
<BR><FONT SIZE=2>&gt; &gt; the IP destination address of the signaling messages is the same</FONT>
<BR><FONT SIZE=2>&gt; &gt; as the IP destination address of the user data packets.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Not necessarly (but normally packet with the same destination </FONT>
<BR><FONT SIZE=2>&gt; likely take </FONT>
<BR><FONT SIZE=2>&gt; the same path)</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; Typical IP routing protocols will route both signaling messages</FONT>
<BR><FONT SIZE=2>&gt; &gt; and user data packets that have the same IP destination </FONT>
<BR><FONT SIZE=2>&gt; address through</FONT>
<BR><FONT SIZE=2>&gt; &gt; the same path. RSVPv1 uses something similar (on the PATH messages</FONT>
<BR><FONT SIZE=2>&gt; &gt; and user data packets having the same flow ID);</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; [MB]&gt;&gt; And whether, the</FONT>
<BR><FONT SIZE=2>&gt; &gt; [MB]&gt;&gt; protocol work</FONT>
<BR><FONT SIZE=2>&gt; &gt; [MB]&gt;&gt; between ehost, eedge, ehop, all of them can be controllers</FONT>
<BR><FONT SIZE=2>&gt; &gt; [MB]&gt;&gt; and initiators</FONT>
<BR><FONT SIZE=2>&gt; &gt; [MB] on the other side. So they do not require data and signalling</FONT>
<BR><FONT SIZE=2>&gt; &gt; [MB] on the same path.</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; What do you mean, would you like to have a NSIS protocol version</FONT>
<BR><FONT SIZE=2>&gt; &gt; that starts at one hop router and terminates at the next </FONT>
<BR><FONT SIZE=2>&gt; first hop router.</FONT>
<BR><FONT SIZE=2>&gt; &gt; This protocol will be very slow, very complex, and in my opinion</FONT>
<BR><FONT SIZE=2>&gt; &gt; not useful!</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; You have to be more specific on slow and complex.</FONT>
<BR><FONT SIZE=2>&gt; If you mean with slow the signalling delay (I think you are </FONT>
<BR><FONT SIZE=2>&gt; better of not </FONT>
<BR><FONT SIZE=2>&gt; performing some actions in each hop)</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; The complextity in terms CPU heavily depends on the </FONT>
<BR><FONT SIZE=2>&gt; complexity of the state </FONT>
<BR><FONT SIZE=2>&gt; machine, which defionitly not defined yet. But you are </FONT>
<BR><FONT SIZE=2>&gt; definitly right, </FONT>
<BR><FONT SIZE=2>&gt; that it needs to be simple.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Marcus</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; Best regards,</FONT>
<BR><FONT SIZE=2>&gt; &gt; Georgios</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; _______________________________________________</FONT>
<BR><FONT SIZE=2>&gt; nsis mailing list</FONT>
<BR><FONT SIZE=2>&gt; nsis@ietf.org</FONT>
<BR><FONT SIZE=2>&gt; <A HREF="https://www1.ietf.org/mailman/listinfo/nsis" TARGET="_blank">https://www1.ietf.org/mailman/listinfo/nsis</A></FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; _______________________________________________</FONT>
<BR><FONT SIZE=2>&gt; nsis mailing list</FONT>
<BR><FONT SIZE=2>&gt; nsis@ietf.org</FONT>
<BR><FONT SIZE=2>&gt; <A HREF="https://www1.ietf.org/mailman/listinfo/nsis" TARGET="_blank">https://www1.ietf.org/mailman/listinfo/nsis</A></FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; _______________________________________________</FONT>
<BR><FONT SIZE=2>&gt; nsis mailing list</FONT>
<BR><FONT SIZE=2>&gt; nsis@ietf.org</FONT>
<BR><FONT SIZE=2>&gt; <A HREF="https://www1.ietf.org/mailman/listinfo/nsis" TARGET="_blank">https://www1.ietf.org/mailman/listinfo/nsis</A></FONT>
<BR><FONT SIZE=2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1AA71.C134E4A0--

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



From daemon@optimus.ietf.org  Thu Jan 31 11:37: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 LAA02513
	for <nsis-archive@odin.ietf.org>; Thu, 31 Jan 2002 11:37:17 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id LAA03101
	for nsis-archive@odin.ietf.org; Thu, 31 Jan 2002 11:37: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 LAA01487;
	Thu, 31 Jan 2002 11:23: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 LAA01454
	for <nsis@optimus.ietf.org>; Thu, 31 Jan 2002 11:23:46 -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 LAA01918
	for <nsis@ietf.org>; Thu, 31 Jan 2002 11:23:42 -0500 (EST)
Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56])
	by zcars0m9.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g0VGNE503760;
	Thu, 31 Jan 2002 11:23:14 -0500 (EST)
Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7])
	by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g0VGNC508598;
	Thu, 31 Jan 2002 11:23:12 -0500 (EST)
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19)
	id <D8QAVWGB>; Thu, 31 Jan 2002 11:23:11 -0500
Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA47DB@zcard031.ca.nortel.com>
From: "Gary Kenward"<gkenward@nortelnetworks.com>
To: "'David.Partain@ericsson.com'" <David.Partain@ericsson.com>,
        NSIS Mailing List <nsis@ietf.org>
Subject: RE: [NSIS] summary of thread on data and signalling path
Date: Thu, 31 Jan 2002 11:23:08 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C1AA73.91F6DC00"
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_01C1AA73.91F6DC00
Content-Type: text/plain;
	charset="iso-8859-1"

I have been trying to stay out of this thread, but David triggered a
thought, perhaps one that simplifies the view of the problem.

At the IP layer it is inappropriate for us to attempt to take into
consideration bandwidth sharing issues. The main considerations of
bandwidth sharing are driven by the specifics of the link layer operation
more then protocol definition at the IP layer.

What should be a consideration, is whether the protocol has the ability
to be optionally routed along the same path as the data or a completely
or partially separate path. Ideally, the capability to route the protocol
along an independent path, would give the network designer/operator the 
option to manage bandwidth utilization through the topology.

One other, more minor observation, is we need to be very cautious about
solutions that build forwarding paths through the network, with state 
information at the nodes. This is the RSVP model, and it causes great 
grief for IP mobility solutions.

Gary

> -----Original Message-----
> From: David Partain [mailto:David.Partain@ericsson.com]
> Sent: January 31, 2002 09:06
> To: NSIS Mailing List
> Subject: [NSIS] summary of thread on data and signalling path
> 
> 
> Hi all,
> 
> Here I go again, trying to digest a Monster Thread...
> 
> The question posed is, "Do signalling and data need to follow the
> same path in order to achieve what we're after with NSIS?"
> 
> 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.
> 
>  - There are absolutely going to be cases where there will _not_
>    be a centralized entity managing resources and that the
>    signalling will be used as a tool for resource management.
>    For various reasons (such as efficient use of expensive
>    bandwidth), one will want to have fine-grained, fast,
>    and very dynamic control of the resources in the network.
> 
>  - There are going to be cases where there will be neither
>    signalling nor a centralized entity (overprovisioning).
>    In this case, the question posed just doesn't matter :-)
> 
> There are other possibilities as well.
> 
> Perhaps I'm being repetitive, but it's seems to me that the
> important issue is that the domain answers the question,
> "May I have what I want?"  Whether it bases the answer on a
> centralized entity saying, "Sure, have a good time" or based
> upon hop-by-hop verification of resource availability and then
> allocation is not really important.  It's the combination of
> domain answers which is important.
> 
> I think this follows very closely with what Ilya Freytsis wrote
> on Tuesday:  "If you view the domain with a QoS technology
> as a virtual router than NSIS signaling used between those
> routers follows the same path as data. What happens within
> the router is not a NSIS business."
> 
> As I see it, NSIS must accept all of these possibilities.
> I also believe that we need to have standardized ways of
> implementing both approaches, not just a domain-specific
> free-for-all.    We need to define the interaction between
> higher-level NSIS signalling that answers The Domain Question,
> which I think will follow the same path as data, and the work
> that's done within the domain to answer that question.
> 
> The NSIS protocol must be one of the options available for
> managing QoS within a domain, but of course a different solution
> can be chosen.  That solution may not require that user and
> signalling data follow the same path.  However, if the NSIS
> protocol is used within the domain, this may be required.
> 
> Cheers,
> 
> dlp
> 
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis
> 

------_=_NextPart_001_01C1AA73.91F6DC00
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2654.89">
<TITLE>RE: [NSIS] summary of thread on data and signalling path</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>I have been trying to stay out of this thread, but David triggered a</FONT>
<BR><FONT SIZE=2>thought, perhaps one that simplifies the view of the problem.</FONT>
</P>

<P><FONT SIZE=2>At the IP layer it is inappropriate for us to attempt to take into</FONT>
<BR><FONT SIZE=2>consideration bandwidth sharing issues. The main considerations of</FONT>
<BR><FONT SIZE=2>bandwidth sharing are driven by the specifics of the link layer operation</FONT>
<BR><FONT SIZE=2>more then protocol definition at the IP layer.</FONT>
</P>

<P><FONT SIZE=2>What should be a consideration, is whether the protocol has the ability</FONT>
<BR><FONT SIZE=2>to be optionally routed along the same path as the data or a completely</FONT>
<BR><FONT SIZE=2>or partially separate path. Ideally, the capability to route the protocol</FONT>
<BR><FONT SIZE=2>along an independent path, would give the network designer/operator the </FONT>
<BR><FONT SIZE=2>option to manage bandwidth utilization through the topology.</FONT>
</P>

<P><FONT SIZE=2>One other, more minor observation, is we need to be very cautious about</FONT>
<BR><FONT SIZE=2>solutions that build forwarding paths through the network, with state </FONT>
<BR><FONT SIZE=2>information at the nodes. This is the RSVP model, and it causes great </FONT>
<BR><FONT SIZE=2>grief for IP mobility solutions.</FONT>
</P>

<P><FONT SIZE=2>Gary</FONT>
</P>

<P><FONT SIZE=2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; From: David Partain [<A HREF="mailto:David.Partain@ericsson.com">mailto:David.Partain@ericsson.com</A>]</FONT>
<BR><FONT SIZE=2>&gt; Sent: January 31, 2002 09:06</FONT>
<BR><FONT SIZE=2>&gt; To: NSIS Mailing List</FONT>
<BR><FONT SIZE=2>&gt; Subject: [NSIS] summary of thread on data and signalling path</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Hi all,</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Here I go again, trying to digest a Monster Thread...</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; The question posed is, &quot;Do signalling and data need to follow the</FONT>
<BR><FONT SIZE=2>&gt; same path in order to achieve what we're after with NSIS?&quot;</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Marcus started this thread by stating that he doesn't think this</FONT>
<BR><FONT SIZE=2>&gt; should be a requirement.&nbsp; I think we need to consider the</FONT>
<BR><FONT SIZE=2>&gt; scenarios.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt;&nbsp; - There are absolutely going to be cases where a centralized</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; entity will take a decision about QoS requests.&nbsp; In this</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; case, there's no question there is no need to have data</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; follow the signalling path.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt;&nbsp; - There are absolutely going to be cases where there will _not_</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; be a centralized entity managing resources and that the</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; signalling will be used as a tool for resource management.</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; For various reasons (such as efficient use of expensive</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; bandwidth), one will want to have fine-grained, fast,</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; and very dynamic control of the resources in the network.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt;&nbsp; - There are going to be cases where there will be neither</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; signalling nor a centralized entity (overprovisioning).</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; In this case, the question posed just doesn't matter :-)</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; There are other possibilities as well.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Perhaps I'm being repetitive, but it's seems to me that the</FONT>
<BR><FONT SIZE=2>&gt; important issue is that the domain answers the question,</FONT>
<BR><FONT SIZE=2>&gt; &quot;May I have what I want?&quot;&nbsp; Whether it bases the answer on a</FONT>
<BR><FONT SIZE=2>&gt; centralized entity saying, &quot;Sure, have a good time&quot; or based</FONT>
<BR><FONT SIZE=2>&gt; upon hop-by-hop verification of resource availability and then</FONT>
<BR><FONT SIZE=2>&gt; allocation is not really important.&nbsp; It's the combination of</FONT>
<BR><FONT SIZE=2>&gt; domain answers which is important.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; I think this follows very closely with what Ilya Freytsis wrote</FONT>
<BR><FONT SIZE=2>&gt; on Tuesday:&nbsp; &quot;If you view the domain with a QoS technology</FONT>
<BR><FONT SIZE=2>&gt; as a virtual router than NSIS signaling used between those</FONT>
<BR><FONT SIZE=2>&gt; routers follows the same path as data. What happens within</FONT>
<BR><FONT SIZE=2>&gt; the router is not a NSIS business.&quot;</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; As I see it, NSIS must accept all of these possibilities.</FONT>
<BR><FONT SIZE=2>&gt; I also believe that we need to have standardized ways of</FONT>
<BR><FONT SIZE=2>&gt; implementing both approaches, not just a domain-specific</FONT>
<BR><FONT SIZE=2>&gt; free-for-all.&nbsp;&nbsp;&nbsp; We need to define the interaction between</FONT>
<BR><FONT SIZE=2>&gt; higher-level NSIS signalling that answers The Domain Question,</FONT>
<BR><FONT SIZE=2>&gt; which I think will follow the same path as data, and the work</FONT>
<BR><FONT SIZE=2>&gt; that's done within the domain to answer that question.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; The NSIS protocol must be one of the options available for</FONT>
<BR><FONT SIZE=2>&gt; managing QoS within a domain, but of course a different solution</FONT>
<BR><FONT SIZE=2>&gt; can be chosen.&nbsp; That solution may not require that user and</FONT>
<BR><FONT SIZE=2>&gt; signalling data follow the same path.&nbsp; However, if the NSIS</FONT>
<BR><FONT SIZE=2>&gt; protocol is used within the domain, this may be required.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Cheers,</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; dlp</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; _______________________________________________</FONT>
<BR><FONT SIZE=2>&gt; nsis mailing list</FONT>
<BR><FONT SIZE=2>&gt; nsis@ietf.org</FONT>
<BR><FONT SIZE=2>&gt; <A HREF="https://www1.ietf.org/mailman/listinfo/nsis" TARGET="_blank">https://www1.ietf.org/mailman/listinfo/nsis</A></FONT>
<BR><FONT SIZE=2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1AA73.91F6DC00--

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



From daemon@optimus.ietf.org  Thu Jan 31 12:05: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 MAA03570
	for <nsis-archive@odin.ietf.org>; Thu, 31 Jan 2002 12:05:12 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id MAA06442
	for nsis-archive@odin.ietf.org; Thu, 31 Jan 2002 12:05: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 LAA04429;
	Thu, 31 Jan 2002 11:55: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 LAA04382
	for <nsis@optimus.ietf.org>; Thu, 31 Jan 2002 11:55:25 -0500 (EST)
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03127
	for <nsis@ietf.org>; Thu, 31 Jan 2002 11:55:20 -0500 (EST)
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id g0VGsp616840;
	Thu, 31 Jan 2002 08:54:52 -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 AAU26350;
	Thu, 31 Jan 2002 08:54:21 -0800 (PST)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA22437; Thu, 31 Jan 2002 08:54:51 -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: <15449.30427.5587.662644@thomasm-u1.cisco.com>
Date: Thu, 31 Jan 2002 08:54:51 -0800 (PST)
To: David.Partain@ericsson.com
Cc: NSIS Mailing List <nsis@ietf.org>
Subject: [NSIS] summary of thread on data and signalling path
In-Reply-To: <0GQT00A5D35168@mbb1.ericsson.se>
References: <0GQT00A5D35168@mbb1.ericsson.se>
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

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?

	   Mike

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



From daemon@optimus.ietf.org  Thu Jan 31 12:10: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 MAA03908
	for <nsis-archive@odin.ietf.org>; Thu, 31 Jan 2002 12:10:24 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id MAA06937
	for nsis-archive@odin.ietf.org; Thu, 31 Jan 2002 12:10: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 LAA04185;
	Thu, 31 Jan 2002 11:52:58 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA04119
	for <nsis@optimus.ietf.org>; Thu, 31 Jan 2002 11:52:53 -0500 (EST)
Received: from cbibipnt03.HC.BT.COM (saturn.bt.com [193.113.57.20])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03043
	for <nsis@ietf.org>; Thu, 31 Jan 2002 11:52:48 -0500 (EST)
From: dick.rr.knight@bt.com
Received: by cbibipnt03.hc.bt.com with Internet Mail Service (5.5.2652.35)
	id <D03BBST2>; Thu, 31 Jan 2002 16:52:09 -0000
Message-ID: <451D45016C2CD2119DA50000F8FE7F07080E5AAA@mlngcbnt01.hc.bt.com>
To: gkenward@nortelnetworks.com, dick.rr.knight@bt.com,
        Georgios.Karagiannis@eln.ericsson.se, ifreytsis@cetacean.com,
        brunner@ccrle.nec.de
Cc: nsis@ietf.org
Subject: RE: [NSIS] RE: Independence of signalling and data path (host-edg
	e vs edge-edge & b/w at final hop)
Date: Thu, 31 Jan 2002 16:51:40 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C1AA77.8E127910"
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_01C1AA77.8E127910
Content-Type: text/plain;
	charset="iso-8859-1"

I am sort of split on the differences and similarities between host-edge and
edge-edge (which don't quite equate to UNI and NNI in telephony).
 
A protocol that highlights the differences will not be popular in the IETF,
where the end-to-end model stills reigns and is seen as being something that
should still be supported. However, some of the security aspects of spoofing
to steal others bandwidth is a worry.
 
I was not quite sure what you meant by "given the 
activities going on in signalling compression, bandwidth efficiency across
the 
host to network link should not be overly emphasized." I thought that there
was a need for efficiency in the 3G radio world, and other scenarios where
"final hop" bandwidth is severely limited.
 
Dick 

-----Original Message-----
From: Gary Kenward [mailto:gkenward@nortelnetworks.com]
Sent: 31 January 2002 16:10
To: 'dick.rr.knight@bt.com'; Georgios.Karagiannis@eln.ericsson.se;
ifreytsis@Cetacean.com; brunner@ccrle.nec.de
Cc: nsis@ietf.org
Subject: RE: [NSIS] RE: Independence of signalling and data path 



Dick: 

  Sounds reasonable. The only small addition, which is probably obvious, is 
to be careful about the need to distinguish between host-to-edge and
edge-to-edge 
interactions. At one level of abstraction, a client-server model is
applicable, 
where the client is either a host or a network/bandwidth broker. Any
variations in 
the solution that distinguishes host-to-edge from edge-to-edge thus needs to
be 
justified against the added complexity. And, just to pursue that thought,
given the 
activities going on in signalling compression, bandwidth efficiency across
the 
host to network link should not be overly emphasized. 

 I realize that this abstract will probably break down when we get to the
point 
of looking at the specifics of each case. However, I am wondering if it is
possible 
to construct the requirements for the more general client-server model? This
could 
cut the number of requirements nearly in half, and the associated debate by
an 
order of magnitude ;^). 

 Just a thought. 

Gary 

> -----Original Message----- 
> From: dick.rr.knight@bt.com [ mailto:dick.rr.knight@bt.com
<mailto:dick.rr.knight@bt.com> ] 
> Sent: January 31, 2002 07:17 
> To: Georgios.Karagiannis@eln.ericsson.se; ifreytsis@Cetacean.com; 
> brunner@ccrle.nec.de 
> Cc: nsis@ietf.org 
> Subject: RE: [NSIS] RE: Independence of signalling and data path 
> 
> 
> 
> I think that we are all moving to is a generic NSIS protocol that is 
> applicable to the Host-Edge and the Edge-Edge interfaces. The 
> use of it 
> within a domain (hop-hop) must always be the decision of the domain 
> operator. This is because: 
> 1. An operator of a domain will make their own decisions 
> regarding protocol 
> selection 
> 2. domain operators need a generalised QoS protocol for interconnect 
> 3. Some approaches for QoS (at least the bandwidth part) do 
> not require any 
> signalling (e.g. overprovision). 
> 
> In case 3, it seems to me this is a specialised case of 
> Edge-Edge. The two 
> edges in this case are within a single domain or technology 
> type, and the 
> NSIS signalling protocol must traverse it in order to reach 
> the next domain 
> or QoS technology type. 
> 
> Dick 
> 
> 
> -----Original Message----- 
> From: Georgios Karagiannis (ELN) 
> [ mailto:Georgios.Karagiannis@eln.ericsson.se
<mailto:Georgios.Karagiannis@eln.ericsson.se> ] 
> Sent: 31 January 2002 09:03 
> To: 'Freytsis, Ilya'; 'brunner@ccrle.nec.de' 
> Cc: 'nsis@ietf.org' 
> Subject: RE: [NSIS] RE: Independence of signalling and data path 
> 
> 
> Hi Ilya 
> 
> Regarding your following statement: 
> 
> [IF]>> In other words I am suggesting the following global analogy: 
> [IF]>> If you view the domain with a QoS technology as a 
> [IF]>> virtual router than NSIS 
> [IF]>> signaling used between those routers follows the same 
> [IF]>> path as data. What 
> [IF]>> happens within the router is not a NSIS business. 
> 
> I partially agree! 
> 
> I believe that the NSIS protocol when needed, 
> should be capable of operating within a QoS domain 
> (that is a QoS domain administrated by a provider). 
> However, if the QoS functionality is provided by a Bandwidth Broker 
> or the domain is overprovisioned then the signaling path and 
> user data path 
> can be independent (not the same). Of course this can be 
> chosen by the 
> provider! 
> 
> But when a provider would want to use the NSIS protocol within the 
> domain for QoS support, then it should be possible to set (activate) 
> the NSIS protocol such that the signaling path and user data 
> path use the 
> same path. 
> 
> I agree with the rest of your statement! 
> 
> Best Regards, 
> Georgios 
> 
> 
> -----Original Message----- 
> From: Freytsis, Ilya [ mailto:ifreytsis@Cetacean.com
<mailto:ifreytsis@Cetacean.com> ] 
> Sent: dinsdag 29 januari 2002 18:45 
> To: 'brunner@ccrle.nec.de' 
> Cc: 'nsis@ietf.org' 
> Subject: [NSIS] RE: Independence of signalling and data path 
> 
> 
> Marcus, 
> 
> Let me add my 2cents into this discussion: 
> 
> It looks to me that this discussion got very heated because 
> it is at the 
> very border between general QoS signaling and specific QoS 
> technology in use 
> (by the domain). The fact that you mentioned such terms as 
> "Controller" and 
> "BB" indicates to me that you have a particular technology in 
> mind that 
> based on this kind of entities. Tell me how the node at the 
> edge of the RSVP 
> or DiffServe domain can get such an idea as a BB that governs the 
> neighboring domain. On the other hand the framework advocated 
> by Georgios 
> somewhat implies the use of the hop-by-hop QoS technology 
> (and probably for 
> this reason is opposed by some people including myself) that relies on 
> signaling and data path being the same. 
> The way to resolve this conflict in my mind is something 
> along the following 
> lines: 
> 1. The general NSIS signaling being used between the host and 
> the edge and 
> between the edges of the neighboring domains (based on different QoS 
> technology) should follow the same path as data (or lay out 
> the path for the 
> data if you wish). 
> 2. It is up to the edge nodes that understand used within domain QoS 
> technology to communicate to the BB or controller and 
> translate NSIS generic 
> signaling into something specific for this domain. Obviously 
> the generic 
> NSIS signaling has to be recreated at the domain egress edge. 
> 3. In this scenario the host can be enabled with the particular QoS 
> technology and use specific signaling for communication with the first 
> domain or can use generic NSIS signaling. 
> 4. The communication between neighboring domains using the same QoS 
> technology can be done in the specific for the technology 
> fashion though 
> translation to NSIS and back will be always available if for 
> whatever reason 
> those domains prefer it. 
> 
> In other words I am suggesting the following global analogy: 
> If you view the domain with a QoS technology as a virtual 
> router than NSIS 
> signaling used between those routers follows the same path as 
> data. What 
> happens within the router is not a NSIS business. 
> 
> Ilya Freytsis 
> 
> Date: Tue, 29 Jan 2002 11:36:05 +0100 
> From: Marcus Brunner <brunner@ccrle.nec.de> 
> Reply-To: brunner@ccrle.nec.de 
> To: "Georgios Karagiannis (ELN)" 
> <Georgios.Karagiannis@eln.ericsson.se> 
> Cc: nsis@ietf.org 
> n.se> 
> Subject: [NSIS] RE: Independence of signalling and data path 
> (was RE: [NSIS] 
> Two                   kindsof  requirements) 
> 
> Georgios, 
> 
> see inline 
> 
> --On Monday, January 28, 2002 2:45 PM +0100 "Georgios 
> Karagiannis (ELN)" 
> <Georgios.Karagiannis@eln.ericsson.se> wrote: 
> 
> > Hi Marcus 
> > 
> > 
> > [MB]>> So, I think you much in line with that req. The protocol 
> > [MB]>> from host to BB does not depend on the data path 
> > [MB}>> completly. What the constrain for the 
> > [MB]>> communication are is a different question. 
> > 
> > I will repeat what was already said in my previous e-mail: 
> > 
> > This is only true when the following CONSIDEARTIONS are 
> > fulfilled: 
> > 
> > * BB's or QoS controllers are used; 
> 
> -> QoS controllers are no BBs in our understanding, the hop by hop 
> signalling is a special case, where each hop has a QoS 
> controller and QoS 
> initiator functionality runing. 
> 
> > * the end-host should know the address of the first hop 
> Bandwidth Broker; 
> 
> An end-host needs to know quite a bit of servers/nodes 
> anyway. I even think 
> there are solutions (e.g. AAA servers), where the first hop router is 
> forwarding the signalling messages to the right place. 
> 
> > * the BBs should be aware (know) the addresses of neighboring BBs; 
> 
> Sure, you need interdoamin routing anyway. 
> 
> > * BB's or QoS controllers should be able to relate 
> >    the QoS signaling to the data path; 
> > 
> 
> yes true, I think this is the core functionality of a 
> signalling protocol. 
> Only depends on the information available in the signaling message. 
> 
> > 
> >  In GENERAL the above CONSIDERATIONS are very difficult to 
> >  fulfill. Please note that we need a NSIS protocol that can 
> >  be applied for GENERAL cases. Of course YOUR 
> >  SCENARIO, but OTHER TYPES as well will be INCLUDED. 
> > 
> 
> IMO, with the QoS initator and QoS controller framework we 
> excaclty target 
> a more general case then the hop-by-hop signalling. 
> 
> > Thus, in GENERAL the path followed by signaling 
> > messages and the path followed by user data packets (associated 
> > to these signaling messages) MUST BE THE SAME!! 
> > 
> 
> No, I do not agree. 
> 
> 
> > 
> > Solution on how signaling messages and user data 
> > packets can follow the same path: 
> > The signaling messages will 
> > follow the same path as the user data packets when for example, 
> > the IP destination address of the signaling messages is the same 
> > as the IP destination address of the user data packets. 
> 
> Not necessarly (but normally packet with the same destination 
> likely take 
> the same path) 
> 
> > Typical IP routing protocols will route both signaling messages 
> > and user data packets that have the same IP destination 
> address through 
> > the same path. RSVPv1 uses something similar (on the PATH messages 
> > and user data packets having the same flow ID); 
> > 
> > [MB]>> And whether, the 
> > [MB]>> protocol work 
> > [MB]>> between ehost, eedge, ehop, all of them can be controllers 
> > [MB]>> and initiators 
> > [MB] on the other side. So they do not require data and signalling 
> > [MB] on the same path. 
> > 
> > What do you mean, would you like to have a NSIS protocol version 
> > that starts at one hop router and terminates at the next 
> first hop router. 
> > This protocol will be very slow, very complex, and in my opinion 
> > not useful! 
> > 
> 
> You have to be more specific on slow and complex. 
> If you mean with slow the signalling delay (I think you are 
> better of not 
> performing some actions in each hop) 
> 
> The complextity in terms CPU heavily depends on the 
> complexity of the state 
> machine, which defionitly not defined yet. But you are 
> definitly right, 
> that it needs to be simple. 
> 
> Marcus 
> 
> > 
> > Best regards, 
> > Georgios 
> > 
> > 
> > 
> > 
> 
> 
> _______________________________________________ 
> nsis mailing list 
> nsis@ietf.org 
> https://www1.ietf.org/mailman/listinfo/nsis
<https://www1.ietf.org/mailman/listinfo/nsis>  
> 
> _______________________________________________ 
> nsis mailing list 
> nsis@ietf.org 
> https://www1.ietf.org/mailman/listinfo/nsis
<https://www1.ietf.org/mailman/listinfo/nsis>  
> 
> _______________________________________________ 
> nsis mailing list 
> nsis@ietf.org 
> https://www1.ietf.org/mailman/listinfo/nsis
<https://www1.ietf.org/mailman/listinfo/nsis>  
> 


------_=_NextPart_001_01C1AA77.8E127910
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">
<TITLE>RE: [NSIS] RE: Independence of signalling and data path</TITLE>

<META content="MSHTML 5.50.4134.600" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=770184616-31012002><FONT face=Arial color=#0000ff size=2>I am 
sort of split on the differences and similarities between host-edge and 
edge-edge (which don't quite equate to UNI and NNI in 
telephony).</FONT></SPAN></DIV>
<DIV><SPAN class=770184616-31012002><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=770184616-31012002><FONT face=Arial color=#0000ff size=2>A 
protocol that highlights the differences will not be popular in the IETF, where 
the end-to-end model stills reigns and is seen as being something that should 
still be supported. However, some of the security aspects of spoofing to steal 
others bandwidth is a worry.</FONT></SPAN></DIV>
<DIV><SPAN class=770184616-31012002><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=770184616-31012002><FONT face=Arial color=#0000ff size=2>I was 
not quite sure what you meant by "<FONT face="Times New Roman" 
color=#000080>given the</FONT><FONT color=#000080><FONT 
face="Times New Roman"><FONT size=3> <BR></FONT><FONT size=2>activities going on 
in signalling compression, bandwidth efficiency across 
the</FONT></FONT></FONT><FONT color=#000080><FONT face="Times New Roman"><FONT 
size=3> <BR></FONT><FONT size=2>host to network link should not be overly 
emphasized.<FONT face=Arial color=#0000ff>"&nbsp;I thought that&nbsp;there was a 
need for efficiency in the 3G radio world, and other scenarios where 
"final&nbsp;hop" bandwidth is severely 
limited.</FONT></FONT></FONT></FONT></FONT></SPAN></DIV>
<DIV><SPAN class=770184616-31012002></SPAN>&nbsp;</DIV>
<DIV><SPAN class=770184616-31012002><FONT face=Arial color=#0000ff 
size=2>Dick</FONT>&nbsp;</SPAN></DIV>
<BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Gary Kenward 
  [mailto:gkenward@nortelnetworks.com]<BR><B>Sent:</B> 31 January 2002 
  16:10<BR><B>To:</B> 'dick.rr.knight@bt.com'; 
  Georgios.Karagiannis@eln.ericsson.se; ifreytsis@Cetacean.com; 
  brunner@ccrle.nec.de<BR><B>Cc:</B> nsis@ietf.org<BR><B>Subject:</B> RE: [NSIS] 
  RE: Independence of signalling and data path <BR><BR></FONT></DIV>
  <P><FONT size=2>Dick:</FONT> </P>
  <P><FONT size=2>&nbsp; Sounds reasonable. The only small addition, which is 
  probably obvious, is</FONT> <BR><FONT size=2>to be careful about the need to 
  distinguish between host-to-edge and edge-to-edge</FONT> <BR><FONT 
  size=2>interactions. At one level of abstraction, a client-server model is 
  applicable,</FONT> <BR><FONT size=2>where the client is either a host or a 
  network/bandwidth broker. Any variations in</FONT> <BR><FONT size=2>the 
  solution that distinguishes host-to-edge from edge-to-edge thus needs to 
  be</FONT> <BR><FONT size=2>justified against the added complexity. And, just 
  to pursue that thought, given the</FONT> <BR><FONT size=2>activities going on 
  in signalling compression, bandwidth efficiency across the</FONT> <BR><FONT 
  size=2>host to network link should not be overly emphasized.</FONT> </P>
  <P><FONT size=2>&nbsp;I realize that this abstract will probably break down 
  when we get to the point</FONT> <BR><FONT size=2>of looking at the specifics 
  of each case. However, I am wondering if it is possible</FONT> <BR><FONT 
  size=2>to construct the requirements for the more general client-server model? 
  This could</FONT> <BR><FONT size=2>cut the number of requirements nearly in 
  half, and the associated debate by an</FONT> <BR><FONT size=2>order of 
  magnitude ;^).</FONT> </P>
  <P><FONT size=2>&nbsp;Just a thought.</FONT> </P>
  <P><FONT size=2>Gary</FONT> </P>
  <P><FONT size=2>&gt; -----Original Message-----</FONT> <BR><FONT size=2>&gt; 
  From: dick.rr.knight@bt.com [<A 
  href="mailto:dick.rr.knight@bt.com">mailto:dick.rr.knight@bt.com</A>]</FONT> 
  <BR><FONT size=2>&gt; Sent: January 31, 2002 07:17</FONT> <BR><FONT 
  size=2>&gt; To: Georgios.Karagiannis@eln.ericsson.se; 
  ifreytsis@Cetacean.com;</FONT> <BR><FONT size=2>&gt; 
  brunner@ccrle.nec.de</FONT> <BR><FONT size=2>&gt; Cc: nsis@ietf.org</FONT> 
  <BR><FONT size=2>&gt; Subject: RE: [NSIS] RE: Independence of signalling and 
  data path </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; 
  </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; I think that we are 
  all moving to is a generic NSIS protocol that is</FONT> <BR><FONT size=2>&gt; 
  applicable to the Host-Edge and the Edge-Edge interfaces. The </FONT><BR><FONT 
  size=2>&gt; use of it</FONT> <BR><FONT size=2>&gt; within a domain (hop-hop) 
  must always be the decision of the domain</FONT> <BR><FONT size=2>&gt; 
  operator. This is because:</FONT> <BR><FONT size=2>&gt; 1. An operator of a 
  domain will make their own decisions </FONT><BR><FONT size=2>&gt; regarding 
  protocol</FONT> <BR><FONT size=2>&gt; selection</FONT> <BR><FONT size=2>&gt; 
  2. domain operators need a generalised QoS protocol for interconnect</FONT> 
  <BR><FONT size=2>&gt; 3. Some approaches for QoS (at least the bandwidth part) 
  do </FONT><BR><FONT size=2>&gt; not require any</FONT> <BR><FONT size=2>&gt; 
  signalling (e.g. overprovision).</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT 
  size=2>&gt; In case 3, it seems to me this is a specialised case of 
  </FONT><BR><FONT size=2>&gt; Edge-Edge. The two</FONT> <BR><FONT size=2>&gt; 
  edges in this case are within a single domain or technology </FONT><BR><FONT 
  size=2>&gt; type, and the</FONT> <BR><FONT size=2>&gt; NSIS signalling 
  protocol must traverse it in order to reach </FONT><BR><FONT size=2>&gt; the 
  next domain</FONT> <BR><FONT size=2>&gt; or QoS technology type.</FONT> 
  <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; Dick</FONT> <BR><FONT 
  size=2>&gt; </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; 
  -----Original Message-----</FONT> <BR><FONT size=2>&gt; From: Georgios 
  Karagiannis (ELN)</FONT> <BR><FONT size=2>&gt; [<A 
  href="mailto:Georgios.Karagiannis@eln.ericsson.se">mailto:Georgios.Karagiannis@eln.ericsson.se</A>]</FONT> 
  <BR><FONT size=2>&gt; Sent: 31 January 2002 09:03</FONT> <BR><FONT size=2>&gt; 
  To: 'Freytsis, Ilya'; 'brunner@ccrle.nec.de'</FONT> <BR><FONT size=2>&gt; Cc: 
  'nsis@ietf.org'</FONT> <BR><FONT size=2>&gt; Subject: RE: [NSIS] RE: 
  Independence of signalling and data path </FONT><BR><FONT size=2>&gt; 
  </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; Hi Ilya</FONT> 
  <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; Regarding your following 
  statement:</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; 
  [IF]&gt;&gt; In other words I am suggesting the following global analogy: 
  </FONT><BR><FONT size=2>&gt; [IF]&gt;&gt; If you view the domain with a QoS 
  technology as a </FONT><BR><FONT size=2>&gt; [IF]&gt;&gt; virtual router than 
  NSIS</FONT> <BR><FONT size=2>&gt; [IF]&gt;&gt; signaling used between those 
  routers follows the same </FONT><BR><FONT size=2>&gt; [IF]&gt;&gt; path as 
  data. What</FONT> <BR><FONT size=2>&gt; [IF]&gt;&gt; happens within the router 
  is not a NSIS business.</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT 
  size=2>&gt; I partially agree! </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT 
  size=2>&gt; I believe that the NSIS protocol when needed,</FONT> <BR><FONT 
  size=2>&gt; should be capable of operating within a QoS domain</FONT> 
  <BR><FONT size=2>&gt; (that is a QoS domain administrated by a 
  provider).</FONT> <BR><FONT size=2>&gt; However, if the QoS functionality is 
  provided by a Bandwidth Broker</FONT> <BR><FONT size=2>&gt; or the domain is 
  overprovisioned then the signaling path and </FONT><BR><FONT size=2>&gt; user 
  data path</FONT> <BR><FONT size=2>&gt; can be independent (not the same). Of 
  course this can be </FONT><BR><FONT size=2>&gt; chosen by the </FONT><BR><FONT 
  size=2>&gt; provider!</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT 
  size=2>&gt; But when a provider would want to use the NSIS protocol within the 
  </FONT><BR><FONT size=2>&gt; domain for QoS support, then it should be 
  possible to set (activate) </FONT><BR><FONT size=2>&gt; the NSIS protocol such 
  that the signaling path and user data </FONT><BR><FONT size=2>&gt; path use 
  the </FONT><BR><FONT size=2>&gt; same path.</FONT> <BR><FONT size=2>&gt; 
  </FONT><BR><FONT size=2>&gt; I agree with the rest of your statement!</FONT> 
  <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; Best Regards,</FONT> 
  <BR><FONT size=2>&gt; Georgios</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT 
  size=2>&gt; </FONT><BR><FONT size=2>&gt; -----Original Message-----</FONT> 
  <BR><FONT size=2>&gt; From: Freytsis, Ilya [<A 
  href="mailto:ifreytsis@Cetacean.com">mailto:ifreytsis@Cetacean.com</A>]</FONT> 
  <BR><FONT size=2>&gt; Sent: dinsdag 29 januari 2002 18:45</FONT> <BR><FONT 
  size=2>&gt; To: 'brunner@ccrle.nec.de'</FONT> <BR><FONT size=2>&gt; Cc: 
  'nsis@ietf.org'</FONT> <BR><FONT size=2>&gt; Subject: [NSIS] RE: Independence 
  of signalling and data path </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT 
  size=2>&gt; </FONT><BR><FONT size=2>&gt; Marcus, </FONT><BR><FONT size=2>&gt; 
  </FONT><BR><FONT size=2>&gt; Let me add my 2cents into this discussion:</FONT> 
  <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; It looks to me that this 
  discussion got very heated because </FONT><BR><FONT size=2>&gt; it is at 
  the</FONT> <BR><FONT size=2>&gt; very border between general QoS signaling and 
  specific QoS </FONT><BR><FONT size=2>&gt; technology in use</FONT> <BR><FONT 
  size=2>&gt; (by the domain). The fact that you mentioned such terms as 
  </FONT><BR><FONT size=2>&gt; "Controller" and</FONT> <BR><FONT size=2>&gt; 
  "BB" indicates to me that you have a particular technology in </FONT><BR><FONT 
  size=2>&gt; mind that</FONT> <BR><FONT size=2>&gt; based on this kind of 
  entities. Tell me how the node at the </FONT><BR><FONT size=2>&gt; edge of the 
  RSVP</FONT> <BR><FONT size=2>&gt; or DiffServe domain can get such an idea as 
  a BB that governs the</FONT> <BR><FONT size=2>&gt; neighboring domain. On the 
  other hand the framework advocated </FONT><BR><FONT size=2>&gt; by 
  Georgios</FONT> <BR><FONT size=2>&gt; somewhat implies the use of the 
  hop-by-hop QoS technology </FONT><BR><FONT size=2>&gt; (and probably 
  for</FONT> <BR><FONT size=2>&gt; this reason is opposed by some people 
  including myself) that relies on</FONT> <BR><FONT size=2>&gt; signaling and 
  data path being the same.</FONT> <BR><FONT size=2>&gt; The way to resolve this 
  conflict in my mind is something </FONT><BR><FONT size=2>&gt; along the 
  following</FONT> <BR><FONT size=2>&gt; lines:</FONT> <BR><FONT size=2>&gt; 1. 
  The general NSIS signaling being used between the host and </FONT><BR><FONT 
  size=2>&gt; the edge and</FONT> <BR><FONT size=2>&gt; between the edges of the 
  neighboring domains (based on different QoS</FONT> <BR><FONT size=2>&gt; 
  technology) should follow the same path as data (or lay out </FONT><BR><FONT 
  size=2>&gt; the path for the</FONT> <BR><FONT size=2>&gt; data if you 
  wish).</FONT> <BR><FONT size=2>&gt; 2. It is up to the edge nodes that 
  understand used within domain QoS</FONT> <BR><FONT size=2>&gt; technology to 
  communicate to the BB or controller and </FONT><BR><FONT size=2>&gt; translate 
  NSIS generic</FONT> <BR><FONT size=2>&gt; signaling into something specific 
  for this domain. Obviously </FONT><BR><FONT size=2>&gt; the generic</FONT> 
  <BR><FONT size=2>&gt; NSIS signaling has to be recreated at the domain egress 
  edge.</FONT> <BR><FONT size=2>&gt; 3. In this scenario the host can be enabled 
  with the particular QoS</FONT> <BR><FONT size=2>&gt; technology and use 
  specific signaling for communication with the first</FONT> <BR><FONT 
  size=2>&gt; domain or can use generic NSIS signaling.</FONT> <BR><FONT 
  size=2>&gt; 4. The communication between neighboring domains using the same 
  QoS</FONT> <BR><FONT size=2>&gt; technology can be done in the specific for 
  the technology </FONT><BR><FONT size=2>&gt; fashion though</FONT> <BR><FONT 
  size=2>&gt; translation to NSIS and back will be always available if for 
  </FONT><BR><FONT size=2>&gt; whatever reason</FONT> <BR><FONT size=2>&gt; 
  those domains prefer it.</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT 
  size=2>&gt; In other words I am suggesting the following global analogy: 
  </FONT><BR><FONT size=2>&gt; If you view the domain with a QoS technology as a 
  virtual </FONT><BR><FONT size=2>&gt; router than NSIS</FONT> <BR><FONT 
  size=2>&gt; signaling used between those routers follows the same path as 
  </FONT><BR><FONT size=2>&gt; data. What</FONT> <BR><FONT size=2>&gt; happens 
  within the router is not a NSIS business.</FONT> <BR><FONT size=2>&gt; 
  </FONT><BR><FONT size=2>&gt; Ilya Freytsis</FONT> <BR><FONT size=2>&gt; 
  </FONT><BR><FONT size=2>&gt; Date: Tue, 29 Jan 2002 11:36:05 +0100</FONT> 
  <BR><FONT size=2>&gt; From: Marcus Brunner &lt;brunner@ccrle.nec.de&gt;</FONT> 
  <BR><FONT size=2>&gt; Reply-To: brunner@ccrle.nec.de</FONT> <BR><FONT 
  size=2>&gt; To: "Georgios Karagiannis (ELN)" </FONT><BR><FONT size=2>&gt; 
  &lt;Georgios.Karagiannis@eln.ericsson.se&gt;</FONT> <BR><FONT size=2>&gt; Cc: 
  nsis@ietf.org</FONT> <BR><FONT size=2>&gt; n.se&gt;</FONT> <BR><FONT 
  size=2>&gt; Subject: [NSIS] RE: Independence of signalling and data path 
  </FONT><BR><FONT size=2>&gt; (was RE: [NSIS]</FONT> <BR><FONT size=2>&gt; 
  Two&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; kindsof&nbsp; requirements)</FONT> 
  <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; Georgios,</FONT> <BR><FONT 
  size=2>&gt; </FONT><BR><FONT size=2>&gt; see inline</FONT> <BR><FONT 
  size=2>&gt; </FONT><BR><FONT size=2>&gt; --On Monday, January 28, 2002 2:45 PM 
  +0100 "Georgios </FONT><BR><FONT size=2>&gt; Karagiannis (ELN)" 
  </FONT><BR><FONT size=2>&gt; &lt;Georgios.Karagiannis@eln.ericsson.se&gt; 
  wrote:</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; &gt; Hi 
  Marcus</FONT> <BR><FONT size=2>&gt; &gt;</FONT> <BR><FONT size=2>&gt; 
  &gt;</FONT> <BR><FONT size=2>&gt; &gt; [MB]&gt;&gt; So, I think you much in 
  line with that req. The protocol</FONT> <BR><FONT size=2>&gt; &gt; 
  [MB]&gt;&gt; from host to BB does not depend on the data path</FONT> <BR><FONT 
  size=2>&gt; &gt; [MB}&gt;&gt; completly. What the constrain for the</FONT> 
  <BR><FONT size=2>&gt; &gt; [MB]&gt;&gt; communication are is a different 
  question.</FONT> <BR><FONT size=2>&gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; 
  I will repeat what was already said in my previous e-mail:</FONT> <BR><FONT 
  size=2>&gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; This is only true when the 
  following CONSIDEARTIONS are</FONT> <BR><FONT size=2>&gt; &gt; 
  fulfilled:</FONT> <BR><FONT size=2>&gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; 
  * BB's or QoS controllers are used;</FONT> <BR><FONT size=2>&gt; 
  </FONT><BR><FONT size=2>&gt; -&gt; QoS controllers are no BBs in our 
  understanding, the hop by hop </FONT><BR><FONT size=2>&gt; signalling is a 
  special case, where each hop has a QoS </FONT><BR><FONT size=2>&gt; controller 
  and QoS </FONT><BR><FONT size=2>&gt; initiator functionality runing.</FONT> 
  <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; &gt; * the end-host should 
  know the address of the first hop </FONT><BR><FONT size=2>&gt; Bandwidth 
  Broker;</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; An end-host 
  needs to know quite a bit of servers/nodes </FONT><BR><FONT size=2>&gt; 
  anyway. I even think </FONT><BR><FONT size=2>&gt; there are solutions (e.g. 
  AAA servers), where the first hop router is </FONT><BR><FONT size=2>&gt; 
  forwarding the signalling messages to the right place.</FONT> <BR><FONT 
  size=2>&gt; </FONT><BR><FONT size=2>&gt; &gt; * the BBs should be aware (know) 
  the addresses of neighboring BBs;</FONT> <BR><FONT size=2>&gt; 
  </FONT><BR><FONT size=2>&gt; Sure, you need interdoamin routing anyway.</FONT> 
  <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; &gt; * BB's or QoS 
  controllers should be able to relate</FONT> <BR><FONT size=2>&gt; 
  &gt;&nbsp;&nbsp;&nbsp; the QoS signaling to the data path;</FONT> <BR><FONT 
  size=2>&gt; &gt;</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; yes 
  true, I think this is the core functionality of a </FONT><BR><FONT size=2>&gt; 
  signalling protocol. </FONT><BR><FONT size=2>&gt; Only depends on the 
  information available in the signaling message.</FONT> <BR><FONT size=2>&gt; 
  </FONT><BR><FONT size=2>&gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt;&nbsp; In 
  GENERAL the above CONSIDERATIONS are very difficult to</FONT> <BR><FONT 
  size=2>&gt; &gt;&nbsp; fulfill. Please note that we need a NSIS protocol that 
  can</FONT> <BR><FONT size=2>&gt; &gt;&nbsp; be applied for GENERAL cases. Of 
  course YOUR</FONT> <BR><FONT size=2>&gt; &gt;&nbsp; SCENARIO, but OTHER TYPES 
  as well will be INCLUDED.</FONT> <BR><FONT size=2>&gt; &gt;</FONT> <BR><FONT 
  size=2>&gt; </FONT><BR><FONT size=2>&gt; IMO, with the QoS initator and QoS 
  controller framework we </FONT><BR><FONT size=2>&gt; excaclty target 
  </FONT><BR><FONT size=2>&gt; a more general case then the hop-by-hop 
  signalling.</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; &gt; 
  Thus, in GENERAL the path followed by signaling</FONT> <BR><FONT size=2>&gt; 
  &gt; messages and the path followed by user data packets (associated</FONT> 
  <BR><FONT size=2>&gt; &gt; to these signaling messages) MUST BE THE 
  SAME!!</FONT> <BR><FONT size=2>&gt; &gt;</FONT> <BR><FONT size=2>&gt; 
  </FONT><BR><FONT size=2>&gt; No, I do not agree.</FONT> <BR><FONT size=2>&gt; 
  </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; &gt;</FONT> 
  <BR><FONT size=2>&gt; &gt; Solution on how signaling messages and user 
  data</FONT> <BR><FONT size=2>&gt; &gt; packets can follow the same 
  path:</FONT> <BR><FONT size=2>&gt; &gt; The signaling messages will</FONT> 
  <BR><FONT size=2>&gt; &gt; follow the same path as the user data packets when 
  for example,</FONT> <BR><FONT size=2>&gt; &gt; the IP destination address of 
  the signaling messages is the same</FONT> <BR><FONT size=2>&gt; &gt; as the IP 
  destination address of the user data packets.</FONT> <BR><FONT size=2>&gt; 
  </FONT><BR><FONT size=2>&gt; Not necessarly (but normally packet with the same 
  destination </FONT><BR><FONT size=2>&gt; likely take </FONT><BR><FONT 
  size=2>&gt; the same path)</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT 
  size=2>&gt; &gt; Typical IP routing protocols will route both signaling 
  messages</FONT> <BR><FONT size=2>&gt; &gt; and user data packets that have the 
  same IP destination </FONT><BR><FONT size=2>&gt; address through</FONT> 
  <BR><FONT size=2>&gt; &gt; the same path. RSVPv1 uses something similar (on 
  the PATH messages</FONT> <BR><FONT size=2>&gt; &gt; and user data packets 
  having the same flow ID);</FONT> <BR><FONT size=2>&gt; &gt;</FONT> <BR><FONT 
  size=2>&gt; &gt; [MB]&gt;&gt; And whether, the</FONT> <BR><FONT size=2>&gt; 
  &gt; [MB]&gt;&gt; protocol work</FONT> <BR><FONT size=2>&gt; &gt; [MB]&gt;&gt; 
  between ehost, eedge, ehop, all of them can be controllers</FONT> <BR><FONT 
  size=2>&gt; &gt; [MB]&gt;&gt; and initiators</FONT> <BR><FONT size=2>&gt; &gt; 
  [MB] on the other side. So they do not require data and signalling</FONT> 
  <BR><FONT size=2>&gt; &gt; [MB] on the same path.</FONT> <BR><FONT size=2>&gt; 
  &gt;</FONT> <BR><FONT size=2>&gt; &gt; What do you mean, would you like to 
  have a NSIS protocol version</FONT> <BR><FONT size=2>&gt; &gt; that starts at 
  one hop router and terminates at the next </FONT><BR><FONT size=2>&gt; first 
  hop router.</FONT> <BR><FONT size=2>&gt; &gt; This protocol will be very slow, 
  very complex, and in my opinion</FONT> <BR><FONT size=2>&gt; &gt; not 
  useful!</FONT> <BR><FONT size=2>&gt; &gt;</FONT> <BR><FONT size=2>&gt; 
  </FONT><BR><FONT size=2>&gt; You have to be more specific on slow and 
  complex.</FONT> <BR><FONT size=2>&gt; If you mean with slow the signalling 
  delay (I think you are </FONT><BR><FONT size=2>&gt; better of not 
  </FONT><BR><FONT size=2>&gt; performing some actions in each hop)</FONT> 
  <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; The complextity in terms 
  CPU heavily depends on the </FONT><BR><FONT size=2>&gt; complexity of the 
  state </FONT><BR><FONT size=2>&gt; machine, which defionitly not defined yet. 
  But you are </FONT><BR><FONT size=2>&gt; definitly right, </FONT><BR><FONT 
  size=2>&gt; that it needs to be simple.</FONT> <BR><FONT size=2>&gt; 
  </FONT><BR><FONT size=2>&gt; Marcus</FONT> <BR><FONT size=2>&gt; 
  </FONT><BR><FONT size=2>&gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; Best 
  regards,</FONT> <BR><FONT size=2>&gt; &gt; Georgios</FONT> <BR><FONT 
  size=2>&gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt;</FONT> <BR><FONT 
  size=2>&gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt;</FONT> <BR><FONT 
  size=2>&gt; </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; 
  _______________________________________________</FONT> <BR><FONT size=2>&gt; 
  nsis mailing list</FONT> <BR><FONT size=2>&gt; nsis@ietf.org</FONT> <BR><FONT 
  size=2>&gt; <A target=_blank 
  href="https://www1.ietf.org/mailman/listinfo/nsis">https://www1.ietf.org/mailman/listinfo/nsis</A></FONT> 
  <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; 
  _______________________________________________</FONT> <BR><FONT size=2>&gt; 
  nsis mailing list</FONT> <BR><FONT size=2>&gt; nsis@ietf.org</FONT> <BR><FONT 
  size=2>&gt; <A target=_blank 
  href="https://www1.ietf.org/mailman/listinfo/nsis">https://www1.ietf.org/mailman/listinfo/nsis</A></FONT> 
  <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; 
  _______________________________________________</FONT> <BR><FONT size=2>&gt; 
  nsis mailing list</FONT> <BR><FONT size=2>&gt; nsis@ietf.org</FONT> <BR><FONT 
  size=2>&gt; <A target=_blank 
  href="https://www1.ietf.org/mailman/listinfo/nsis">https://www1.ietf.org/mailman/listinfo/nsis</A></FONT> 
  <BR><FONT size=2>&gt; </FONT></P></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C1AA77.8E127910--

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



From daemon@optimus.ietf.org  Thu Jan 31 12:14: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 MAA04145
	for <nsis-archive@odin.ietf.org>; Thu, 31 Jan 2002 12:14:48 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id MAA07298
	for nsis-archive@odin.ietf.org; Thu, 31 Jan 2002 12:14: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 MAA06315;
	Thu, 31 Jan 2002 12:04: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 MAA06246
	for <nsis@optimus.ietf.org>; Thu, 31 Jan 2002 12:04:23 -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 MAA03527
	for <nsis@ietf.org>; Thu, 31 Jan 2002 12:04:18 -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 g0VH3o514659;
	Thu, 31 Jan 2002 12:03:50 -0500 (EST)
Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7])
	by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g0VH3mb22792;
	Thu, 31 Jan 2002 12:03:48 -0500 (EST)
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19)
	id <D8QAVXKR>; Thu, 31 Jan 2002 12:03:47 -0500
Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA47DD@zcard031.ca.nortel.com>
From: "Gary Kenward"<gkenward@nortelnetworks.com>
To: "'dick.rr.knight@bt.com'" <dick.rr.knight@bt.com>,
        Georgios.Karagiannis@eln.ericsson.se, ifreytsis@cetacean.com,
        brunner@ccrle.nec.de
Cc: nsis@ietf.org
Subject: RE: [NSIS] RE: Independence of signalling and data path (host-edg
	 e vs edge-edge & b/w at final hop)
Date: Thu, 31 Jan 2002 12:03:46 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C1AA79.3EFEB850"
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_01C1AA79.3EFEB850
Content-Type: text/plain;
	charset="iso-8859-1"

Dick:
 
   Wireless is always (over) sensitive to bandwidth consumption over the
air. The issue I was raising was whether
this consideration should be explicitly be incorporated in the NSIS protocol
design, or whether normal design principles
of protocol efficiency for the internet should be used under the assumption
that additional bandwidth efficiency/overhead
reduction for wireless links be effected through packet compression.
 
  The first option with definitely result in the creation of two protocols,
with the obvious artifact that considerations of 
wireless link layer issues is one of the main distinctions between the two.
The second approach fits more into the IETF
model of link independence and end-to-end, but with the downside that an
additional compression protocol may be required 
for wireless operation.
 
Gary

-----Original Message-----
From: dick.rr.knight@bt.com [mailto:dick.rr.knight@bt.com]
Sent: January 31, 2002 11:52
To: Kenward, Gary [WDLN2:AN10:EXCH]; dick.rr.knight@bt.com;
Georgios.Karagiannis@eln.ericsson.se; ifreytsis@Cetacean.com;
brunner@ccrle.nec.de
Cc: nsis@ietf.org
Subject: RE: [NSIS] RE: Independence of signalling and data path (host-edg e
vs edge-edge & b/w at final hop)


I am sort of split on the differences and similarities between host-edge and
edge-edge (which don't quite equate to UNI and NNI in telephony).
 
A protocol that highlights the differences will not be popular in the IETF,
where the end-to-end model stills reigns and is seen as being something that
should still be supported. However, some of the security aspects of spoofing
to steal others bandwidth is a worry.
 
I was not quite sure what you meant by "given the 
activities going on in signalling compression, bandwidth efficiency across
the 
host to network link should not be overly emphasized." I thought that there
was a need for efficiency in the 3G radio world, and other scenarios where
"final hop" bandwidth is severely limited.
 
Dick 

-----Original Message-----
From: Gary Kenward [mailto:gkenward@nortelnetworks.com]
Sent: 31 January 2002 16:10
To: 'dick.rr.knight@bt.com'; Georgios.Karagiannis@eln.ericsson.se;
ifreytsis@Cetacean.com; brunner@ccrle.nec.de
Cc: nsis@ietf.org
Subject: RE: [NSIS] RE: Independence of signalling and data path 



Dick: 

  Sounds reasonable. The only small addition, which is probably obvious, is 
to be careful about the need to distinguish between host-to-edge and
edge-to-edge 
interactions. At one level of abstraction, a client-server model is
applicable, 
where the client is either a host or a network/bandwidth broker. Any
variations in 
the solution that distinguishes host-to-edge from edge-to-edge thus needs to
be 
justified against the added complexity. And, just to pursue that thought,
given the 
activities going on in signalling compression, bandwidth efficiency across
the 
host to network link should not be overly emphasized. 

 I realize that this abstract will probably break down when we get to the
point 
of looking at the specifics of each case. However, I am wondering if it is
possible 
to construct the requirements for the more general client-server model? This
could 
cut the number of requirements nearly in half, and the associated debate by
an 
order of magnitude ;^). 

 Just a thought. 

Gary 

> -----Original Message----- 
> From: dick.rr.knight@bt.com [ mailto:dick.rr.knight@bt.com
<mailto:dick.rr.knight@bt.com> ] 
> Sent: January 31, 2002 07:17 
> To: Georgios.Karagiannis@eln.ericsson.se; ifreytsis@Cetacean.com; 
> brunner@ccrle.nec.de 
> Cc: nsis@ietf.org 
> Subject: RE: [NSIS] RE: Independence of signalling and data path 
> 
> 
> 
> I think that we are all moving to is a generic NSIS protocol that is 
> applicable to the Host-Edge and the Edge-Edge interfaces. The 
> use of it 
> within a domain (hop-hop) must always be the decision of the domain 
> operator. This is because: 
> 1. An operator of a domain will make their own decisions 
> regarding protocol 
> selection 
> 2. domain operators need a generalised QoS protocol for interconnect 
> 3. Some approaches for QoS (at least the bandwidth part) do 
> not require any 
> signalling (e.g. overprovision). 
> 
> In case 3, it seems to me this is a specialised case of 
> Edge-Edge. The two 
> edges in this case are within a single domain or technology 
> type, and the 
> NSIS signalling protocol must traverse it in order to reach 
> the next domain 
> or QoS technology type. 
> 
> Dick 
> 
> 
> -----Original Message----- 
> From: Georgios Karagiannis (ELN) 
> [ mailto:Georgios.Karagiannis@eln.ericsson.se
<mailto:Georgios.Karagiannis@eln.ericsson.se> ] 
> Sent: 31 January 2002 09:03 
> To: 'Freytsis, Ilya'; 'brunner@ccrle.nec.de' 
> Cc: 'nsis@ietf.org' 
> Subject: RE: [NSIS] RE: Independence of signalling and data path 
> 
> 
> Hi Ilya 
> 
> Regarding your following statement: 
> 
> [IF]>> In other words I am suggesting the following global analogy: 
> [IF]>> If you view the domain with a QoS technology as a 
> [IF]>> virtual router than NSIS 
> [IF]>> signaling used between those routers follows the same 
> [IF]>> path as data. What 
> [IF]>> happens within the router is not a NSIS business. 
> 
> I partially agree! 
> 
> I believe that the NSIS protocol when needed, 
> should be capable of operating within a QoS domain 
> (that is a QoS domain administrated by a provider). 
> However, if the QoS functionality is provided by a Bandwidth Broker 
> or the domain is overprovisioned then the signaling path and 
> user data path 
> can be independent (not the same). Of course this can be 
> chosen by the 
> provider! 
> 
> But when a provider would want to use the NSIS protocol within the 
> domain for QoS support, then it should be possible to set (activate) 
> the NSIS protocol such that the signaling path and user data 
> path use the 
> same path. 
> 
> I agree with the rest of your statement! 
> 
> Best Regards, 
> Georgios 
> 
> 
> -----Original Message----- 
> From: Freytsis, Ilya [ mailto:ifreytsis@Cetacean.com
<mailto:ifreytsis@Cetacean.com> ] 
> Sent: dinsdag 29 januari 2002 18:45 
> To: 'brunner@ccrle.nec.de' 
> Cc: 'nsis@ietf.org' 
> Subject: [NSIS] RE: Independence of signalling and data path 
> 
> 
> Marcus, 
> 
> Let me add my 2cents into this discussion: 
> 
> It looks to me that this discussion got very heated because 
> it is at the 
> very border between general QoS signaling and specific QoS 
> technology in use 
> (by the domain). The fact that you mentioned such terms as 
> "Controller" and 
> "BB" indicates to me that you have a particular technology in 
> mind that 
> based on this kind of entities. Tell me how the node at the 
> edge of the RSVP 
> or DiffServe domain can get such an idea as a BB that governs the 
> neighboring domain. On the other hand the framework advocated 
> by Georgios 
> somewhat implies the use of the hop-by-hop QoS technology 
> (and probably for 
> this reason is opposed by some people including myself) that relies on 
> signaling and data path being the same. 
> The way to resolve this conflict in my mind is something 
> along the following 
> lines: 
> 1. The general NSIS signaling being used between the host and 
> the edge and 
> between the edges of the neighboring domains (based on different QoS 
> technology) should follow the same path as data (or lay out 
> the path for the 
> data if you wish). 
> 2. It is up to the edge nodes that understand used within domain QoS 
> technology to communicate to the BB or controller and 
> translate NSIS generic 
> signaling into something specific for this domain. Obviously 
> the generic 
> NSIS signaling has to be recreated at the domain egress edge. 
> 3. In this scenario the host can be enabled with the particular QoS 
> technology and use specific signaling for communication with the first 
> domain or can use generic NSIS signaling. 
> 4. The communication between neighboring domains using the same QoS 
> technology can be done in the specific for the technology 
> fashion though 
> translation to NSIS and back will be always available if for 
> whatever reason 
> those domains prefer it. 
> 
> In other words I am suggesting the following global analogy: 
> If you view the domain with a QoS technology as a virtual 
> router than NSIS 
> signaling used between those routers follows the same path as 
> data. What 
> happens within the router is not a NSIS business. 
> 
> Ilya Freytsis 
> 
> Date: Tue, 29 Jan 2002 11:36:05 +0100 
> From: Marcus Brunner <brunner@ccrle.nec.de> 
> Reply-To: brunner@ccrle.nec.de 
> To: "Georgios Karagiannis (ELN)" 
> <Georgios.Karagiannis@eln.ericsson.se> 
> Cc: nsis@ietf.org 
> n.se> 
> Subject: [NSIS] RE: Independence of signalling and data path 
> (was RE: [NSIS] 
> Two                   kindsof  requirements) 
> 
> Georgios, 
> 
> see inline 
> 
> --On Monday, January 28, 2002 2:45 PM +0100 "Georgios 
> Karagiannis (ELN)" 
> <Georgios.Karagiannis@eln.ericsson.se> wrote: 
> 
> > Hi Marcus 
> > 
> > 
> > [MB]>> So, I think you much in line with that req. The protocol 
> > [MB]>> from host to BB does not depend on the data path 
> > [MB}>> completly. What the constrain for the 
> > [MB]>> communication are is a different question. 
> > 
> > I will repeat what was already said in my previous e-mail: 
> > 
> > This is only true when the following CONSIDEARTIONS are 
> > fulfilled: 
> > 
> > * BB's or QoS controllers are used; 
> 
> -> QoS controllers are no BBs in our understanding, the hop by hop 
> signalling is a special case, where each hop has a QoS 
> controller and QoS 
> initiator functionality runing. 
> 
> > * the end-host should know the address of the first hop 
> Bandwidth Broker; 
> 
> An end-host needs to know quite a bit of servers/nodes 
> anyway. I even think 
> there are solutions (e.g. AAA servers), where the first hop router is 
> forwarding the signalling messages to the right place. 
> 
> > * the BBs should be aware (know) the addresses of neighboring BBs; 
> 
> Sure, you need interdoamin routing anyway. 
> 
> > * BB's or QoS controllers should be able to relate 
> >    the QoS signaling to the data path; 
> > 
> 
> yes true, I think this is the core functionality of a 
> signalling protocol. 
> Only depends on the information available in the signaling message. 
> 
> > 
> >  In GENERAL the above CONSIDERATIONS are very difficult to 
> >  fulfill. Please note that we need a NSIS protocol that can 
> >  be applied for GENERAL cases. Of course YOUR 
> >  SCENARIO, but OTHER TYPES as well will be INCLUDED. 
> > 
> 
> IMO, with the QoS initator and QoS controller framework we 
> excaclty target 
> a more general case then the hop-by-hop signalling. 
> 
> > Thus, in GENERAL the path followed by signaling 
> > messages and the path followed by user data packets (associated 
> > to these signaling messages) MUST BE THE SAME!! 
> > 
> 
> No, I do not agree. 
> 
> 
> > 
> > Solution on how signaling messages and user data 
> > packets can follow the same path: 
> > The signaling messages will 
> > follow the same path as the user data packets when for example, 
> > the IP destination address of the signaling messages is the same 
> > as the IP destination address of the user data packets. 
> 
> Not necessarly (but normally packet with the same destination 
> likely take 
> the same path) 
> 
> > Typical IP routing protocols will route both signaling messages 
> > and user data packets that have the same IP destination 
> address through 
> > the same path. RSVPv1 uses something similar (on the PATH messages 
> > and user data packets having the same flow ID); 
> > 
> > [MB]>> And whether, the 
> > [MB]>> protocol work 
> > [MB]>> between ehost, eedge, ehop, all of them can be controllers 
> > [MB]>> and initiators 
> > [MB] on the other side. So they do not require data and signalling 
> > [MB] on the same path. 
> > 
> > What do you mean, would you like to have a NSIS protocol version 
> > that starts at one hop router and terminates at the next 
> first hop router. 
> > This protocol will be very slow, very complex, and in my opinion 
> > not useful! 
> > 
> 
> You have to be more specific on slow and complex. 
> If you mean with slow the signalling delay (I think you are 
> better of not 
> performing some actions in each hop) 
> 
> The complextity in terms CPU heavily depends on the 
> complexity of the state 
> machine, which defionitly not defined yet. But you are 
> definitly right, 
> that it needs to be simple. 
> 
> Marcus 
> 
> > 
> > Best regards, 
> > Georgios 
> > 
> > 
> > 
> > 
> 
> 
> _______________________________________________ 
> nsis mailing list 
> nsis@ietf.org 
> https://www1.ietf.org/mailman/listinfo/nsis
<https://www1.ietf.org/mailman/listinfo/nsis>  
> 
> _______________________________________________ 
> nsis mailing list 
> nsis@ietf.org 
> https://www1.ietf.org/mailman/listinfo/nsis
<https://www1.ietf.org/mailman/listinfo/nsis>  
> 
> _______________________________________________ 
> nsis mailing list 
> nsis@ietf.org 
> https://www1.ietf.org/mailman/listinfo/nsis
<https://www1.ietf.org/mailman/listinfo/nsis>  
> 


------_=_NextPart_001_01C1AA79.3EFEB850
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">
<TITLE>RE: [NSIS] RE: Independence of signalling and data path</TITLE>

<META content="MSHTML 5.00.3315.2869" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT color=#0000ff face="Comic Sans MS"><SPAN 
class=165490317-31012002>Dick:</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face="Comic Sans MS"><SPAN 
class=165490317-31012002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face="Comic Sans MS"><SPAN 
class=165490317-31012002>&nbsp;&nbsp; Wireless is always (over) sensitive to 
bandwidth consumption over the air. The issue I was raising was 
whether</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face="Comic Sans MS"><SPAN 
class=165490317-31012002>this consideration should be explicitly be incorporated 
in the NSIS protocol design, or whether normal design 
principles</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face="Comic Sans MS"><SPAN class=165490317-31012002>of 
protocol efficiency for the internet should be used under the assumption that 
additional&nbsp;bandwidth efficiency/overhead</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face="Comic Sans MS"><SPAN 
class=165490317-31012002>reduction for wireless links be effected through packet 
compression.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face="Comic Sans MS"><SPAN 
class=165490317-31012002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face="Comic Sans MS"><SPAN 
class=165490317-31012002>&nbsp; The first option with definitely result in the 
creation of two protocols, with the obvious artifact that considerations of 
</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face="Comic Sans MS"><SPAN 
class=165490317-31012002>wireless link layer issues is one of the main 
distinctions between the two. The second approach fits more into the 
IETF</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face="Comic Sans MS"><SPAN 
class=165490317-31012002>model of link independence and end-to-end, but with the 
downside that an additional compression protocol may be required 
</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face="Comic Sans MS"><SPAN class=165490317-31012002>for 
wireless operation.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face="Comic Sans MS"><SPAN 
class=165490317-31012002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face="Comic Sans MS"><SPAN 
class=165490317-31012002>Gary</SPAN></FONT></DIV>
<BLOCKQUOTE dir=ltr 
style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">
  <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> dick.rr.knight@bt.com 
  [mailto:dick.rr.knight@bt.com]<BR><B>Sent:</B> January 31, 2002 
  11:52<BR><B>To:</B> Kenward, Gary [WDLN2:AN10:EXCH]; dick.rr.knight@bt.com; 
  Georgios.Karagiannis@eln.ericsson.se; ifreytsis@Cetacean.com; 
  brunner@ccrle.nec.de<BR><B>Cc:</B> nsis@ietf.org<BR><B>Subject:</B> RE: [NSIS] 
  RE: Independence of signalling and data path (host-edg e vs edge-edge &amp; 
  b/w at final hop)<BR><BR></DIV></FONT>
  <DIV><SPAN class=770184616-31012002><FONT color=#0000ff face=Arial size=2>I am 
  sort of split on the differences and similarities between host-edge and 
  edge-edge (which don't quite equate to UNI and NNI in 
  telephony).</FONT></SPAN></DIV>
  <DIV><SPAN class=770184616-31012002><FONT color=#0000ff face=Arial 
  size=2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=770184616-31012002><FONT color=#0000ff face=Arial size=2>A 
  protocol that highlights the differences will not be popular in the IETF, 
  where the end-to-end model stills reigns and is seen as being something that 
  should still be supported. However, some of the security aspects of spoofing 
  to steal others bandwidth is a worry.</FONT></SPAN></DIV>
  <DIV><SPAN class=770184616-31012002><FONT color=#0000ff face=Arial 
  size=2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=770184616-31012002><FONT color=#0000ff face=Arial size=2>I 
  was not quite sure what you meant by "<FONT color=#000080 
  face="Times New Roman">given the</FONT><FONT color=#000080><FONT 
  face="Times New Roman"><FONT size=3> <BR></FONT><FONT size=2>activities going 
  on in signalling compression, bandwidth efficiency across 
  the</FONT></FONT></FONT><FONT color=#000080><FONT face="Times New Roman"><FONT 
  size=3> <BR></FONT><FONT size=2>host to network link should not be overly 
  emphasized.<FONT color=#0000ff face=Arial>"&nbsp;I thought that&nbsp;there was 
  a need for efficiency in the 3G radio world, and other scenarios where 
  "final&nbsp;hop" bandwidth is severely 
  limited.</FONT></FONT></FONT></FONT></FONT></SPAN></DIV>
  <DIV><SPAN class=770184616-31012002></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=770184616-31012002><FONT color=#0000ff face=Arial 
  size=2>Dick</FONT>&nbsp;</SPAN></DIV>
  <BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
    <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
    size=2>-----Original Message-----<BR><B>From:</B> Gary Kenward 
    [mailto:gkenward@nortelnetworks.com]<BR><B>Sent:</B> 31 January 2002 
    16:10<BR><B>To:</B> 'dick.rr.knight@bt.com'; 
    Georgios.Karagiannis@eln.ericsson.se; ifreytsis@Cetacean.com; 
    brunner@ccrle.nec.de<BR><B>Cc:</B> nsis@ietf.org<BR><B>Subject:</B> RE: 
    [NSIS] RE: Independence of signalling and data path <BR><BR></FONT></DIV>
    <P><FONT size=2>Dick:</FONT> </P>
    <P><FONT size=2>&nbsp; Sounds reasonable. The only small addition, which is 
    probably obvious, is</FONT> <BR><FONT size=2>to be careful about the need to 
    distinguish between host-to-edge and edge-to-edge</FONT> <BR><FONT 
    size=2>interactions. At one level of abstraction, a client-server model is 
    applicable,</FONT> <BR><FONT size=2>where the client is either a host or a 
    network/bandwidth broker. Any variations in</FONT> <BR><FONT size=2>the 
    solution that distinguishes host-to-edge from edge-to-edge thus needs to 
    be</FONT> <BR><FONT size=2>justified against the added complexity. And, just 
    to pursue that thought, given the</FONT> <BR><FONT size=2>activities going 
    on in signalling compression, bandwidth efficiency across the</FONT> 
    <BR><FONT size=2>host to network link should not be overly 
    emphasized.</FONT> </P>
    <P><FONT size=2>&nbsp;I realize that this abstract will probably break down 
    when we get to the point</FONT> <BR><FONT size=2>of looking at the specifics 
    of each case. However, I am wondering if it is possible</FONT> <BR><FONT 
    size=2>to construct the requirements for the more general client-server 
    model? This could</FONT> <BR><FONT size=2>cut the number of requirements 
    nearly in half, and the associated debate by an</FONT> <BR><FONT 
    size=2>order of magnitude ;^).</FONT> </P>
    <P><FONT size=2>&nbsp;Just a thought.</FONT> </P>
    <P><FONT size=2>Gary</FONT> </P>
    <P><FONT size=2>&gt; -----Original Message-----</FONT> <BR><FONT size=2>&gt; 
    From: dick.rr.knight@bt.com [<A 
    href="mailto:dick.rr.knight@bt.com">mailto:dick.rr.knight@bt.com</A>]</FONT> 
    <BR><FONT size=2>&gt; Sent: January 31, 2002 07:17</FONT> <BR><FONT 
    size=2>&gt; To: Georgios.Karagiannis@eln.ericsson.se; 
    ifreytsis@Cetacean.com;</FONT> <BR><FONT size=2>&gt; 
    brunner@ccrle.nec.de</FONT> <BR><FONT size=2>&gt; Cc: nsis@ietf.org</FONT> 
    <BR><FONT size=2>&gt; Subject: RE: [NSIS] RE: Independence of signalling and 
    data path </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; 
    </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; I think that we 
    are all moving to is a generic NSIS protocol that is</FONT> <BR><FONT 
    size=2>&gt; applicable to the Host-Edge and the Edge-Edge interfaces. The 
    </FONT><BR><FONT size=2>&gt; use of it</FONT> <BR><FONT size=2>&gt; within a 
    domain (hop-hop) must always be the decision of the domain</FONT> <BR><FONT 
    size=2>&gt; operator. This is because:</FONT> <BR><FONT size=2>&gt; 1. An 
    operator of a domain will make their own decisions </FONT><BR><FONT 
    size=2>&gt; regarding protocol</FONT> <BR><FONT size=2>&gt; selection</FONT> 
    <BR><FONT size=2>&gt; 2. domain operators need a generalised QoS protocol 
    for interconnect</FONT> <BR><FONT size=2>&gt; 3. Some approaches for QoS (at 
    least the bandwidth part) do </FONT><BR><FONT size=2>&gt; not require 
    any</FONT> <BR><FONT size=2>&gt; signalling (e.g. overprovision).</FONT> 
    <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; In case 3, it seems to me 
    this is a specialised case of </FONT><BR><FONT size=2>&gt; Edge-Edge. The 
    two</FONT> <BR><FONT size=2>&gt; edges in this case are within a single 
    domain or technology </FONT><BR><FONT size=2>&gt; type, and the</FONT> 
    <BR><FONT size=2>&gt; NSIS signalling protocol must traverse it in order to 
    reach </FONT><BR><FONT size=2>&gt; the next domain</FONT> <BR><FONT 
    size=2>&gt; or QoS technology type.</FONT> <BR><FONT size=2>&gt; 
    </FONT><BR><FONT size=2>&gt; Dick</FONT> <BR><FONT size=2>&gt; 
    </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; -----Original 
    Message-----</FONT> <BR><FONT size=2>&gt; From: Georgios Karagiannis 
    (ELN)</FONT> <BR><FONT size=2>&gt; [<A 
    href="mailto:Georgios.Karagiannis@eln.ericsson.se">mailto:Georgios.Karagiannis@eln.ericsson.se</A>]</FONT> 
    <BR><FONT size=2>&gt; Sent: 31 January 2002 09:03</FONT> <BR><FONT 
    size=2>&gt; To: 'Freytsis, Ilya'; 'brunner@ccrle.nec.de'</FONT> <BR><FONT 
    size=2>&gt; Cc: 'nsis@ietf.org'</FONT> <BR><FONT size=2>&gt; Subject: RE: 
    [NSIS] RE: Independence of signalling and data path </FONT><BR><FONT 
    size=2>&gt; </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; Hi 
    Ilya</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; Regarding 
    your following statement:</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT 
    size=2>&gt; [IF]&gt;&gt; In other words I am suggesting the following global 
    analogy: </FONT><BR><FONT size=2>&gt; [IF]&gt;&gt; If you view the domain 
    with a QoS technology as a </FONT><BR><FONT size=2>&gt; [IF]&gt;&gt; virtual 
    router than NSIS</FONT> <BR><FONT size=2>&gt; [IF]&gt;&gt; signaling used 
    between those routers follows the same </FONT><BR><FONT size=2>&gt; 
    [IF]&gt;&gt; path as data. What</FONT> <BR><FONT size=2>&gt; [IF]&gt;&gt; 
    happens within the router is not a NSIS business.</FONT> <BR><FONT 
    size=2>&gt; </FONT><BR><FONT size=2>&gt; I partially agree! </FONT><BR><FONT 
    size=2>&gt; </FONT><BR><FONT size=2>&gt; I believe that the NSIS protocol 
    when needed,</FONT> <BR><FONT size=2>&gt; should be capable of operating 
    within a QoS domain</FONT> <BR><FONT size=2>&gt; (that is a QoS domain 
    administrated by a provider).</FONT> <BR><FONT size=2>&gt; However, if the 
    QoS functionality is provided by a Bandwidth Broker</FONT> <BR><FONT 
    size=2>&gt; or the domain is overprovisioned then the signaling path and 
    </FONT><BR><FONT size=2>&gt; user data path</FONT> <BR><FONT size=2>&gt; can 
    be independent (not the same). Of course this can be </FONT><BR><FONT 
    size=2>&gt; chosen by the </FONT><BR><FONT size=2>&gt; provider!</FONT> 
    <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; But when a provider would 
    want to use the NSIS protocol within the </FONT><BR><FONT size=2>&gt; domain 
    for QoS support, then it should be possible to set (activate) 
    </FONT><BR><FONT size=2>&gt; the NSIS protocol such that the signaling path 
    and user data </FONT><BR><FONT size=2>&gt; path use the </FONT><BR><FONT 
    size=2>&gt; same path.</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT 
    size=2>&gt; I agree with the rest of your statement!</FONT> <BR><FONT 
    size=2>&gt; </FONT><BR><FONT size=2>&gt; Best Regards,</FONT> <BR><FONT 
    size=2>&gt; Georgios</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT 
    size=2>&gt; </FONT><BR><FONT size=2>&gt; -----Original Message-----</FONT> 
    <BR><FONT size=2>&gt; From: Freytsis, Ilya [<A 
    href="mailto:ifreytsis@Cetacean.com">mailto:ifreytsis@Cetacean.com</A>]</FONT> 
    <BR><FONT size=2>&gt; Sent: dinsdag 29 januari 2002 18:45</FONT> <BR><FONT 
    size=2>&gt; To: 'brunner@ccrle.nec.de'</FONT> <BR><FONT size=2>&gt; Cc: 
    'nsis@ietf.org'</FONT> <BR><FONT size=2>&gt; Subject: [NSIS] RE: 
    Independence of signalling and data path </FONT><BR><FONT size=2>&gt; 
    </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; Marcus, 
    </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; Let me add my 
    2cents into this discussion:</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT 
    size=2>&gt; It looks to me that this discussion got very heated because 
    </FONT><BR><FONT size=2>&gt; it is at the</FONT> <BR><FONT size=2>&gt; very 
    border between general QoS signaling and specific QoS </FONT><BR><FONT 
    size=2>&gt; technology in use</FONT> <BR><FONT size=2>&gt; (by the domain). 
    The fact that you mentioned such terms as </FONT><BR><FONT size=2>&gt; 
    "Controller" and</FONT> <BR><FONT size=2>&gt; "BB" indicates to me that you 
    have a particular technology in </FONT><BR><FONT size=2>&gt; mind 
    that</FONT> <BR><FONT size=2>&gt; based on this kind of entities. Tell me 
    how the node at the </FONT><BR><FONT size=2>&gt; edge of the RSVP</FONT> 
    <BR><FONT size=2>&gt; or DiffServe domain can get such an idea as a BB that 
    governs the</FONT> <BR><FONT size=2>&gt; neighboring domain. On the other 
    hand the framework advocated </FONT><BR><FONT size=2>&gt; by Georgios</FONT> 
    <BR><FONT size=2>&gt; somewhat implies the use of the hop-by-hop QoS 
    technology </FONT><BR><FONT size=2>&gt; (and probably for</FONT> <BR><FONT 
    size=2>&gt; this reason is opposed by some people including myself) that 
    relies on</FONT> <BR><FONT size=2>&gt; signaling and data path being the 
    same.</FONT> <BR><FONT size=2>&gt; The way to resolve this conflict in my 
    mind is something </FONT><BR><FONT size=2>&gt; along the following</FONT> 
    <BR><FONT size=2>&gt; lines:</FONT> <BR><FONT size=2>&gt; 1. The general 
    NSIS signaling being used between the host and </FONT><BR><FONT size=2>&gt; 
    the edge and</FONT> <BR><FONT size=2>&gt; between the edges of the 
    neighboring domains (based on different QoS</FONT> <BR><FONT size=2>&gt; 
    technology) should follow the same path as data (or lay out </FONT><BR><FONT 
    size=2>&gt; the path for the</FONT> <BR><FONT size=2>&gt; data if you 
    wish).</FONT> <BR><FONT size=2>&gt; 2. It is up to the edge nodes that 
    understand used within domain QoS</FONT> <BR><FONT size=2>&gt; technology to 
    communicate to the BB or controller and </FONT><BR><FONT size=2>&gt; 
    translate NSIS generic</FONT> <BR><FONT size=2>&gt; signaling into something 
    specific for this domain. Obviously </FONT><BR><FONT size=2>&gt; the 
    generic</FONT> <BR><FONT size=2>&gt; NSIS signaling has to be recreated at 
    the domain egress edge.</FONT> <BR><FONT size=2>&gt; 3. In this scenario the 
    host can be enabled with the particular QoS</FONT> <BR><FONT size=2>&gt; 
    technology and use specific signaling for communication with the 
    first</FONT> <BR><FONT size=2>&gt; domain or can use generic NSIS 
    signaling.</FONT> <BR><FONT size=2>&gt; 4. The communication between 
    neighboring domains using the same QoS</FONT> <BR><FONT size=2>&gt; 
    technology can be done in the specific for the technology </FONT><BR><FONT 
    size=2>&gt; fashion though</FONT> <BR><FONT size=2>&gt; translation to NSIS 
    and back will be always available if for </FONT><BR><FONT size=2>&gt; 
    whatever reason</FONT> <BR><FONT size=2>&gt; those domains prefer it.</FONT> 
    <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; In other words I am 
    suggesting the following global analogy: </FONT><BR><FONT size=2>&gt; If you 
    view the domain with a QoS technology as a virtual </FONT><BR><FONT 
    size=2>&gt; router than NSIS</FONT> <BR><FONT size=2>&gt; signaling used 
    between those routers follows the same path as </FONT><BR><FONT size=2>&gt; 
    data. What</FONT> <BR><FONT size=2>&gt; happens within the router is not a 
    NSIS business.</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; 
    Ilya Freytsis</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; 
    Date: Tue, 29 Jan 2002 11:36:05 +0100</FONT> <BR><FONT size=2>&gt; From: 
    Marcus Brunner &lt;brunner@ccrle.nec.de&gt;</FONT> <BR><FONT size=2>&gt; 
    Reply-To: brunner@ccrle.nec.de</FONT> <BR><FONT size=2>&gt; To: "Georgios 
    Karagiannis (ELN)" </FONT><BR><FONT size=2>&gt; 
    &lt;Georgios.Karagiannis@eln.ericsson.se&gt;</FONT> <BR><FONT size=2>&gt; 
    Cc: nsis@ietf.org</FONT> <BR><FONT size=2>&gt; n.se&gt;</FONT> <BR><FONT 
    size=2>&gt; Subject: [NSIS] RE: Independence of signalling and data path 
    </FONT><BR><FONT size=2>&gt; (was RE: [NSIS]</FONT> <BR><FONT size=2>&gt; 
    Two&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; kindsof&nbsp; 
    requirements)</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; 
    Georgios,</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; see 
    inline</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; --On 
    Monday, January 28, 2002 2:45 PM +0100 "Georgios </FONT><BR><FONT 
    size=2>&gt; Karagiannis (ELN)" </FONT><BR><FONT size=2>&gt; 
    &lt;Georgios.Karagiannis@eln.ericsson.se&gt; wrote:</FONT> <BR><FONT 
    size=2>&gt; </FONT><BR><FONT size=2>&gt; &gt; Hi Marcus</FONT> <BR><FONT 
    size=2>&gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt;</FONT> <BR><FONT 
    size=2>&gt; &gt; [MB]&gt;&gt; So, I think you much in line with that req. 
    The protocol</FONT> <BR><FONT size=2>&gt; &gt; [MB]&gt;&gt; from host to BB 
    does not depend on the data path</FONT> <BR><FONT size=2>&gt; &gt; 
    [MB}&gt;&gt; completly. What the constrain for the</FONT> <BR><FONT 
    size=2>&gt; &gt; [MB]&gt;&gt; communication are is a different 
    question.</FONT> <BR><FONT size=2>&gt; &gt;</FONT> <BR><FONT size=2>&gt; 
    &gt; I will repeat what was already said in my previous e-mail:</FONT> 
    <BR><FONT size=2>&gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; This is only 
    true when the following CONSIDEARTIONS are</FONT> <BR><FONT size=2>&gt; &gt; 
    fulfilled:</FONT> <BR><FONT size=2>&gt; &gt;</FONT> <BR><FONT size=2>&gt; 
    &gt; * BB's or QoS controllers are used;</FONT> <BR><FONT size=2>&gt; 
    </FONT><BR><FONT size=2>&gt; -&gt; QoS controllers are no BBs in our 
    understanding, the hop by hop </FONT><BR><FONT size=2>&gt; signalling is a 
    special case, where each hop has a QoS </FONT><BR><FONT size=2>&gt; 
    controller and QoS </FONT><BR><FONT size=2>&gt; initiator functionality 
    runing.</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; &gt; * the 
    end-host should know the address of the first hop </FONT><BR><FONT 
    size=2>&gt; Bandwidth Broker;</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT 
    size=2>&gt; An end-host needs to know quite a bit of servers/nodes 
    </FONT><BR><FONT size=2>&gt; anyway. I even think </FONT><BR><FONT 
    size=2>&gt; there are solutions (e.g. AAA servers), where the first hop 
    router is </FONT><BR><FONT size=2>&gt; forwarding the signalling messages to 
    the right place.</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; 
    &gt; * the BBs should be aware (know) the addresses of neighboring 
    BBs;</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; Sure, you 
    need interdoamin routing anyway.</FONT> <BR><FONT size=2>&gt; 
    </FONT><BR><FONT size=2>&gt; &gt; * BB's or QoS controllers should be able 
    to relate</FONT> <BR><FONT size=2>&gt; &gt;&nbsp;&nbsp;&nbsp; the QoS 
    signaling to the data path;</FONT> <BR><FONT size=2>&gt; &gt;</FONT> 
    <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; yes true, I think this is 
    the core functionality of a </FONT><BR><FONT size=2>&gt; signalling 
    protocol. </FONT><BR><FONT size=2>&gt; Only depends on the information 
    available in the signaling message.</FONT> <BR><FONT size=2>&gt; 
    </FONT><BR><FONT size=2>&gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt;&nbsp; In 
    GENERAL the above CONSIDERATIONS are very difficult to</FONT> <BR><FONT 
    size=2>&gt; &gt;&nbsp; fulfill. Please note that we need a NSIS protocol 
    that can</FONT> <BR><FONT size=2>&gt; &gt;&nbsp; be applied for GENERAL 
    cases. Of course YOUR</FONT> <BR><FONT size=2>&gt; &gt;&nbsp; SCENARIO, but 
    OTHER TYPES as well will be INCLUDED.</FONT> <BR><FONT size=2>&gt; 
    &gt;</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; IMO, with the 
    QoS initator and QoS controller framework we </FONT><BR><FONT size=2>&gt; 
    excaclty target </FONT><BR><FONT size=2>&gt; a more general case then the 
    hop-by-hop signalling.</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT 
    size=2>&gt; &gt; Thus, in GENERAL the path followed by signaling</FONT> 
    <BR><FONT size=2>&gt; &gt; messages and the path followed by user data 
    packets (associated</FONT> <BR><FONT size=2>&gt; &gt; to these signaling 
    messages) MUST BE THE SAME!!</FONT> <BR><FONT size=2>&gt; &gt;</FONT> 
    <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; No, I do not 
    agree.</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; 
    </FONT><BR><FONT size=2>&gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; Solution 
    on how signaling messages and user data</FONT> <BR><FONT size=2>&gt; &gt; 
    packets can follow the same path:</FONT> <BR><FONT size=2>&gt; &gt; The 
    signaling messages will</FONT> <BR><FONT size=2>&gt; &gt; follow the same 
    path as the user data packets when for example,</FONT> <BR><FONT size=2>&gt; 
    &gt; the IP destination address of the signaling messages is the same</FONT> 
    <BR><FONT size=2>&gt; &gt; as the IP destination address of the user data 
    packets.</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; Not 
    necessarly (but normally packet with the same destination </FONT><BR><FONT 
    size=2>&gt; likely take </FONT><BR><FONT size=2>&gt; the same path)</FONT> 
    <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; &gt; Typical IP routing 
    protocols will route both signaling messages</FONT> <BR><FONT size=2>&gt; 
    &gt; and user data packets that have the same IP destination 
    </FONT><BR><FONT size=2>&gt; address through</FONT> <BR><FONT size=2>&gt; 
    &gt; the same path. RSVPv1 uses something similar (on the PATH 
    messages</FONT> <BR><FONT size=2>&gt; &gt; and user data packets having the 
    same flow ID);</FONT> <BR><FONT size=2>&gt; &gt;</FONT> <BR><FONT 
    size=2>&gt; &gt; [MB]&gt;&gt; And whether, the</FONT> <BR><FONT size=2>&gt; 
    &gt; [MB]&gt;&gt; protocol work</FONT> <BR><FONT size=2>&gt; &gt; 
    [MB]&gt;&gt; between ehost, eedge, ehop, all of them can be 
    controllers</FONT> <BR><FONT size=2>&gt; &gt; [MB]&gt;&gt; and 
    initiators</FONT> <BR><FONT size=2>&gt; &gt; [MB] on the other side. So they 
    do not require data and signalling</FONT> <BR><FONT size=2>&gt; &gt; [MB] on 
    the same path.</FONT> <BR><FONT size=2>&gt; &gt;</FONT> <BR><FONT 
    size=2>&gt; &gt; What do you mean, would you like to have a NSIS protocol 
    version</FONT> <BR><FONT size=2>&gt; &gt; that starts at one hop router and 
    terminates at the next </FONT><BR><FONT size=2>&gt; first hop router.</FONT> 
    <BR><FONT size=2>&gt; &gt; This protocol will be very slow, very complex, 
    and in my opinion</FONT> <BR><FONT size=2>&gt; &gt; not useful!</FONT> 
    <BR><FONT size=2>&gt; &gt;</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT 
    size=2>&gt; You have to be more specific on slow and complex.</FONT> 
    <BR><FONT size=2>&gt; If you mean with slow the signalling delay (I think 
    you are </FONT><BR><FONT size=2>&gt; better of not </FONT><BR><FONT 
    size=2>&gt; performing some actions in each hop)</FONT> <BR><FONT 
    size=2>&gt; </FONT><BR><FONT size=2>&gt; The complextity in terms CPU 
    heavily depends on the </FONT><BR><FONT size=2>&gt; complexity of the state 
    </FONT><BR><FONT size=2>&gt; machine, which defionitly not defined yet. But 
    you are </FONT><BR><FONT size=2>&gt; definitly right, </FONT><BR><FONT 
    size=2>&gt; that it needs to be simple.</FONT> <BR><FONT size=2>&gt; 
    </FONT><BR><FONT size=2>&gt; Marcus</FONT> <BR><FONT size=2>&gt; 
    </FONT><BR><FONT size=2>&gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; Best 
    regards,</FONT> <BR><FONT size=2>&gt; &gt; Georgios</FONT> <BR><FONT 
    size=2>&gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt;</FONT> <BR><FONT 
    size=2>&gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt;</FONT> <BR><FONT 
    size=2>&gt; </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; 
    _______________________________________________</FONT> <BR><FONT size=2>&gt; 
    nsis mailing list</FONT> <BR><FONT size=2>&gt; nsis@ietf.org</FONT> 
    <BR><FONT size=2>&gt; <A href="https://www1.ietf.org/mailman/listinfo/nsis" 
    target=_blank>https://www1.ietf.org/mailman/listinfo/nsis</A></FONT> 
    <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; 
    _______________________________________________</FONT> <BR><FONT size=2>&gt; 
    nsis mailing list</FONT> <BR><FONT size=2>&gt; nsis@ietf.org</FONT> 
    <BR><FONT size=2>&gt; <A href="https://www1.ietf.org/mailman/listinfo/nsis" 
    target=_blank>https://www1.ietf.org/mailman/listinfo/nsis</A></FONT> 
    <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; 
    _______________________________________________</FONT> <BR><FONT size=2>&gt; 
    nsis mailing list</FONT> <BR><FONT size=2>&gt; nsis@ietf.org</FONT> 
    <BR><FONT size=2>&gt; <A href="https://www1.ietf.org/mailman/listinfo/nsis" 
    target=_blank>https://www1.ietf.org/mailman/listinfo/nsis</A></FONT> 
    <BR><FONT size=2>&gt; </FONT></P></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C1AA79.3EFEB850--

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



From daemon@ns.ietf.org  Thu Jan 31 14:34: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 OAA09331
	for <nsis-archive@odin.ietf.org>; Thu, 31 Jan 2002 14:34:18 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id OAA16660
	for nsis-archive@odin.ietf.org; Thu, 31 Jan 2002 14:34: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 OAA15229;
	Thu, 31 Jan 2002 14:22: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 OAA15199
	for <nsis@ns.ietf.org>; Thu, 31 Jan 2002 14:22:22 -0500 (EST)
Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08819
	for <nsis@ietf.org>; Thu, 31 Jan 2002 14:22:16 -0500 (EST)
From: Hemant.Chaskar@nokia.com
Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85])
	by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g0VImDQ29256
	for <nsis@ietf.org>; Thu, 31 Jan 2002 12:48:13 -0600 (CST)
Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T58c8fdaabfac12f255079@davir02nok.americas.nokia.com> for <nsis@ietf.org>;
 Thu, 31 Jan 2002 12:46:29 -0600
Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Thu, 31 Jan 2002 12:45:42 -0600
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [NSIS] summary of thread on data and signalling path
Date: Thu, 31 Jan 2002 13:45:41 -0500
Message-ID: <E320A8529CF07E4C967ECC2F380B0CF94F5750@bsebe001.NOE.Nokia.com>
Thread-Topic: [NSIS] summary of thread on data and signalling path
Thread-Index: AcGqeCc2xyvf6fBQTo2ar5rw8ITx0wADph2A
To: <nsis@ietf.org>
X-OriginalArrivalTime: 31 Jan 2002 18:45:42.0150 (UTC) FILETIME=[7C0B3260:01C1AA87]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id OAA15200
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

An additional issue associated with the same difficulty (though not mentioned in David's summary, but was raised on the mailing list before) is:

How can we actually perform bi-directional reservations when the forward and reverse paths are not reciprocal, with respect to routing topology and routing policy of network domains between sender and receiver? We have to have some baseline feasibility intuition while proposing requirements.

Hemant

-----Original Message-----
From: ext Michael Thomas [mailto:mat@cisco.com]
Sent: Thursday, January 31, 2002 11:55 AM
To: David.Partain@ericsson.com
Cc: NSIS Mailing List
Subject: [NSIS] summary of thread on data and signalling path


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?

	   Mike

_______________________________________________
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  Thu Jan 31 17:41: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 RAA14679
	for <nsis-archive@odin.ietf.org>; Thu, 31 Jan 2002 17:41:10 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id RAA29250
	for nsis-archive@odin.ietf.org; Thu, 31 Jan 2002 17:41: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 RAA28286;
	Thu, 31 Jan 2002 17:28:00 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA28255
	for <nsis@ns.ietf.org>; Thu, 31 Jan 2002 17:27:58 -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 RAA14426
	for <nsis@ietf.org>; Thu, 31 Jan 2002 17:27:52 -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 g0VMRO513072;
	Thu, 31 Jan 2002 17:27:24 -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 g0VMRMb08532;
	Thu, 31 Jan 2002 17:27:22 -0500 (EST)
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19)
	id <D8QAV0YB>; Thu, 31 Jan 2002 17:27:21 -0500
Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA47E1@zcard031.ca.nortel.com>
From: "Gary Kenward"<gkenward@nortelnetworks.com>
To: "'Hemant.Chaskar@nokia.com'" <Hemant.Chaskar@nokia.com>, nsis@ietf.org
Subject: RE: [NSIS] summary of thread on data and signalling path
Date: Thu, 31 Jan 2002 17:27:21 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C1AAA6.72FC3970"
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_01C1AAA6.72FC3970
Content-Type: text/plain;
	charset="iso-8859-1"

I think you are assuming an RSVP-like model, where the reservations
are made along the return path which is determined by the forwarding
path, and requires soft state storage. The need to ensure that the 
return path is the same as the forwarding path is one of the problems 
with RSVP, particularly in a mobile environment. This approach does
have a number of benefits, but isn't it too early to assume that it
is the approach for NSIS?

Gary

> -----Original Message-----
> From: Hemant.Chaskar@nokia.com [mailto:Hemant.Chaskar@nokia.com]
> Sent: January 31, 2002 13:46
> To: nsis@ietf.org
> Subject: RE: [NSIS] summary of thread on data and signalling path
> 
> 
> An additional issue associated with the same difficulty 
> (though not mentioned in David's summary, but was raised on 
> the mailing list before) is:
> 
> How can we actually perform bi-directional reservations when 
> the forward and reverse paths are not reciprocal, with 
> respect to routing topology and routing policy of network 
> domains between sender and receiver? We have to have some 
> baseline feasibility intuition while proposing requirements.
> 
> Hemant
> 
> -----Original Message-----
> From: ext Michael Thomas [mailto:mat@cisco.com]
> Sent: Thursday, January 31, 2002 11:55 AM
> To: David.Partain@ericsson.com
> Cc: NSIS Mailing List
> Subject: [NSIS] summary of thread on data and signalling path
> 
> 
> 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?
> 
> 	   Mike
> 
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis
> 
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis
> 

------_=_NextPart_001_01C1AAA6.72FC3970
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] summary of thread on data and signalling path</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>I think you are assuming an RSVP-like model, where =
the reservations</FONT>
<BR><FONT SIZE=3D2>are made along the return path which is determined =
by the forwarding</FONT>
<BR><FONT SIZE=3D2>path, and requires soft state storage. The need to =
ensure that the </FONT>
<BR><FONT SIZE=3D2>return path is the same as the forwarding path is =
one of the problems </FONT>
<BR><FONT SIZE=3D2>with RSVP, particularly in a mobile environment. =
This approach does</FONT>
<BR><FONT SIZE=3D2>have a number of benefits, but isn't it too early to =
assume that it</FONT>
<BR><FONT SIZE=3D2>is the approach for NSIS?</FONT>
</P>

<P><FONT SIZE=3D2>Gary</FONT>
</P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Hemant.Chaskar@nokia.com [<A =
HREF=3D"mailto:Hemant.Chaskar@nokia.com">mailto:Hemant.Chaskar@nokia.com=
</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: January 31, 2002 13:46</FONT>
<BR><FONT SIZE=3D2>&gt; To: nsis@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: RE: [NSIS] summary of thread on data =
and signalling path</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; An additional issue associated with the same =
difficulty </FONT>
<BR><FONT SIZE=3D2>&gt; (though not mentioned in David's summary, but =
was raised on </FONT>
<BR><FONT SIZE=3D2>&gt; the mailing list before) is:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; How can we actually perform bi-directional =
reservations when </FONT>
<BR><FONT SIZE=3D2>&gt; the forward and reverse paths are not =
reciprocal, with </FONT>
<BR><FONT SIZE=3D2>&gt; respect to routing topology and routing policy =
of network </FONT>
<BR><FONT SIZE=3D2>&gt; domains between sender and receiver? We have to =
have some </FONT>
<BR><FONT SIZE=3D2>&gt; baseline feasibility intuition while proposing =
requirements.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Hemant</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: ext Michael Thomas [<A =
HREF=3D"mailto:mat@cisco.com">mailto:mat@cisco.com</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Thursday, January 31, 2002 11:55 =
AM</FONT>
<BR><FONT SIZE=3D2>&gt; To: David.Partain@ericsson.com</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: NSIS Mailing List</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: [NSIS] summary of thread on data and =
signalling path</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; David Partain writes:</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt; Marcus started this thread by =
stating that he doesn't think this</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt; should be a requirement.&nbsp; I =
think we need to consider the</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt; scenarios.</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;&nbsp; - There are absolutely going =
to be cases where a centralized</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;&nbsp;&nbsp;&nbsp; entity will take a =
decision about QoS requests.&nbsp; In this</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;&nbsp;&nbsp;&nbsp; case, there's no =
question there is no need to have data</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;&nbsp;&nbsp;&nbsp; follow the =
signalling path.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Has somebody shown, absolutely, how this =
centralized</FONT>
<BR><FONT SIZE=3D2>&gt; thing understands an arbitrary routing topology =
between</FONT>
<BR><FONT SIZE=3D2>&gt; the sender and receiver? What happends when it =
leaves</FONT>
<BR><FONT SIZE=3D2>&gt; an AS?</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp; =
Mike</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>
<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_01C1AAA6.72FC3970--

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



From daemon@ns.ietf.org  Thu Jan 31 18:51: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 SAA15790
	for <nsis-archive@odin.ietf.org>; Thu, 31 Jan 2002 18:50:59 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id SAA01625
	for nsis-archive@odin.ietf.org; Thu, 31 Jan 2002 18:51: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 SAA01540;
	Thu, 31 Jan 2002 18:49: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 SAA01509
	for <nsis@ns.ietf.org>; Thu, 31 Jan 2002 18:49:22 -0500 (EST)
Received: from arb-exchange1.cetaceannetworks.com ([63.127.199.197])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15752
	for <nsis@ietf.org>; Thu, 31 Jan 2002 18:49:17 -0500 (EST)
Received: by mail.cetaceannetworks.com with Internet Mail Service (5.5.2653.19)
	id <1A6P3ZMY>; Thu, 31 Jan 2002 18:46:03 -0500
Message-ID: <6D8664171C38D511B5AD0002B325CE6633ECD8@mail.cetaceannetworks.com>
From: "Freytsis, Ilya" <ifreytsis@cetacean.com>
To: "'john.loughney@nokia.com'" <john.loughney@nokia.com>
Cc: "'nsis@ietf.org'" <nsis@ietf.org>
Subject: RE: [NSIS] RE: Independence of signaling and data path
Date: Thu, 31 Jan 2002 18:46:02 -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 think it would help if you elaborate on the context to use the term
"proxy".

On the different subject I would like to discuss the idea prompted by the
discussions with the telephony carriers who are thinking about migrating to
VoIP and associated QoS issues. 
So far we were talking about the following entities participating in NSIS
signaling: hosts, routers/switches and controllers/BB. When we were touching
applications it was assumed something running on the host, communicating to
the other end on the other host, aware of its QoS needs and requesting QoS
from the network (please correct me here if I am completely wrong). It seems
that VoIP does not quite fit into this model since it includes other
entities (lets call it softswitch/SS even everybody agrees it is not
precisely defined but sufficient for my goal) that want to be part of the
resource allocation game but do not generate the traffic and have no
knowledge of the network topology. What I mean that from the telephony
carriers perspective only the centralize intelligence of the VoIP
application should be allowed to requests resources from the network and
endpoint (VoIP gateways, IP phones) should be prohibited to do it. (It seems
to me it is possible only with the network deploying QoS technology based
centralized resource management). This function of the SS (in my example)
can be called for the lack of the better term "Resource-Request Broker". My
question is: should NSIS protocol accommodate this functional entity? I am
pretty sure that applications other than VoIP and multimedia conferencing
may have similar requirements. 
I vote for it but I am thrilled to hear others.

Ilya Freytsis


From: john.loughney@nokia.com
charset="iso-8859-1"
Subject: RE: [NSIS] RE: Independence of signaling and data path
Date: Thu, 31 Jan 2002 14:52:28 +0200
To: <ifreytsis@Cetacean.com>
Cc: <nsis@ietf.org>

Hi Ilya,

> I think there is a big difference between idea of "router" 
> and "BB". Router is one of the most generic ideas in the
> IP world while "BB" can be much more tightly coupled
> with the bandwidth management technology in use. For that
> reason I believe it would be much easier to standardize router-router
> interworkings and leave router-BB (within the same domain) and BB-BB
> (inter-domain) in the realm of specific technology. On the 
> other hands if we'll be able to find a common ground between different 
> technologies for the BB-BB interface I definitely would not object
> to include it into NSIS.

Perhaps we should use a more generic term, such as proxy.
This proxy could be light-weight & reside at an edge router, 
or at a bandwidth broker.  I think that we should stick
to a more generic term, because when discussing Bandwidth 
broakers, we come very close to actual reservation mechanisms.

John


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



From daemon@ns.ietf.org  Thu Jan 31 19:31: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 TAA16491
	for <nsis-archive@odin.ietf.org>; Thu, 31 Jan 2002 19:31:10 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id TAA03864
	for nsis-archive@odin.ietf.org; Thu, 31 Jan 2002 19:31: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 TAA03179;
	Thu, 31 Jan 2002 19:21: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 TAA03145
	for <nsis@ns.ietf.org>; Thu, 31 Jan 2002 19:21:43 -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 TAA16277
	for <nsis@ietf.org>; Thu, 31 Jan 2002 19:21:40 -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 g110LqQ06551
	for <nsis@ietf.org>; Thu, 31 Jan 2002 18:21:52 -0600 (CST)
Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T58ca308826ac12f254079@davir01nok.americas.nokia.com> for <nsis@ietf.org>;
 Thu, 31 Jan 2002 18:21:40 -0600
Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Thu, 31 Jan 2002 18:20:29 -0600
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C1AAB6.40B4AB30"
Subject: RE: [NSIS] summary of thread on data and signalling path
Date: Thu, 31 Jan 2002 19:20:28 -0500
Message-ID: <E320A8529CF07E4C967ECC2F380B0CF94F5753@bsebe001.NOE.Nokia.com>
Thread-Topic: [NSIS] summary of thread on data and signalling path
Thread-Index: AcGqpotsZk+TSKBLS76L4t4Fltpl7wAD1kTw
To: <nsis@ietf.org>
X-OriginalArrivalTime: 01 Feb 2002 00:20:29.0568 (UTC) FILETIME=[4113F000:01C1AAB6]
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_01C1AAB6.40B4AB30
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Gary, I am not referring to the problem you are talking about (though =
I agree that it is one of the serious shortcomings of RSVP when used =
with Mobile IP). I am talking about bi-directional data streams, where =
the packet paths in two directions are different.  - Hemant
=20
-----Original Message-----
From: ext Gary Kenward [mailto:gkenward@nortelnetworks.com]
Sent: Thursday, January 31, 2002 5:27 PM
To: Chaskar Hemant (NRC/Boston); nsis@ietf.org
Subject: RE: [NSIS] summary of thread on data and signalling path



I think you are assuming an RSVP-like model, where the reservations=20
are made along the return path which is determined by the forwarding=20
path, and requires soft state storage. The need to ensure that the=20
return path is the same as the forwarding path is one of the problems=20
with RSVP, particularly in a mobile environment. This approach does=20
have a number of benefits, but isn't it too early to assume that it=20
is the approach for NSIS?=20

Gary=20

> -----Original Message-----=20
> From: Hemant.Chaskar@nokia.com [ mailto:Hemant.Chaskar@nokia.com]=20
> Sent: January 31, 2002 13:46=20
> To: nsis@ietf.org=20
> Subject: RE: [NSIS] summary of thread on data and signalling path=20
>=20
>=20
> An additional issue associated with the same difficulty=20
> (though not mentioned in David's summary, but was raised on=20
> the mailing list before) is:=20
>=20
> How can we actually perform bi-directional reservations when=20
> the forward and reverse paths are not reciprocal, with=20
> respect to routing topology and routing policy of network=20
> domains between sender and receiver? We have to have some=20
> baseline feasibility intuition while proposing requirements.=20
>=20
> Hemant=20
>=20
> -----Original Message-----=20
> From: ext Michael Thomas [ mailto:mat@cisco.com]=20
> Sent: Thursday, January 31, 2002 11:55 AM=20
> To: David.Partain@ericsson.com=20
> Cc: NSIS Mailing List=20
> Subject: [NSIS] summary of thread on data and signalling path=20
>=20
>=20
> David Partain writes:=20
>  > Marcus started this thread by stating that he doesn't think this=20
>  > should be a requirement.  I think we need to consider the=20
>  > scenarios.=20
>  >=20
>  >  - There are absolutely going to be cases where a centralized=20
>  >    entity will take a decision about QoS requests.  In this=20
>  >    case, there's no question there is no need to have data=20
>  >    follow the signalling path.=20
>=20
> Has somebody shown, absolutely, how this centralized=20
> thing understands an arbitrary routing topology between=20
> the sender and receiver? What happends when it leaves=20
> an AS?=20
>=20
>          Mike=20
>=20
> _______________________________________________=20
> nsis mailing list=20
> nsis@ietf.org=20
> https://www1.ietf.org/mailman/listinfo/nsis=20
>=20
> _______________________________________________=20
> nsis mailing list=20
> nsis@ietf.org=20
> https://www1.ietf.org/mailman/listinfo/nsis=20
>=20


------_=_NextPart_001_01C1AAB6.40B4AB30
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">
<TITLE>RE: [NSIS] summary of thread on data and signalling path</TITLE>

<META content=3D"MSHTML 5.50.4611.1300" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DTahoma color=3D#0000ff size=3D2><SPAN =
class=3D304541700-01022002>Hi=20
Gary, I am not referring to the problem you are talking about (though=20
I&nbsp;agree that it is one of the serious shortcomings of =
RSVP&nbsp;when used=20
with&nbsp;Mobile IP). I am talking about bi-directional data streams, =
where the=20
packet paths in two directions are different.&nbsp; - =
Hemant</SPAN></FONT></DIV>
<DIV><FONT face=3DTahoma color=3D#0000ff size=3D2><SPAN=20
class=3D304541700-01022002></SPAN></FONT>&nbsp;</DIV>
<DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
size=3D2>-----Original Message-----<BR><B>From:</B> ext Gary Kenward=20
[mailto:gkenward@nortelnetworks.com]<BR><B>Sent:</B> Thursday, January =
31, 2002=20
5:27 PM<BR><B>To:</B> Chaskar Hemant (NRC/Boston);=20
nsis@ietf.org<BR><B>Subject:</B> RE: [NSIS] summary of thread on data =
and=20
signalling path<BR><BR></FONT></DIV>
<P><FONT size=3D2>I think you are assuming an RSVP-like model, where the =

reservations</FONT> <BR><FONT size=3D2>are made along the return path =
which is=20
determined by the forwarding</FONT> <BR><FONT size=3D2>path, and =
requires soft=20
state storage. The need to ensure that the </FONT><BR><FONT =
size=3D2>return path=20
is the same as the forwarding path is one of the problems =
</FONT><BR><FONT=20
size=3D2>with RSVP, particularly in a mobile environment. This approach=20
does</FONT> <BR><FONT size=3D2>have a number of benefits, but isn't it =
too early=20
to assume that it</FONT> <BR><FONT size=3D2>is the approach for =
NSIS?</FONT> </P>
<P><FONT size=3D2>Gary</FONT> </P>
<P><FONT size=3D2>&gt; -----Original Message-----</FONT> <BR><FONT =
size=3D2>&gt;=20
From: Hemant.Chaskar@nokia.com [<A=20
href=3D"mailto:Hemant.Chaskar@nokia.com">mailto:Hemant.Chaskar@nokia.com<=
/A>]</FONT>=20
<BR><FONT size=3D2>&gt; Sent: January 31, 2002 13:46</FONT> <BR><FONT =
size=3D2>&gt;=20
To: nsis@ietf.org</FONT> <BR><FONT size=3D2>&gt; Subject: RE: [NSIS] =
summary of=20
thread on data and signalling path</FONT> <BR><FONT size=3D2>&gt; =
</FONT><BR><FONT=20
size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; An additional issue =
associated with the=20
same difficulty </FONT><BR><FONT size=3D2>&gt; (though not mentioned in =
David's=20
summary, but was raised on </FONT><BR><FONT size=3D2>&gt; the mailing =
list before)=20
is:</FONT> <BR><FONT size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; How =
can we=20
actually perform bi-directional reservations when </FONT><BR><FONT =
size=3D2>&gt;=20
the forward and reverse paths are not reciprocal, with </FONT><BR><FONT=20
size=3D2>&gt; respect to routing topology and routing policy of network=20
</FONT><BR><FONT size=3D2>&gt; domains between sender and receiver? We =
have to=20
have some </FONT><BR><FONT size=3D2>&gt; baseline feasibility intuition =
while=20
proposing requirements.</FONT> <BR><FONT size=3D2>&gt; </FONT><BR><FONT=20
size=3D2>&gt; Hemant</FONT> <BR><FONT size=3D2>&gt; </FONT><BR><FONT =
size=3D2>&gt;=20
-----Original Message-----</FONT> <BR><FONT size=3D2>&gt; From: ext =
Michael Thomas=20
[<A href=3D"mailto:mat@cisco.com">mailto:mat@cisco.com</A>]</FONT> =
<BR><FONT=20
size=3D2>&gt; Sent: Thursday, January 31, 2002 11:55 AM</FONT> <BR><FONT =

size=3D2>&gt; To: David.Partain@ericsson.com</FONT> <BR><FONT =
size=3D2>&gt; Cc: NSIS=20
Mailing List</FONT> <BR><FONT size=3D2>&gt; Subject: [NSIS] summary of =
thread on=20
data and signalling path</FONT> <BR><FONT size=3D2>&gt; </FONT><BR><FONT =

size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; David Partain =
writes:</FONT> <BR><FONT=20
size=3D2>&gt;&nbsp; &gt; Marcus started this thread by stating that he =
doesn't=20
think this</FONT> <BR><FONT size=3D2>&gt;&nbsp; &gt; should be a=20
requirement.&nbsp; I think we need to consider the</FONT> <BR><FONT=20
size=3D2>&gt;&nbsp; &gt; scenarios.</FONT> <BR><FONT size=3D2>&gt;&nbsp; =
&gt;=20
</FONT><BR><FONT size=3D2>&gt;&nbsp; &gt;&nbsp; - There are absolutely =
going to be=20
cases where a centralized</FONT> <BR><FONT size=3D2>&gt;&nbsp;=20
&gt;&nbsp;&nbsp;&nbsp; entity will take a decision about QoS =
requests.&nbsp; In=20
this</FONT> <BR><FONT size=3D2>&gt;&nbsp; &gt;&nbsp;&nbsp;&nbsp; case, =
there's no=20
question there is no need to have data</FONT> <BR><FONT =
size=3D2>&gt;&nbsp;=20
&gt;&nbsp;&nbsp;&nbsp; follow the signalling path.</FONT> <BR><FONT =
size=3D2>&gt;=20
</FONT><BR><FONT size=3D2>&gt; Has somebody shown, absolutely, how this=20
centralized</FONT> <BR><FONT size=3D2>&gt; thing understands an =
arbitrary routing=20
topology between</FONT> <BR><FONT size=3D2>&gt; the sender and receiver? =
What=20
happends when it leaves</FONT> <BR><FONT size=3D2>&gt; an AS?</FONT> =
<BR><FONT=20
size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
&nbsp;&nbsp; Mike</FONT> <BR><FONT size=3D2>&gt; </FONT><BR><FONT =
size=3D2>&gt;=20
_______________________________________________</FONT> <BR><FONT =
size=3D2>&gt;=20
nsis mailing list</FONT> <BR><FONT size=3D2>&gt; nsis@ietf.org</FONT> =
<BR><FONT=20
size=3D2>&gt; <A target=3D_blank=20
href=3D"https://www1.ietf.org/mailman/listinfo/nsis">https://www1.ietf.or=
g/mailman/listinfo/nsis</A></FONT>=20
<BR><FONT size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt;=20
_______________________________________________</FONT> <BR><FONT =
size=3D2>&gt;=20
nsis mailing list</FONT> <BR><FONT size=3D2>&gt; nsis@ietf.org</FONT> =
<BR><FONT=20
size=3D2>&gt; <A target=3D_blank=20
href=3D"https://www1.ietf.org/mailman/listinfo/nsis">https://www1.ietf.or=
g/mailman/listinfo/nsis</A></FONT>=20
<BR><FONT size=3D2>&gt; </FONT></P></BODY></HTML>

------_=_NextPart_001_01C1AAB6.40B4AB30--

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