Subject: RE: [NSIS] Two kinds of requirements

From: "Chen, Weijing" <[email-masked]>
Date: Wed, 16 Jan 2002 09:06:15 -0600

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
[email-masked]

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: 	[email-masked] [mailto:[email-masked]] 
Sent:	Wednesday, January 16, 2002 6:00 AM
To:	[email-masked]; [email-masked]
Cc:	[email-masked]
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:[email-masked]]
Sent: 22 December 2001 23:57
To: [email-masked]
Cc: [email-masked]
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, [email-masked] 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
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nsis

_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: "Roy, Radhika R, ALASO" <[email-masked]>
Date: Wed, 16 Jan 2002 09:48:09 -0500

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
[email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, January 16, 2002 7:00 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [NSIS] Two kinds of requirements

...

[RRR] You are right.

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

[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

---

From: "Chen, Weijing" <[email-masked]>
Date: Wed, 16 Jan 2002 09:45:44 -0600

-----Original Message-----
From: 	Chen, Weijing  
Sent:	Wednesday, January 16, 2002 9:06 AM
To:	[email-masked]'; [email-masked];
[email-masked]
Cc:	[email-masked]

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

]

--
Weijing Chen
SBC Technology Resources
9505 Arboretum Blvd.
Austin, TX 78759
512 372 5710
[email-masked]

 -----Original Message-----
From: 	[email-masked] [mailto:[email-masked]] 
Sent:	Wednesday, January 16, 2002 6:00 AM
To:	[email-masked]; [email-masked]
Cc:	[email-masked]
Subject:	RE: [NSIS] Two kinds of requirements

Dick Knight

-----Original Message-----
From: Brian Williams [mailto:[email-masked]]
Sent: 22 December 2001 23:57
To: [email-masked]
Cc: [email-masked]
Subject: Re: [NSIS] Two kinds of requirements

Hi.

---

From: "Chaskar Hemant (NRC/Boston)" <[email-masked]>
Date: Wed, 16 Jan 2002 11:45:06 -0500

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

---

From: "Roy, Radhika R, ALASO" <[email-masked]>
Date: Wed, 16 Jan 2002 12:19:39 -0500

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:[email-masked]]
Sent: Wednesday, January 16, 2002 11:45 AM
To: Roy, Radhika R, ALASO
Cc: [email-masked]
Subject: RE: [NSIS] Two kinds of requirements

Hi Radhika:

--------------------------------------snip------------------------------
-----------------

Hemant

---

From: "Freytsis, Ilya" <[email-masked]>
Date: Wed, 16 Jan 2002 13:58:01 -0500

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

---

From: "Chen, Weijing" <[email-masked]>
Date: Wed, 16 Jan 2002 13:19:30 -0600

My comment starts in [WW]
--
Weijing Chen
SBC Technology Resources
9505 Arboretum Blvd.
Austin, TX 78759
512 372 5710
[email-masked]

 -----Original Message-----
From: 	Freytsis, Ilya [mailto:[email-masked]] 
Sent:	Wednesday, January 16, 2002 12:58 PM
To:	[email-masked]'
Cc:	[email-masked]'
Subject:	RE: [NSIS] Two kinds of requirements

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

Ilya Freytsis

---

From: Yaron Kahana <[email-masked]>
Date: Wed, 16 Jan 2002 23:41:58 +0200

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:[email-masked]] 
Sent:	Wednesday, January 16, 2002 11:20 PM
To:	Yaron Kahana
Cc:	[email-masked]; Geib, Ruediger; [email-masked];
[email-masked]

> 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

---

From: "Chen, Weijing" <[email-masked]>
Date: Wed, 16 Jan 2002 22:19:46 -0600

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
[email-masked]

 -----Original Message-----
From: 	Roy, Radhika R, ALASO [mailto:[email-masked]] 
Sent:	Wednesday, January 16, 2002 2:18 PM
To:	Steven Berson
Cc:	Michael Thomas; [email-masked];
[email-masked]; [email-masked]; [email-masked]
Subject:	RE: [NSIS] Two kinds of requirements

-----Original Message-----
From: Steven Berson [mailto:[email-masked]]
Sent: Wednesday, January 16, 2002 2:08 PM
To: Roy, Radhika R, ALASO
Cc: Michael Thomas; [email-masked];
[email-masked]; [email-masked]; [email-masked]
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
> 
> Sent: Wednesday, January 16, 2002 11:31 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> 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
> 
>

---

From: "Chen, Weijing" <[email-masked]>
Date: Wed, 16 Jan 2002 09:22:17 -0600

-----Original Message-----
From: 	Chen, Weijing  
Sent:	Wednesday, January 16, 2002 9:06 AM
To:	[email-masked]'; [email-masked];
[email-masked]
Cc:	[email-masked]

[ Oops, I missed a picture here:

 <<muni.pdf>> 

]

--
Weijing Chen
SBC Technology Resources
9505 Arboretum Blvd.
Austin, TX 78759
512 372 5710
[email-masked]

 -----Original Message-----
From: 	[email-masked] [mailto:[email-masked]] 
Sent:	Wednesday, January 16, 2002 6:00 AM
To:	[email-masked]; [email-masked]
Cc:	[email-masked]
Subject:	RE: [NSIS] Two kinds of requirements

Dick Knight

-----Original Message-----
From: Brian Williams [mailto:[email-masked]]
Sent: 22 December 2001 23:57
To: [email-masked]
Cc: [email-masked]
Subject: Re: [NSIS] Two kinds of requirements

Hi.

---

From: "Loughney John (NRC/Helsinki)" <[email-masked]>
Date: Thu, 17 Jan 2002 08:34:33 +0200

Hi Radhika,

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

---

From: "Loughney John (NRC/Helsinki)" <[email-masked]>
Date: Thu, 17 Jan 2002 08:34:32 +0200

Hi Steve,

> Integrated Services Operation over Diffserv Networks'' by Bernet, et 

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

---

From: "Loughney John (NRC/Helsinki)" <[email-masked]>
Date: Thu, 17 Jan 2002 08:34:25 +0200

Hi Dick,

Thanks for your comments.

> 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

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

---

From: "Loughney John (NRC/Helsinki)" <[email-masked]>
Date: Thu, 17 Jan 2002 08:34:29 +0200

Hi Mike,

> 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

---

From: "Loughney John (NRC/Helsinki)" <[email-masked]>
Date: Thu, 17 Jan 2002 08:34:26 +0200

Hi Rüdiger,

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

And are more prone to breaking.

best regards,
John

---

From: "Georgios Karagiannis (ELN)" <[email-masked]>
Date: Thu, 17 Jan 2002 10:39:03 +0100

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: [email-masked] [mailto:[email-masked]]
Sent: woensdag 16 januari 2002 13:00
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [NSIS] Two kinds of requirements

Dick Knight

-----Original Message-----
From: Brian Williams [mailto:[email-masked]]
Sent: 22 December 2001 23:57
To: [email-masked]
Cc: [email-masked]
Subject: Re: [NSIS] Two kinds of requirements

Hi.

---

From: "Georgios Karagiannis (ELN)" <[email-masked]>
Date: Thu, 17 Jan 2002 11:03:31 +0100

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:[email-masked]]
Sent: woensdag 16 januari 2002 22:16
To: [email-masked]; Geib, Ruediger; [email-masked]
Cc: [email-masked]
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:[email-masked] <mailto:[email-masked]> ] 
Sent:   Wednesday, January 16, 2002 5:35 PM 
To:     Geib, Ruediger; [email-masked] 
Cc:     [email-masked] 
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" 
<[email-masked]> 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 
> 
>> 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). 
>> 
>> QoS mechanism and may lend itself to the signalling of 
>> pre-defined QoS classes rather than parameters. 
>> 
>> Dick Knight 
> 
> 
> https://www1.ietf.org/mailman/listinfo/nsis <https://www1.ietf.org/mailman/listinfo/nsis>  
> 

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

E-Mail: [email-masked] 
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 
[email-masked] 
https://www1.ietf.org/mailman/listinfo/nsis <https://www1.ietf.org/mailman/listinfo/nsis>

---

From: "Georgios Karagiannis (ELN)" <[email-masked]>
Date: Thu, 17 Jan 2002 11:20:18 +0100

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:[email-masked]]
Sent: donderdag 17 januari 2002 7:35
To: ext Steven Berson
Cc: [email-masked]
Subject: RE: [NSIS] Two kinds of requirements

Hi Steve,

best regards,
John

---

From: Yaron Kahana <[email-masked]>
Date: Thu, 17 Jan 2002 13:06:35 +0200

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:[email-masked]] 
Sent:	Thursday, January 17, 2002 12:17 PM
To:	Yaron Kahana; Geib, Ruediger; [email-masked]
Cc:	[email-masked]
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 
<[email-masked]> wrote:

> 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.
>
> 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
>
> From:   Marcus Brunner [mailto:[email-masked]]
> that you want to limit/fix as many parameters as possible? Or are you
> more  think about standardized services everybody understands?
>
> Marcus
>
>> 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
>>
> WWW:    http://www.ccrle.nec.de/
> personal home page: http://www.brubers.org/marcus
>
>

E-Mail: [email-masked]
WWW:    http://www.ccrle.nec.de/
personal home page: http://www.brubers.org/marcus

---

From: "Loughney John (NRC/Helsinki)" <[email-masked]>
Date: Thu, 17 Jan 2002 13:19:22 +0200

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

---

From: Yaron Kahana <[email-masked]>
Date: Thu, 17 Jan 2002 13:23:56 +0200

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:[email-masked]] 
Sent:	Thursday, January 17, 2002 1:28 PM
To:	Yaron Kahana; 'Georgios Karagiannis (ELN)'; Geib, Ruediger;
'Freytsis, Ilya'
Cc:	[email-masked]

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 
<[email-masked]> 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
>
> From: Georgios Karagiannis (ELN)
> [mailto:[email-masked]]  Sent: Thursday, January
> 17, 2002 12:04 PM
> To: 'Yaron Kahana'; Geib, Ruediger; 'Freytsis, Ilya'
> Cc: [email-masked]
> 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
>
> he upgrade his infrastructure, before the chicke
>
> Yaron Kahana
> COGITO Project Manager,
> COMGATES
>
> From:   Marcus Brunner [ mailto:[email-masked]
> <mailto:[email-masked]> ]  Sent:   Wednesday, January 16, 2002 5:35
> PM
>> <https://www1.ietf.org/mailman/listinfo/nsis>
>>
>
>
> <http://www.brubers.org/marcus>
>
>
> <https://www1.ietf.org/mailman/listinfo/nsis>

---

From: "Loughney John (NRC/Helsinki)" <[email-masked]>
Date: Thu, 17 Jan 2002 13:25:06 +0200

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

---

From: "Loughney John (NRC/Helsinki)" <[email-masked]>
Date: Thu, 17 Jan 2002 13:26:52 +0200

Hi Georgios,

> a "brief" analysis, in the context of NSIS, of RFC2998

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

---

From: "Georgios Karagiannis (ELN)" <[email-masked]>
Date: Thu, 17 Jan 2002 13:43:38 +0100

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:[email-masked]]
Sent: donderdag 17 januari 2002 12:25
To: 'ext Georgios Karagiannis (ELN)'; [email-masked]
Cc: [email-masked]
Subject: RE: [NSIS] Two kinds of requirements

Hi Georgios,

 

best regards,
John

---

From: "Georgios Karagiannis (ELN)" <[email-masked]>
Date: Thu, 17 Jan 2002 13:35:23 +0100

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:[email-masked]]
Sent: donderdag 17 januari 2002 12:09
To: 'Georgios Karagiannis (ELN)'; Geib, Ruediger; 'Freytsis, Ilya'
Cc: [email-masked]
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:[email-masked] <mailto:[email-masked]> ] 
Sent: Thursday, January 17, 2002 12:04 PM 
To: 'Yaron Kahana'; Geib, Ruediger; 'Freytsis, Ilya' 
Cc: [email-masked] 
Subject: RE: [NSIS] Two kinds of requirements 

Hi Yaron, Ilya, Ruediger 

Best Regards, 
Georgios 

-----Original Message----- 
From: Yaron Kahana [ mailto:[email-masked] <mailto:[email-masked]> ] 
Sent: woensdag 16 januari 2002 22:16 
To: [email-masked]; Geib, Ruediger; [email-masked] 
Cc: [email-masked] 
Subject: RE: [NSIS] Two kinds of requirements 

Hello Ruediger, Marcus, 

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

Yaron Kahana 
COGITO Project Manager, 
COMGATES 

 -----Original Message----- 
From:   Marcus Brunner [ mailto:[email-masked] <mailto:[email-masked]>  < mailto:[email-masked] <mailto:[email-masked]> > ] 
Sent:   Wednesday, January 16, 2002 5:35 PM 
To:     Geib, Ruediger; [email-masked] 
Cc:     [email-masked] 
Subject:        RE: [NSIS] Two kinds of requirements 

Ruediger, 

Marcus

---

From: Yaron Kahana <[email-masked]>
Date: Thu, 17 Jan 2002 14:46:42 +0200

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:[email-masked]]
Sent: Thursday, January 17, 2002 2:35 PM
To: 'Yaron Kahana'
Cc: [email-masked]
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:[email-masked]]
Sent: donderdag 17 januari 2002 12:09
To: 'Georgios Karagiannis (ELN)'; Geib, Ruediger; 'Freytsis, Ilya'
Cc: [email-masked]
Subject: RE: [NSIS] Two kinds of requirements

Hi,

Yaron

-----Original Message-----
From: Georgios Karagiannis (ELN) [
mailto:[email-masked]
<mailto:[email-masked]> ]
Sent: Thursday, January 17, 2002 12:04 PM
To: 'Yaron Kahana'; Geib, Ruediger; 'Freytsis, Ilya'
Cc: [email-masked]
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:[email-masked]
<mailto:[email-masked]> ]
Sent: woensdag 16 januari 2002 22:16
To: [email-masked]; Geib, Ruediger; [email-masked]
Cc: [email-masked]
Subject: RE: [NSIS] Two kinds of requirements

Hello Ruediger, Marcus,

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:[email-masked]
<mailto:[email-masked]>  < mailto:[email-masked]
<mailto:[email-masked]> > ]
Sent:   Wednesday, January 16, 2002 5:35 PM
To:     Geib, Ruediger; [email-masked]
Cc:     [email-masked]
Subject:        RE: [NSIS] Two kinds of requirements

Ruediger,

Marcus

---

From: Kappler Cornelia <[email-masked]>
Date: Thu, 17 Jan 2002 13:52:08 +0100

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

> From:	Loughney John (NRC/Helsinki) [SMTP:[email-masked]]
> Sent:	Thursday, January 17, 2002 1:45 PM
> To:	'ext Georgios Karagiannis (ELN)'
> Cc:	[email-masked]
> If it is optional, then it is not required.
> 
> John
>

---

From: Yaron Kahana <[email-masked]>
Date: Thu, 17 Jan 2002 15:06:11 +0200

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:[email-masked]]
Sent: Thursday, January 17, 2002 3:00 PM
To: 'Yaron Kahana'
Cc: [email-masked]
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:[email-masked]]
Sent: donderdag 17 januari 2002 13:47
To: 'Georgios Karagiannis (ELN)'
Cc: [email-masked]
Subject: RE: [NSIS] Two kinds of requirements

Hi Georgios,

Best Regards
Yaron

-----Original Message-----

Hi Yaron

Best Regards,
Georgios

-----Original Message-----
From: Yaro mailto:[email-masked] <mailto:[email-masked]> ]
Sent: donderdag 17 januari 2002 12:09
To: 'Georgios Karagiannis (ELN)'; Geib, Ruediger; 'Freytsis, Ilya'
Cc: [email-masked]
Subject: RE: [NSIS] Two kinds of requirements

Hi,

Yaron

-----Original Message-----
From: Georgios Karagiannis (ELN) [
mailto:[email-masked]
<mailto:[email-masked]>  <
mailto:[email-masked]
<mailto:[email-masked]> > ]

Hi Yaron, Ilya, Ruediger

Best Regards,
Georgios

-----Original Message-----
From: Yaron Kahana [ mailto:[email-masked]
<mailto:[email-masked]>  < mailto:[email-masked]
<mailto:[email-masked]> > ]
Sent: woensdag 16 januari 2002 22:16
To: [email-masked]; Geib, Ruediger; [email-masked]
Cc: [email-masked]
Subject: RE: [NSIS] Two kinds of requirements

Hello Ruediger, Marcus,

Yaron Kahana
COGITO Project Manager,
COMGATES

 -----Original Message-----
From:   Marcus Brunner [ mailto:[email-masked]
<mailto:[email-masked]>  < mailto:[email-masked]
<mailto:[email-masked]> >  < mailto:[email-masked]
<mailto:[email-masked]>  < mailto:[email-masked]
<mailto:[email-masked]> > > ]

Ruediger,

Marcus

---

From: "Georgios Karagiannis (ELN)" <[email-masked]>
Date: Thu, 17 Jan 2002 13:59:37 +0100

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:[email-masked]]
Sent: donderdag 17 januari 2002 13:47
To: 'Georgios Karagiannis (ELN)'
Cc: [email-masked]
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:[email-masked] <mailto:[email-masked]> ] 
Sent: Thursday, January 17, 2002 2:35 PM 
To: 'Yaron Kahana' 
Cc: [email-masked] 
Subject: RE: [NSIS] Two kinds of requirements 

Hi Yaron 

Best Regards, 
Georgios 

-----Original Message----- 
From: Yaro mailto:[email-masked] <mailto:[email-masked]> ] 
Sent: donderdag 17 januari 2002 12:09 
To: 'Georgios Karagiannis (ELN)'; Geib, Ruediger; 'Freytsis, Ilya' 
Cc: [email-masked] 
Subject: RE: [NSIS] Two kinds of requirements 

Hi, 

Yaron 

-----Original Message----- 
From: Georgios Karagiannis (ELN) [ mailto:[email-masked] <mailto:[email-masked]>  < mailto:[email-masked] <mailto:[email-masked]> > ]

Hi Yaron, Ilya, Ruediger 

Best Regards, 
Georgios 

-----Original Message----- 
From: Yaron Kahana [ mailto:[email-masked] <mailto:[email-masked]>  < mailto:[email-masked] <mailto:[email-masked]> > ] 
Sent: woensdag 16 januari 2002 22:16 
To: [email-masked]; Geib, Ruediger; [email-masked] 
Cc: [email-masked] 
Subject: RE: [NSIS] Two kinds of requirements 

Hello Ruediger, Marcus, 

Yaron Kahana 
COGITO Project Manager, 
COMGATES 

 -----Original Message----- 
From:   Marcus Brunner [ mailto:[email-masked] <mailto:[email-masked]>  < mailto:[email-masked] <mailto:[email-masked]> >  < mailto:[email-masked] <mailto:[email-masked]>  < mailto:[email-masked] <mailto:[email-masked]> > > ]

Ruediger, 

Marcus

---

From: "Georgios Karagiannis (ELN)" <[email-masked]>
Date: Thu, 17 Jan 2002 14:09:57 +0100

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:[email-masked]]
Sent: donderdag 17 januari 2002 13:54
To: 'ext Kappler Cornelia'; 'ext Georgios Karagiannis (ELN)'
Cc: [email-masked]
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

---

From: "Georgios Karagiannis (ELN)" <[email-masked]>
Date: Thu, 17 Jan 2002 14:11:36 +0100

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:[email-masked]]
Sent: donderdag 17 januari 2002 14:06
To: 'Georgios Karagiannis (ELN)'
Cc: [email-masked]
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:[email-masked] <mailto:[email-masked]> ] 
Sent: Thursday, January 17, 2002 3:00 PM 
To: 'Yaron Kahana' 
Cc: [email-masked] 
Subject: RE: [NSIS] Two kinds of requirements 

Hi Yaron 

Best Regards, 
Georgios 

-----Original Message----- 
From: Yaron Kahana [ mailto:[email-masked] <mailto:[email-masked]> ] 
Sent: donderdag 17 januari 2002 13:47 
To: 'Georgios Karagiannis (ELN)' 
Cc: [email-masked] 
Subject: RE: [NSIS] Two kinds of requirements 

Hi Georgios,

---

From: [email-masked]
Date: Thu, 17 Jan 2002 14:12:47 +0100

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 <[email-masked]> on 17/01/2002 14:06:11

  To:          "'Georgios Karagiannis (ELN)'"                 
               <[email-masked]>         
                                                              
  cc:          [email-masked](bcc: Sven VAN DEN                
               BOSCH/BE/ALCATEL)                              

  Subject      RE: [NSIS] Two kinds of requirements           
  :                                                           

Hi,

Yaron
 .

-----Original Message-----

Hi Yaron

Best Regards,
Georgios

-----Original Message-----
From: Yaron Kahana [mailto:[email-masked]]
Sent: donderdag 17 januari 2002 13:47
To: 'Georgios Karagiannis (ELN)'
Cc: [email-masked]
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-----

Hi Yaron

Best Regards,
Georgios

-----Original Message-----
From: Yaro mailto:[email-masked] <mailto:[email-masked]> ]
Sent: donderdag 17 januari 2002 12:09
To: 'Georgios Karagiannis (ELN)'; Geib, Ruediger; 'Freytsis, Ilya'
Cc: [email-masked]
Subject: RE: [NSIS] Two kinds of requirements

Hi,

Yaron

-----Original Message-----

Hi Yaron, Ilya, Ruediger

also
(NSIS protocol components) and define a minimum set of mandatory
reservation

Best Regards,
Georgios

-----Original Message-----

Hello Ruediger, Marcus,

Yaron Kahana
COGITO Project Manager,
COMGATES

 -----Original Message-----

Ruediger,

Marcus

>> I think that what is needed is a new protocol that can signal the

(See attached file: att1.htm)

---

From: "Loughney John (NRC/Helsinki)" <[email-masked]>
Date: Thu, 17 Jan 2002 15:14:37 +0200

Hi Georgios,

> 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

---

From: Yaron Kahana <[email-masked]>
Date: Thu, 17 Jan 2002 15:26:27 +0200

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

 -----Original Message-----
From: 	[email-masked] [mailto:[email-masked]]

Sent:	Thursday, January 17, 2002 3:13 PM
To:	Yaron Kahana
Cc:	'Georgios Karagiannis (ELN)'; [email-masked]
Subject:	RE: [NSIS] Two kinds of requirements

 << File: att1.htm >> Hi,

Sven.

                                                              

                                                              

Hi,

Yaron
 .

-----Original Message-----

Hi Yaron

Best Regards,
Georgios

-----Original Message-----
From: Yaron Kahana [mailto:[email-masked]]
Sent: donderdag 17 januari 2002 13:47
To: 'Georgios Karagiannis (ELN)'
Cc: [email-masked]
Subject: RE: [NSIS] Two kinds of requirements

Hi Georgios,

Best Regards
Yaron

-----Original Message-----

Hi Yaron

Best Regards,
Georgios

-----Original Message-----
From: Yaro mailto:[email-masked] <mailto:[email-masked]> ]
Sent: donderdag 17 januari 2002 12:09
To: 'Georgios Karagiannis (ELN)'; Geib, Ruediger; 'Freytsis, Ilya'
Cc: [email-masked]
Subject: RE: [NSIS] Two kinds of requirements

Hi,

Yaron

-----Original Message-----

Hi Yaron, Ilya, Ruediger

Best Regards,
Georgios

-----Original Message-----

Hello Ruediger, Marcus,

Yaron Kahana
COGITO Project Manager,
COMGATES

 -----Original Message-----

Ruediger,

Marcus

---

From: "Roy, Radhika R, ALASO" <[email-masked]>
Date: Thu, 17 Jan 2002 09:29:31 -0500

Inputs are inline [RRR]

-----Original Message-----
From: Loughney John (NRC/Helsinki) [mailto:[email-masked]]
Sent: Thursday, January 17, 2002 6:27 AM
To: 'ext Georgios Karagiannis (ELN)'
Cc: [email-masked]
Subject: RE: [NSIS] Two kinds of requirements

Hi Georgios,

[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

---

From: "Roy, Radhika R, ALASO" <[email-masked]>
Date: Thu, 17 Jan 2002 09:32:58 -0500

Inputs inline [RRR]

-----Original Message-----
From: Loughney John (NRC/Helsinki) [mailto:[email-masked]]
Sent: Thursday, January 17, 2002 1:35 AM
To: Roy, Radhika R, ALASO
Cc: [email-masked]
Subject: RE: [NSIS] Two kinds of requirements

Hi Radhika,

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

best regards,
John

---

From: "Roy, Radhika R, ALASO" <[email-masked]>
Date: Thu, 17 Jan 2002 09:47:28 -0500

Comments inline [RRR]

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]
Sent: Thursday, January 17, 2002 8:13 AM
To: Yaron Kahana
Cc: 'Georgios Karagiannis (ELN)'; [email-masked]
Subject: RE: [NSIS] Two kinds of requirements

Hi,

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

---

From: "Chen, Weijing" <[email-masked]>
Date: Thu, 17 Jan 2002 08:53:30 -0600

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
[email-masked]

 -----Original Message-----
From: 	Georgios Karagiannis (ELN)
[mailto:[email-masked]] 
Sent:	Thursday, January 17, 2002 3:39 AM
To:	[email-masked]'
Cc:	[email-masked]
Subject:	RE: [NSIS] Two kinds of requirements

Hi Dick 

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.

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

Best Regards,
Georgios

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: woensdag 16 januari 2002 13:00
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [NSIS] Two kinds of requirements

Dick Knight

-----Original Message-----
From: Brian Williams [mailto:[email-masked]]
Sent: 22 December 2001 23:57
To: [email-masked]
Cc: [email-masked]
Subject: Re: [NSIS] Two kinds of requirements

Hi.

---

From: "Georgios Karagiannis (ELN)" <[email-masked]>
Date: Thu, 17 Jan 2002 16:26:49 +0100

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:[email-masked]]
Sent: donderdag 17 januari 2002 15:54
To: 'Georgios Karagiannis (ELN)'
Cc: [email-masked]
Subject: RE: [NSIS] Two kinds of requirements

Georgois,

--
Weijing Chen
SBC Technology Resources
9505 Arboretum Blvd.
Austin, TX 78759
512 372 5710
[email-masked]

 -----Original Message-----

Hi Dick 

|---------|
|---------|

Best Regards,
Georgios

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: woensdag 16 januari 2002 13:00
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [NSIS] Two kinds of requirements

Dick Knight

-----Original Message-----
From: Brian Williams [mailto:[email-masked]]
Sent: 22 December 2001 23:57
To: [email-masked]
Cc: [email-masked]
Subject: Re: [NSIS] Two kinds of requirements

Hi.

---

From: "Chen, Weijing" <[email-masked]>
Date: Thu, 17 Jan 2002 09:51:43 -0600

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
[email-masked]

 -----Original Message-----
From: 	Georgios Karagiannis (ELN)
[mailto:[email-masked]] 
Sent:	Thursday, January 17, 2002 9:27 AM
To:	Chen, Weijing
Cc:	[email-masked]
Subject:	RE: [NSIS] Two kinds of requirements

Hi Weijing

Best Regards,
Georgios

-----Original Message-----
From: Chen, Weijing [mailto:[email-masked]]
Sent: donderdag 17 januari 2002 15:54
To: 'Georgios Karagiannis (ELN)'
Cc: [email-masked]
Subject: RE: [NSIS] Two kinds of requirements

Georgois,

--
Weijing Chen
SBC Technology Resources
9505 Arboretum Blvd.
Austin, TX 78759
512 372 5710
[email-masked]

 -----Original Message-----

Hi Dick 

|---------|
|---------|

Best Regards,
Georgios

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: woensdag 16 januari 2002 13:00
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [NSIS] Two kinds of requirements

Dick Knight

-----Original Message-----
From: Brian Williams [mailto:[email-masked]]
Sent: 22 December 2001 23:57
To: [email-masked]
Cc: [email-masked]
Subject: Re: [NSIS] Two kinds of requirements

Hi.

---

From: "Georgios Karagiannis (ELN)" <[email-masked]>
Date: Thu, 17 Jan 2002 17:25:18 +0100

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:[email-masked]]
Sent: donderdag 17 januari 2002 16:52
To: 'Georgios Karagiannis (ELN)'
Cc: [email-masked]
Subject: RE: [NSIS] Two kinds of requirements

Georgios,

--
Weijing Chen
SBC Technology Resources
9505 Arboretum Blvd.
Austin, TX 78759
512 372 5710
[email-masked]

 -----Original Message-----

Hi Weijing

Best Regards,
Georgios

-----Original Message-----
From: Chen, Weijing [mailto:[email-masked]]
Sent: donderdag 17 januari 2002 15:54
To: 'Georgios Karagiannis (ELN)'
Cc: [email-masked]
Subject: RE: [NSIS] Two kinds of requirements

Georgois,

--
Weijing Chen
SBC Technology Resources
9505 Arboretum Blvd.
Austin, TX 78759
512 372 5710
[email-masked]

 -----Original Message-----

Hi Dick 

|---------|
|---------|

Best Regards,
Georgios

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: woensdag 16 januari 2002 13:00
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [NSIS] Two kinds of requirements

Dick Knight

-----Original Message-----
From: Brian Williams [mailto:[email-masked]]
Sent: 22 December 2001 23:57
To: [email-masked]
Cc: [email-masked]
Subject: Re: [NSIS] Two kinds of requirements

Hi.

---

From: "Georgios Karagiannis (ELN)" <[email-masked]>
Date: Thu, 17 Jan 2002 17:45:08 +0100

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:[email-masked]]
Sent: donderdag 17 januari 2002 17:20
To: Chen, Weijing; Georgios Karagiannis (ELN)
Cc: [email-masked]
Subject: RE: [NSIS] Two kinds of requirements

Inputs are inline [RRR]

-----Original Message-----
From: Chen, Weijing [mailto:[email-masked]]
Sent: Thursday, January 17, 2002 10:52 AM
To: 'Georgios Karagiannis (ELN)'
Cc: [email-masked]
Subject: RE: [NSIS] Two kinds of requirements

Georgios,

[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
[email-masked]

---

From: "Gary Kenward"<[email-masked]>
Date: Thu, 17 Jan 2002 13:11:24 -0500

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

> Sent: January 17, 2002 06:16
> To: [email-masked]; Yaron Kahana; Geib, Ruediger;
> [email-masked]
> Cc: [email-masked]
> Hi all,
> > 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
>

---

From: "Gary Kenward"<[email-masked]>
Date: Thu, 17 Jan 2002 13:13:29 -0500

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

> Sent: January 17, 2002 06:25

---

From: "Gary Kenward"<[email-masked]>
Date: Thu, 17 Jan 2002 13:35:11 -0500

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.

> Sent: January 17, 2002 08:15
> To: 'ext Georgios Karagiannis (ELN)'; 'ext Kappler Cornelia'
> Cc: nsis

---

From: Scott Bradner <[email-masked]>
Date: Thu, 17 Jan 2002 13:41:43 -0500 (EST)

> 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

---

From: "Gary Kenward"<[email-masked]>
Date: Thu, 17 Jan 2002 13:45:25 -0500

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.

> Sent: January 17, 2002 10:52
> signaling toolkit
> independent of
> mechanisms deployed
> QoS mechanism

---

From: "Gary Kenward"<[email-masked]>
Date: Thu, 17 Jan 2002 13:54:15 -0500

Roy:

 I think we agree. 

Gary

> Sent: January 17, 2002 13:37
> To: Kenward, Gary [WDLN2:AN10:EXCH]; Loughney John (NRC/Helsinki);
> [email-masked]; Yaron Kahana; Geib, Ruediger;
> [email-masked]
> Cc: [email-masked]
>         Inputs are inline [Roy, Radhika R, ALARC] .
> 
> From: Gary Kenward [mailto:[email-masked]]
> Sent: Thursday, January 17, 2002 1:11 PM
> To: 'Loughney John (NRC/Helsinki)'; [email-masked]; 
> Yaron Kahana; Geib, Ruediger; [email-masked]
> Cc: [email-masked]
> [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 
> [Roy, Radhika R, ALARC] I agree these areas may be left at 
> the will of the operators and, no standardization may be required.
> 
> 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, 
> [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 
> 
>

---

From: "Roy, Radhika R, ALASO" <[email-masked]>
Date: Thu, 17 Jan 2002 13:37:10 -0500

-----Original Message-----
From: Gary Kenward [mailto:[email-masked]]
Sent: Thursday, January 17, 2002 1:11 PM
To: 'Loughney John (NRC/Helsinki)'; [email-masked]; Yaron Kahana; Geib, Ruediger; [email-masked]
Cc: [email-masked]
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

---

From: Hermann De Meer <[email-masked]>
Date: Thu, 17 Jan 2002 19:49:13 +0000

Hi Georgios and all

>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

---

From: "Schneider, Marco" <[email-masked]>
Date: Thu, 17 Jan 2002 19:17:13 -0600

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: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, January 16, 2002 6:00 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [NSIS] Two kinds of requirements

Dick Knight

-----Original Message-----
From: Brian Williams [mailto:[email-masked]]
Sent: 22 December 2001 23:57
To: [email-masked]
Cc: [email-masked]
Subject: Re: [NSIS] Two kinds of requirements

Hi.

---

From: "Schneider, Marco" <[email-masked]>
Date: Thu, 17 Jan 2002 19:46:52 -0600

Hi Roy,

Can you please define what you mean by "End-to-End Application Layer QOS
Signaling". Thanks.

Marco Schneider

-----Original Message-----
From: Gary Kenward [mailto:[email-masked]]
Sent: Thursday, January 17, 2002 1:11 PM
To: 'Loughney John (NRC/Helsinki)'; [email-masked]; Yaron Kahana;
Geib, Ruediger; [email-masked]
Cc: [email-masked]
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.

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

---

From: "Schneider, Marco" <[email-masked]>
Date: Thu, 17 Jan 2002 19:43:56 -0600

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

Hi Dick 

|---------|
|---------|

Best Regards,
Georgios

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: woensdag 16 januari 2002 13:00
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [NSIS] Two kinds of requirements

Dick Knight

-----Original Message-----
From: Brian Williams [mailto:[email-masked]]
Sent: 22 December 2001 23:57
To: [email-masked]
Cc: [email-masked]
Subject: Re: [NSIS] Two kinds of requirements

Hi.

---

From: "Loughney John (NRC/Helsinki)" <[email-masked]>
Date: Fri, 18 Jan 2002 09:04:38 +0200

Hi Gary,

denotatively 
> a contradiction, it is a common approach. In IETF parlance, this would
be a 

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

---

From: "Loughney John (NRC/Helsinki)" <[email-masked]>
Date: Fri, 18 Jan 2002 09:10:23 +0200

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

---

From: "Loughney John (NRC/Helsinki)" <[email-masked]>
Date: Fri, 18 Jan 2002 09:08:26 +0200

Hi All,

> 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

---

From: [email-masked]
Date: Fri, 18 Jan 2002 11:26:15 -0000

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:[email-masked]]
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,

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 

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

best regards,
John

---

From: [email-masked]
Date: Fri, 18 Jan 2002 11:29:08 -0000

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-----
Sent: 17 January 2002 09:39

Hi Dick 

|---------|
|---------|

Best Regards,
Georgios

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: woensdag 16 januari 2002 13:00
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [NSIS] Two kinds of requirements

Dick Knight

-----Original Message-----
From: Brian Williams [mailto:[email-masked]]
Sent: 22 December 2001 23:57
To: [email-masked]
Cc: [email-masked]
Subject: Re: [NSIS] Two kinds of requirements

Hi.

---

From: [email-masked]
Date: Fri, 18 Jan 2002 11:30:28 -0000

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:[email-masked]]
Sent: 17 January 2002 06:35
To: ext Roy, Radhika R, ALASO
Cc: nsis
Subject: RE: [NSIS] Two kinds of requirements

Hi Radhika,

best regards,
John

---

From: [email-masked]
Date: Fri, 18 Jan 2002 11:45:07 -0000

I love the comparison with DTMF. I have inserted some comments (marked [dk])

-----Original Message-----
From: Chen, Weijing [mailto:[email-masked]]
Sent: 17 January 2002 04:20
To: 'Roy, Radhika R, ALASO'; Steven Berson
Cc: Michael Thomas; [email-masked];

Roy, Dick, etc

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? 

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
[email-masked]

-----Original Message-----
From: Steven Berson [mailto:[email-masked]]
Sent: Wednesday, January 16, 2002 2:08 PM
To: Roy, Radhika R, ALASO
Cc: Michael Thomas; [email-masked];

Regards,
Steve

---

From: "Loughney John (NRC/Helsinki)" <[email-masked]>
Date: Fri, 18 Jan 2002 14:19:20 +0200

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

---

From: "Georgios Karagiannis (ELN)" <[email-masked]>
Date: Fri, 18 Jan 2002 13:27:44 +0100

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

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: [email-masked] [mailto:[email-masked]]
Sent: vrijdag 18 januari 2002 12:29
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [NSIS] Two kinds of requirements

Dick
-----Original Message-----

Hi Dick 

|---------|
|---------|

Best Regards,
Georgios

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: woensdag 16 januari 2002 13:00
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [NSIS] Two kinds of requirements

Dick Knight

-----Original Message-----
From: Brian Williams [mailto:[email-masked]]
Sent: 22 December 2001 23:57
To: [email-masked]
Cc: [email-masked]
Subject: Re: [NSIS] Two kinds of requirements

Hi.

---

From: [email-masked]
Date: Fri, 18 Jan 2002 12:21:05 -0000

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:[email-masked]]
Sent: 16 January 2002 16:45
To: 'ext Roy, Radhika R, ALASO'
Cc: nsis
Subject: RE: [NSIS] Two kinds of requirements

Hi Radhika:

--------------------------------------snip------------------------------
-----------------

Hemant

---

From: "Loughney John (NRC/Helsinki)" <[email-masked]>
Date: Fri, 18 Jan 2002 14:39:58 +0200

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

---

From: "Chaskar Hemant (NRC/Boston)" <[email-masked]>
Date: Fri, 18 Jan 2002 08:10:22 -0500

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

---

From: [email-masked]
Date: Fri, 18 Jan 2002 13:24:07 -0000

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:[email-masked]]
Sent: 18 January 2002 13:10
To: ext Roy, Radhika R, ALASO
Cc: nsis
Subject: RE: [NSIS] Two kinds of requirements

Hi:

-------------------------------excerpt--------------------------------- 

Hemant

---

From: "Chaskar Hemant (NRC/Boston)" <[email-masked]>
Date: Fri, 18 Jan 2002 08:42:18 -0500

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 [email-masked] [mailto:[email-masked]]
Sent: Friday, January 18, 2002 6:29 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [NSIS] Two kinds of requirements

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

Hi Dick 

[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

|---------|
|---------|
|everyhost|<------------------------------------------------------->|eve
ryho
st|
|---------|
|---------|
|         |                                                         |
|
|---------|   |---------|                             |---------|
|---------|
|everyedge|<->|everyedge|<--------------------------->|everyedge|<->|eve
ryed
ge|
|---------|   |---------|                             |---------|
|---------|
|         |   |         |                             |         |   |
|
|---------|   |---------|   |--------|   |--------|   |---------|
|---------|
|everyhop |<->|everyhop |<->|everyhop|<->|everyhop|<->|everyhop
|<->|everyhop |
|---------|   |---------|   |--------|   |--------|   |---------|
|---------| 
    host          edge        interior    interior       edge
host

 *  edge: can be a Diffserv edge, MPLS edge, etc., and it can process
and
use 
    the "everyedge", and "everyhop" protocol components. The "everyhost"

 *  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: [email-masked] [mailto:[email-masked]]
Sent: woensdag 16 januari 2002 13:00
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [NSIS] Two kinds of 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:[email-masked]]
Sent: 22 December 2001 23:57
To: [email-masked]
Cc: [email-masked]
Subject: Re: [NSIS] Two kinds of requirements

Hi.

---

From: "Roy, Radhika R, ALASO" <[email-masked]>
Date: Fri, 18 Jan 2002 09:19:24 -0500

Hi, John:

I agree with you. 

Thanks,
Radhika

-----Original Message-----
From: Loughney John (NRC/Helsinki) [mailto:[email-masked]]
Sent: Friday, January 18, 2002 7:40 AM
To: Roy, Radhika R, ALASO; Chen, Weijing; Georgios Karagiannis (ELN)
Cc: [email-masked]
Subject: RE: [NSIS] Two kinds of requirements

Hi Radhika,

 

John

---

From: "Roy, Radhika R, ALASO" <[email-masked]>
Date: Fri, 18 Jan 2002 09:51:51 -0500

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
[email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, January 18, 2002 7:21 AM
To: [email-masked]; Roy, Radhika R, ALASO
Cc: [email-masked]
Subject: RE: [NSIS] Two kinds of requirements

Dick

-----Original Message-----
From: Chaskar Hemant (NRC/Boston) [mailto:[email-masked]]
Sent: 16 January 2002 16:45
To: 'ext Roy, Radhika R, ALASO'
Cc: nsis
Subject: RE: [NSIS] Two kinds of requirements

Hi Radhika:

--------------------------------------snip------------------------------
-----------------

Hemant

---

From: "Roy, Radhika R, ALASO" <[email-masked]>
Date: Fri, 18 Jan 2002 09:52:16 -0500

Inputs inline [RRR].

-----Original Message-----
From: Chaskar Hemant (NRC/Boston) [mailto:[email-masked]]
Sent: Friday, January 18, 2002 8:10 AM
To: Roy, Radhika R, ALASO
Cc: [email-masked]
Subject: RE: [NSIS] Two kinds of requirements

Hi:

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

Hemant

---

From: "Roy, Radhika R, ALASO" <[email-masked]>
Date: Fri, 18 Jan 2002 10:18:04 -0500

Defined below [RRR]

-----Original Message-----
From: Schneider, Marco [mailto:[email-masked]]
Sent: Thursday, January 17, 2002 8:47 PM
To: Roy, Radhika R, ALASO; Gary Kenward; Loughney John (NRC/Helsinki);

Hi Roy,

[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

---

From: "Chen, Weijing" <[email-masked]>
Date: Fri, 18 Jan 2002 09:45:40 -0600

--
Weijing Chen
SBC Technology Resources
9505 Arboretum Blvd.
Austin, TX 78759
512 372 5710
[email-masked]

-----Original Message-----
From: Chen, Weijing [mailto:[email-masked]]
Sent: 17 January 2002 04:20
To: 'Roy, Radhika R, ALASO'; Steven Berson
Cc: Michael Thomas; [email-masked];

Roy, Dick, etc

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

[wj] The interworking among different networks is needed but it can be
treated as customer-to-network with customer-to-network solution.

--
Weijing Chen
SBC Technology Resources
9505 Arboretum Blvd.
Austin, TX 78759
512 372 5710
[email-masked]

-----Original Message-----
From: Steven Berson [mailto:[email-masked]]
Sent: Wednesday, January 16, 2002 2:08 PM
To: Roy, Radhika R, ALASO
Cc: Michael Thomas; [email-masked];

Regards,
Steve

---

From: "Chen, Weijing" <[email-masked]>
Date: Fri, 18 Jan 2002 09:49:46 -0600

Yes, yes! This is what we must do first.

* [RRR] Host will only express its needs 
* [wj] >> to network >> to satisfy the 
> can express its needs. [wj] >> to edge of the network.

--
Weijing Chen
SBC Technology Resources
9505 Arboretum Blvd.
Austin, TX 78759
512 372 5710
[email-masked]

 -----Original Message-----
From: 	Roy, Radhika R, ALASO [mailto:[email-masked]] 
Sent:	Friday, January 18, 2002 8:19 AM
To:	Loughney John (NRC/Helsinki); Chen, Weijing; Georgios Karagiannis
(ELN)
Cc:	[email-masked]

Hi, John:

I agree with you. 

Thanks,
Radhika

-----Original Message-----
From: Loughney John (NRC/Helsinki) [mailto:[email-masked]]
Sent: Friday, January 18, 2002 7:40 AM
To: Roy, Radhika R, ALASO; Chen, Weijing; Georgios Karagiannis (ELN)
Cc: [email-masked]
Subject: RE: [NSIS] Two kinds of requirements

Hi Radhika,

 

John

---

From: [email-masked]
Date: Fri, 18 Jan 2002 16:42:38 -0000

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:[email-masked]]
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
[email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, January 18, 2002 7:21 AM
To: [email-masked]; Roy, Radhika R, ALASO
Cc: [email-masked]
Subject: RE: [NSIS] Two kinds of requirements

Dick

-----Original Message-----
From: Chaskar Hemant (NRC/Boston) [mailto:[email-masked]]
Sent: 16 January 2002 16:45
To: 'ext Roy, Radhika R, ALASO'
Cc: nsis
Subject: RE: [NSIS] Two kinds of requirements

Hi Radhika:

--------------------------------------snip------------------------------
-----------------

Hemant

---

From: "Schneider, Marco" <[email-masked]>
Date: Fri, 18 Jan 2002 14:09:30 -0600

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:[email-masked]]
Sent: Friday, January 18, 2002 9:18 AM
To: Schneider, Marco; Gary Kenward; Loughney John (NRC/Helsinki);

Defined below [RRR]

-----Original Message-----
From: Schneider, Marco [mailto:[email-masked]]
Sent: Thursday, January 17, 2002 8:47 PM
To: Roy, Radhika R, ALASO; Gary Kenward; Loughney John (NRC/Helsinki);

Hi Roy,

[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

---

From: [email-masked]
Date: Mon, 21 Jan 2002 10:10:00 -0000

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:[email-masked]]
Sent: 18 January 2002 20:10
To: 'Roy, Radhika R, ALASO'; Gary Kenward; Loughney John (NRC/Helsinki);

Hi Roy,

Marco Schneider

-----Original Message-----
From: Roy, Radhika R, ALASO [mailto:[email-masked]]
Sent: Friday, January 18, 2002 9:18 AM
To: Schneider, Marco; Gary Kenward; Loughney John (NRC/Helsinki);

Defined below [RRR]

-----Original Message-----
From: Schneider, Marco [mailto:[email-masked]]
Sent: Thursday, January 17, 2002 8:47 PM
To: Roy, Radhika R, ALASO; Gary Kenward; Loughney John (NRC/Helsinki);

Hi Roy,

Marco Schneider

---

From: "Georgios Karagiannis (ELN)" <[email-masked]>
Date: Mon, 21 Jan 2002 11:29:38 +0100

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:[email-masked]]
Sent: 18 January 2002 20:10
To: 'Roy, Radhika R, ALASO'; Gary Kenward; Loughney John (NRC/Helsinki);

Hi Roy,

Marco Schneider

-----Original Message-----
From: Roy, Radhika R, ALASO [mailto:[email-masked]]
Sent: Friday, January 18, 2002 9:18 AM
To: Schneider, Marco; Gary Kenward; Loughney John (NRC/Helsinki);

Defined below [RRR]

-----Original Message-----
From: Schneider, Marco [mailto:[email-masked]]
Sent: Thursday, January 17, 2002 8:47 PM
To: Roy, Radhika R, ALASO; Gary Kenward; Loughney John (NRC/Helsinki);

Hi Roy,

Marco Schneider

---

From: [email-masked]
Date: Mon, 21 Jan 2002 10:49:14 -0000

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-----
Sent: 21 January 2002 10:30

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.

edge - edge: the NSIS protocol is terminated at egdes of one/multiple
domains;

Best regards,
Georgios

-----Original Message-----
From: Schneider, Marco [mailto:[email-masked]]
Sent: 18 January 2002 20:10
To: 'Roy, Radhika R, ALASO'; Gary Kenward; Loughney John (NRC/Helsinki);

Hi Roy,

Marco Schneider

-----Original Message-----
From: Roy, Radhika R, ALASO [mailto:[email-masked]]
Sent: Friday, January 18, 2002 9:18 AM
To: Schneider, Marco; Gary Kenward; Loughney John (NRC/Helsinki);

Defined below [RRR]

-----Original Message-----
From: Schneider, Marco [mailto:[email-masked]]
Sent: Thursday, January 17, 2002 8:47 PM
To: Roy, Radhika R, ALASO; Gary Kenward; Loughney John (NRC/Helsinki);

Hi Roy,

Marco Schneider

---

From: "Georgios Karagiannis (ELN)" <[email-masked]>
Date: Mon, 21 Jan 2002 12:12:40 +0100

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: [email-masked] [mailto:[email-masked]]
Sent: maandag 21 januari 2002 11:49
To: [email-masked]
Cc: [email-masked]
Subject: RE: [NSIS] Two kinds of requirements

Interesting. I agree.

Dick

-----Original Message-----

Hi Dick

Best regards,
Georgios

-----Original Message-----
From: Schneider, Marco [mailto:[email-masked]]
Sent: 18 January 2002 20:10
To: 'Roy, Radhika R, ALASO'; Gary Kenward; Loughney John (NRC/Helsinki);

Hi Roy,

Marco Schneider

-----Original Message-----
From: Roy, Radhika R, ALASO [mailto:[email-masked]]
Sent: Friday, January 18, 2002 9:18 AM
To: Schneider, Marco; Gary Kenward; Loughney John (NRC/Helsinki);

Defined below [RRR]

-----Original Message-----
From: Schneider, Marco [mailto:[email-masked]]
Sent: Thursday, January 17, 2002 8:47 PM
To: Roy, Radhika R, ALASO; Gary Kenward; Loughney John (NRC/Helsinki);

Hi Roy,

Marco Schneider

---

From: "Gary Kenward"<[email-masked]>
Date: Mon, 21 Jan 2002 09:52:55 -0500

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

> Sent: January 18, 2002 15:10
> To: 'Roy, Radhika R, ALASO'; Kenward, Gary [WDLN2:AN10:EXCH]; Loughney
> John (NRC/Helsinki); [email-masked]; Yaron Kahana; 
> Geib, Ruediger;
> [email-masked]
> Cc: [email-masked]
> will be mapped

---

From: "Chen, Weijing" <[email-masked]>
Date: Mon, 21 Jan 2002 09:49:06 -0600

-----Original Message-----
From: Gary Kenward [mailto:[email-masked]]
Sent: Monday, January 21, 2002 8:53 AM
To: Schneider, Marco; 'Roy, Radhika R, ALASO'; Loughney John (NRC/Helsinki);
[email-masked]; Yaron Kahana; Geib, Ruediger; [email-masked]
Cc: [email-masked]
Subject: RE: [NSIS] Two kinds of requirements

Marco: 

[Chen, Weijing]  Yes, that is the case.

  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.

capability? 

Gary Kenward 

> From: Schneider, Marco [ mailto:[email-masked]
<mailto:[email-masked]> ] 
> From: Roy, Radhika R, ALASO [ mailto:[email-masked] <mailto:[email-masked]>
] 
> From: Schneider, Marco [ mailto:[email-masked]
<mailto:[email-masked]> ]

---

From: "Chen, Weijing" <[email-masked]>
Date: Mon, 21 Jan 2002 10:03:44 -0600

See the comments in [wj].

--
Weijing Chen
SBC Technology Resources
9505 Arboretum Blvd.
Austin, TX 78759
512 372 5710
[email-masked]

 -----Original Message-----
From: 	[email-masked] [mailto:[email-masked]] 
Sent:	Monday, January 21, 2002 4:10 AM
To:	Schneider, Marco; [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]
Cc:	[email-masked]
Subject:	RE: [NSIS] Two kinds of requirements

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

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

Dick

-----Original Message-----
From: Schneider, Marco [mailto:[email-masked]]
Sent: 18 January 2002 20:10
To: 'Roy, Radhika R, ALASO'; Gary Kenward; Loughney John (NRC/Helsinki);

Hi Roy,

Marco Schneider

-----Original Message-----
From: Roy, Radhika R, ALASO [mailto:[email-masked]]
Sent: Friday, January 18, 2002 9:18 AM
To: Schneider, Marco; Gary Kenward; Loughney John (NRC/Helsinki);

Defined below [RRR]

-----Original Message-----
From: Schneider, Marco [mailto:[email-masked]]
Sent: Thursday, January 17, 2002 8:47 PM
To: Roy, Radhika R, ALASO; Gary Kenward; Loughney John (NRC/Helsinki);

Hi Roy,

Marco Schneider

---

From: "Chen, Weijing" <[email-masked]>
Date: Mon, 21 Jan 2002 10:20:19 -0600

I am afraid that we are creating a Utopian solution here.

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

>>end host - edge: the NSIS protocol is terminated at end end host and edge;
This should be our focus now.

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
[email-masked]

-----Original Message-----
Sent:	Monday, January 21, 2002 4:30 AM

Hi Dick

Best regards,
Georgios

-----Original Message-----
From: Schneider, Marco [mailto:[email-masked]]
Sent: 18 January 2002 20:10
To: 'Roy, Radhika R, ALASO'; Gary Kenward; Loughney John (NRC/Helsinki);

Hi Roy,

Marco Schneider

-----Original Message-----
From: Roy, Radhika R, ALASO [mailto:[email-masked]]
Sent: Friday, January 18, 2002 9:18 AM
To: Schneider, Marco; Gary Kenward; Loughney John (NRC/Helsinki);

Defined below [RRR]

-----Original Message-----
From: Schneider, Marco [mailto:[email-masked]]
Sent: Thursday, January 17, 2002 8:47 PM
To: Roy, Radhika R, ALASO; Gary Kenward; Loughney John (NRC/Helsinki);

Hi Roy,

Marco Schneider

---

From: [email-masked]
Date: Mon, 21 Jan 2002 17:14:45 -0000

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:[email-masked]]
Sent: 21 January 2002 16:20
To: 'Georgios Karagiannis (ELN)'
Cc: [email-masked]'
Subject: RE: [NSIS] Two kinds of requirements

protocol.

domains;

--
Weijing Chen
SBC Technology Resources
9505 Arboretum Blvd.
Austin, TX 78759
512 372 5710
[email-masked]

-----Original Message-----

Hi Dick

Best regards,
Georgios

-----Original Message-----
From: Schneider, Marco [mailto:[email-masked]]
Sent: 18 January 2002 20:10
To: 'Roy, Radhika R, ALASO'; Gary Kenward; Loughney John (NRC/Helsinki);

Hi Roy,

Marco Schneider

-----Original Message-----
From: Roy, Radhika R, ALASO [mailto:[email-masked]]
Sent: Friday, January 18, 2002 9:18 AM
To: Schneider, Marco; Gary Kenward; Loughney John (NRC/Helsinki);

Defined below [RRR]

-----Original Message-----
From: Schneider, Marco [mailto:[email-masked]]
Sent: Thursday, January 17, 2002 8:47 PM
To: Roy, Radhika R, ALASO; Gary Kenward; Loughney John (NRC/Helsinki);

Hi Roy,

Marco Schneider

---

From: "Allen, Keith" <[email-masked]>
Date: Mon, 21 Jan 2002 11:37:03 -0600

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
[email-masked]

 -----Original Message-----
From: 	[email-masked] [mailto:[email-masked]] 
Sent:	Monday, January 21, 2002 11:15 AM
To:	Chen, Weijing; [email-masked]
Cc:	[email-masked]
Subject:	RE: [NSIS] Two kinds of requirements

Weijing,

Dick

-----Original Message-----
From: Chen, Weijing [mailto:[email-masked]]
Sent: 21 January 2002 16:20
To: 'Georgios Karagiannis (ELN)'
Cc: [email-masked]'
Subject: RE: [NSIS] Two kinds of requirements

protocol.

domains;

--
Weijing Chen
SBC Technology Resources
9505 Arboretum Blvd.
Austin, TX 78759
512 372 5710
[email-masked]

-----Original Message-----

Hi Dick

Best regards,
Georgios

-----Original Message-----
From: Schneider, Marco [mailto:[email-masked]]
Sent: 18 January 2002 20:10
To: 'Roy, Radhika R, ALASO'; Gary Kenward; Loughney John (NRC/Helsinki);

Hi Roy,

Marco Schneider

-----Original Message-----
From: Roy, Radhika R, ALASO [mailto:[email-masked]]
Sent: Friday, January 18, 2002 9:18 AM
To: Schneider, Marco; Gary Kenward; Loughney John (NRC/Helsinki);

Defined below [RRR]

-----Original Message-----
From: Schneider, Marco [mailto:[email-masked]]
Sent: Thursday, January 17, 2002 8:47 PM
To: Roy, Radhika R, ALASO; Gary Kenward; Loughney John (NRC/Helsinki);

Hi Roy,

Marco Schneider

---

From: "Roy, Radhika R, ALASO" <[email-masked]>
Date: Mon, 21 Jan 2002 12:39:18 -0500

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: [email-masked] [mailto:[email-masked]]
Sent: Monday, January 21, 2002 5:10 AM
To: [email-masked]; Roy, Radhika R, ALASO;
[email-masked]; [email-masked];
[email-masked]; [email-masked];
[email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [NSIS] Two kinds of requirements

Dick

-----Original Message-----
From: Schneider, Marco [mailto:[email-masked]]
Sent: 18 January 2002 20:10
To: 'Roy, Radhika R, ALASO'; Gary Kenward; Loughney John (NRC/Helsinki);

Hi Roy,

Marco Schneider

-----Original Message-----
From: Roy, Radhika R, ALASO [mailto:[email-masked]]
Sent: Friday, January 18, 2002 9:18 AM
To: Schneider, Marco; Gary Kenward; Loughney John (NRC/Helsinki);

Defined below [RRR]

-----Original Message-----
From: Schneider, Marco [mailto:[email-masked]]
Sent: Thursday, January 17, 2002 8:47 PM
To: Roy, Radhika R, ALASO; Gary Kenward; Loughney John (NRC/Helsinki);

Hi Roy,

Marco Schneider

---

From: "Chen, Weijing" <[email-masked]>
Date: Mon, 21 Jan 2002 12:00:46 -0600

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
[email-masked]

 -----Original Message-----
From: 	[email-masked] [mailto:[email-masked]] 
Sent:	Monday, January 21, 2002 11:15 AM
To:	Chen, Weijing; [email-masked]
Cc:	[email-masked]
Subject:	RE: [NSIS] Two kinds of requirements

Weijing,

Dick

-----Original Message-----
From: Chen, Weijing [mailto:[email-masked]]
Sent: 21 January 2002 16:20
To: 'Georgios Karagiannis (ELN)'
Cc: [email-masked]'
Subject: RE: [NSIS] Two kinds of requirements

protocol.

domains;

--
Weijing Chen
SBC Technology Resources
9505 Arboretum Blvd.
Austin, TX 78759
512 372 5710
[email-masked]

-----Original Message-----

Hi Dick

Best regards,
Georgios

-----Original Message-----
From: Schneider, Marco [mailto:[email-masked]]
Sent: 18 January 2002 20:10
To: 'Roy, Radhika R, ALASO'; Gary Kenward; Loughney John (NRC/Helsinki);

Hi Roy,

Marco Schneider

-----Original Message-----
From: Roy, Radhika R, ALASO [mailto:[email-masked]]
Sent: Friday, January 18, 2002 9:18 AM
To: Schneider, Marco; Gary Kenward; Loughney John (NRC/Helsinki);

Defined below [RRR]

-----Original Message-----
From: Schneider, Marco [mailto:[email-masked]]
Sent: Thursday, January 17, 2002 8:47 PM
To: Roy, Radhika R, ALASO; Gary Kenward; Loughney John (NRC/Helsinki);

Hi Roy,

Marco Schneider

---

From: "Schneider, Marco" <[email-masked]>
Date: Mon, 21 Jan 2002 17:32:58 -0600

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: [email-masked] [mailto:[email-masked]]
Sent: Monday, January 21, 2002 4:10 AM
To: Schneider, Marco; [email-masked]; [email-masked];

Dick

-----Original Message-----
From: Schneider, Marco [mailto:[email-masked]]
Sent: 18 January 2002 20:10
To: 'Roy, Radhika R, ALASO'; Gary Kenward; Loughney John (NRC/Helsinki);

Hi Roy,

Marco Schneider

-----Original Message-----
From: Roy, Radhika R, ALASO [mailto:[email-masked]]
Sent: Friday, January 18, 2002 9:18 AM
To: Schneider, Marco; Gary Kenward; Loughney John (NRC/Helsinki);

Defined below [RRR]

-----Original Message-----
From: Schneider, Marco [mailto:[email-masked]]
Sent: Thursday, January 17, 2002 8:47 PM
To: Roy, Radhika R, ALASO; Gary Kenward; Loughney John (NRC/Helsinki);

Hi Roy,

Marco Schneider

---

From: "Schneider, Marco" <[email-masked]>
Date: Mon, 21 Jan 2002 18:03:00 -0600

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

Hi Dick

Best regards,
Georgios

-----Original Message-----
From: Schneider, Marco [mailto:[email-masked]]
Sent: 18 January 2002 20:10
To: 'Roy, Radhika R, ALASO'; Gary Kenward; Loughney John (NRC/Helsinki);

Hi Roy,

Marco Schneider

-----Original Message-----
From: Roy, Radhika R, ALASO [mailto:[email-masked]]
Sent: Friday, January 18, 2002 9:18 AM
To: Schneider, Marco; Gary Kenward; Loughney John (NRC/Helsinki);

Defined below [RRR]

-----Original Message-----
From: Schneider, Marco [mailto:[email-masked]]
Sent: Thursday, January 17, 2002 8:47 PM
To: Roy, Radhika R, ALASO; Gary Kenward; Loughney John (NRC/Helsinki);

Hi Roy,

Marco Schneider

---

From: "Schneider, Marco" <[email-masked]>
Date: Mon, 21 Jan 2002 19:47:30 -0600

Gary, 
 
Please see my comments preceeded by [MS] below.
 
Marco

-----Original Message-----
From: Gary Kenward [mailto:[email-masked]]
Sent: Monday, January 21, 2002 8:53 AM
To: Schneider, Marco; 'Roy, Radhika R, ALASO'; Loughney John (NRC/Helsinki);

Marco: 

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

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 

]

---

From: "Geib, Ruediger" <[email-masked]>
Date: Tue, 22 Jan 2002 10:04:45 +0100

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.

---

From: [email-masked]
Date: Tue, 22 Jan 2002 12:53:48 +0200

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

---

From: "Allen, Keith" <[email-masked]>
Date: Tue, 22 Jan 2002 08:34:10 -0600

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
[email-masked]

message in error, please notify the sender at (512) 372-5000 and delete this

 -----Original Message-----
From: 	Geib, Ruediger [mailto:[email-masked]] 
Sent:	Tuesday, January 22, 2002 3:05 AM
To:	Allen, Keith
Cc:	[email-masked]
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

---

From: "Gary Kenward"<[email-masked]>
Date: Tue, 22 Jan 2002 10:01:39 -0500

Marco:

-----Original Message-----
> Sent: January 21, 2002 20:48
> To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Roy, Radhika R, ALASO'; Loughney
John > 
> (NRC/Helsinki); [email-masked]; Yaron Kahana; Geib, Ruediger;
[email-masked]

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

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

---

From: [email-masked]
Date: Tue, 22 Jan 2002 16:45:53 -0000

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:[email-masked]]
Sent: 22 January 2002 09:39
To: 'Schneider, Marco'
Cc: [email-masked]
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:[email-masked]]
Sent: dinsdag 22 januari 2002 1:03
To: 'Georgios Karagiannis (ELN)'; [email-masked]'
Cc: [email-masked]
Subject: RE: [NSIS] Two kinds of requirements

Hi Georgios, All

Marco

-----Original Message-----

Hi Dick

Best regards,
Georgios

-----Original Message-----
From: Schneider, Marco [mailto:[email-masked]]
Sent: 18 January 2002 20:10
To: 'Roy, Radhika R, ALASO'; Gary Kenward; Loughney John (NRC/Helsinki);

Hi Roy,

Marco Schneider

-----Original Message-----
From: Roy, Radhika R, ALASO [mailto:[email-masked]]
Sent: Friday, January 18, 2002 9:18 AM
To: Schneider, Marco; Gary Kenward; Loughney John (NRC/Helsinki);

Defined below [RRR]

-----Original Message-----
From: Schneider, Marco [mailto:[email-masked]]
Sent: Thursday, January 17, 2002 8:47 PM
To: Roy, Radhika R, ALASO; Gary Kenward; Loughney John (NRC/Helsinki);

Hi Roy,

Marco Schneider

---

From: "Chen, Weijing" <[email-masked]>
Date: Tue, 22 Jan 2002 10:59:20 -0600

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
[email-masked]

-----Original Message-----
From: Georgios Karagiannis (ELN)
[mailto:[email-masked]] 
Sent: Tuesday, January 22, 2002 3:39 AM
To: Schneider, Marco
Cc: [email-masked]
Subject: RE: [NSIS] Two kinds of requirements

Hi Marco

 

Best regards,
Georgios

-----Original Message-----
From: Schneider, Marco [mailto:[email-masked]]
Sent: dinsdag 22 januari 2002 1:03
To: 'Georgios Karagiannis (ELN)'; [email-masked]'
Cc: [email-masked]
Subject: RE: [NSIS] Two kinds of requirements

Hi Georgios, All

Marco

-----Original Message-----

Hi Dick

Best regards,
Georgios

-----Original Message-----
From: Schneider, Marco [mailto:[email-masked]]
Sent: 18 January 2002 20:10
To: 'Roy, Radhika R, ALASO'; Gary Kenward; Loughney John (NRC/Helsinki);

Hi Roy,

Marco Schneider

-----Original Message-----
From: Roy, Radhika R, ALASO [mailto:[email-masked]]
Sent: Friday, January 18, 2002 9:18 AM
To: Schneider, Marco; Gary Kenward; Loughney John (NRC/Helsinki);

Defined below [RRR]

-----Original Message-----
From: Schneider, Marco [mailto:[email-masked]]
Sent: Thursday, January 17, 2002 8:47 PM
To: Roy, Radhika R, ALASO; Gary Kenward; Loughney John (NRC/Helsinki);

Hi Roy,

Marco Schneider

---

From: "Chen, Weijing" <[email-masked]>
Date: Tue, 22 Jan 2002 11:34:49 -0600

[Chen, Weijing] Excellent statement.

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

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

[Chen, Weijing] Agreed.

--

Weijing Chen

SBC Technology Resources

9505 Arboretum Blvd.

Austin, TX 78759

512 372 5710

 <mailto:[email-masked]> [email-masked]

---

From: "Freytsis, Ilya" <[email-masked]>
Date: Tue, 22 Jan 2002 15:19:54 -0500

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
[email-masked]

From: "Allen, Keith" <[email-masked]>
To: [email-masked]
Subject: RE: [NSIS] Two kinds of requirements
Date: Tue, 22 Jan 2002 08:34:10 -0600
charset="iso-8859-1"

Rüdiger,

Keith Allen
SBC Technology Resources
9505 Arboretum Blvd.
Austin, TX 78759
(512) 372-5741
[email-masked]

 -----Original Message-----
From: 	Geib, Ruediger [mailto:[email-masked]] 
Sent:	Tuesday, January 22, 2002 3:05 AM
To:	Allen, Keith
Cc:	[email-masked]
Subject:	RE: [NSIS] Two kinds of requirements

Allen,

Regards, Rüdiger

---

From: "Schneider, Marco" <[email-masked]>
Date: Tue, 22 Jan 2002 14:34:34 -0600

Gary,

-----Original Message-----
From: Gary Kenward [mailto:[email-masked]]
Sent: Tuesday, January 22, 2002 9:02 AM
To: Schneider, Marco; 'Roy, Radhika R, ALASO'; Loughney John (NRC/Helsinki);

Marco: 

-----Original Message----- 
to the best 
capability that 
forwards a 
RSVP path 
session layer does 

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.

devices in 
"End-to-End 
to user (end- 
(contexts). The way 
(all the 

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. 

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

request (and 
part entails 
a number of 
between domains. If 
preproposed a 

[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

[Schneider, Marco]  
*snip*

---

From: "Schneider, Marco" <[email-masked]>
Date: Tue, 22 Jan 2002 14:43:55 -0600

Ilya,

I agree wholeheartedly with what you say below.

Marco

-----Original Message-----
From: Freytsis, Ilya [mailto:[email-masked]]
Sent: Tuesday, January 22, 2002 2:20 PM
To: [email-masked]'
Subject: RE: [NSIS] Two kinds of requirements

Allen,

Ilya Freytsis
Cetacean Networks Inc.
ph. (603) 766-6065
fax (603) 766-7190
[email-masked]

Rüdiger,

Keith Allen
SBC Technology Resources
9505 Arboretum Blvd.
Austin, TX 78759
(512) 372-5741
[email-masked]

 -----Original Message-----
From: 	Geib, Ruediger [mailto:[email-masked]] 
Sent:	Tuesday, January 22, 2002 3:05 AM
To:	Allen, Keith
Cc:	[email-masked]
Subject:	RE: [NSIS] Two kinds of requirements

Allen,

Regards, Rüdiger

---

From: "Chen, Weijing" <[email-masked]>
Date: Wed, 23 Jan 2002 01:07:19 -0600

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
[email-masked]

-----Original Message-----
From: Freytsis, Ilya [mailto:[email-masked]] 
Sent: Tuesday, January 22, 2002 2:20 PM
To: [email-masked]'
Subject: RE: [NSIS] Two kinds of requirements

Allen,

Ilya Freytsis
Cetacean Networks Inc.
ph. (603) 766-6065
fax (603) 766-7190
[email-masked]

Rüdiger,

Keith Allen
SBC Technology Resources
9505 Arboretum Blvd.
Austin, TX 78759
(512) 372-5741
[email-masked]

 -----Original Message-----
From: 	Geib, Ruediger [mailto:[email-masked]] 
Sent:	Tuesday, January 22, 2002 3:05 AM
To:	Allen, Keith
Cc:	[email-masked]
Subject:	RE: [NSIS] Two kinds of requirements

Allen,

Regards, Rüdiger

---

From: [email-masked]
Date: Wed, 23 Jan 2002 09:33:50 +0200

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

---

From: "Georgios Karagiannis (ELN)" <[email-masked]>
Date: Wed, 23 Jan 2002 12:00:08 +0100

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:[email-masked]]
Sent: dinsdag 22 januari 2002 17:59
To: 'Georgios Karagiannis (ELN)'; Schneider, Marco
Cc: [email-masked]
Subject: RE: [NSIS] Two kinds of requirements

Georgios,

--
Weijing Chen
SBC Technology Resources
9505 Arboretum Blvd.
Austin, TX 78759
512 372 5710
[email-masked]

-----Original Message-----

Hi Marco

 

Best regards,
Georgios

-----Original Message-----
From: Schneider, Marco [mailto:[email-masked]]
Sent: dinsdag 22 januari 2002 1:03
To: 'Georgios Karagiannis (ELN)'; [email-masked]'
Cc: [email-masked]
Subject: RE: [NSIS] Two kinds of requirements

Hi Georgios, All

Marco

-----Original Message-----

Hi Dick

Best regards,
Georgios

-----Original Message-----
From: Schneider, Marco [mailto:[email-masked]]
Sent: 18 January 2002 20:10
To: 'Roy, Radhika R, ALASO'; Gary Kenward; Loughney John (NRC/Helsinki);

Hi Roy,

Marco Schneider

-----Original Message-----
From: Roy, Radhika R, ALASO [mailto:[email-masked]]
Sent: Friday, January 18, 2002 9:18 AM
To: Schneider, Marco; Gary Kenward; Loughney John (NRC/Helsinki);

Defined below [RRR]

-----Original Message-----
From: Schneider, Marco [mailto:[email-masked]]
Sent: Thursday, January 17, 2002 8:47 PM
To: Roy, Radhika R, ALASO; Gary Kenward; Loughney John (NRC/Helsinki);

Hi Roy,

Marco Schneider

---

From: "Gary Kenward"<[email-masked]>
Date: Wed, 23 Jan 2002 10:58:21 -0500

Marco:
 
  Good points. 

-----Original Message-----
From: Schneider, Marco [mailto:[email-masked]]
Sent: January 22, 2002 17:49
To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Roy, Radhika R, ALASO'; Loughney John

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:[email-masked]]
Sent: Tuesday, January 22, 2002 3:34 PM
To: Schneider, Marco; 'Roy, Radhika R, ALASO'; Loughney John (NRC/Helsinki);

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:[email-masked]]
Sent: January 22, 2002 15:35
To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Roy, Radhika R, ALASO'; Loughney John

Gary,

-----Original Message-----
From: Gary Kenward [mailto:[email-masked]]
Sent: Tuesday, January 22, 2002 9:02 AM
To: Schneider, Marco; 'Roy, Radhika R, ALASO'; Loughney John (NRC/Helsinki);

Marco: 

-----Original Message----- 
to the best 
capability that 
forwards a 
RSVP path 
session layer does 

Have I missed something? 

devices in 
"End-to-End 
to user (end- 
(contexts). The way 
(all the 

request (and 
part entails 
a number of 
between domains. If 
preproposed a 

Deludedly yours,

Marco

[Schneider, Marco]  
*snip*

---

From: "Gary Kenward"<[email-masked]>
Date: Wed, 23 Jan 2002 11:05:41 -0500

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

> Sent: January 23, 2002 05:41
> To: Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: 'Schneider, Marco'; 'Roy, Radhika R, ALASO'; Loughney "John
> [email-masked]; [email-masked]
> 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
> > 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
> 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
> 
> > To: Schneider, Marco; 'Roy, Radhika R, ALASO'; Loughney John
> > > [MS]  This is exactly what has been proposed in RAP and 
> SIP working
> > groups to the best 
> > > 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 
> > is including tokens in RSVP, then it is the entity setting up the
> > transport QoS (although 
> > [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. 
> > > 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 
> > > 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 
> > >   It is too early to determine which approach is best, 
> but in either
> > case, 
> > > [MS]  So by end-to-end you are referring to both the 
> end-systems and
> > the devices in 
> > > Application Layer QOS Signaling" and his answer implied user
> > (end-system) to user (end- 
> > > 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. 
> > 
> > the end systems, a host-to-cloud agreement for the transport of the
> > packets, and 
> > Depending upon the complexity of the cloud, the latter 
> could imply all
> > sorts of QoS 
> > require a signalling protocol. My opinion is that it is 
> better in the
> > long term to 
> > 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, 
> > 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.
> > 
> > develope the protocols where they are needed (but not where they are
> > not). At this point, 
> > [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).
> > 
> > 
> > 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 
> > 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. 
> > 
> > 
> > > 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 
> > whatever, the issue is whether a requirement actually helps 
> us define
> > the solution 
> > [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 
> > [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
> >

---

From: [email-masked]
Date: Thu, 24 Jan 2002 18:52:02 +0200

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

---

From: "Schneider, Marco" <[email-masked]>
Date: Mon, 28 Jan 2002 12:31:44 -0600

Brian,

I will look forward to reading your draft as this is an area I know very
little about.

Marco

> Sent: Friday, January 25, 2002 11:00 AM
> To: john loughney
> Cc: [email-masked]
> Hi John.
> On Sat, 2002-01-26 at 01:46, [email-masked] 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