Subject: RE: [NSIS] Two kinds of requirements (priority on the boundary be tween a customer and the network)

From: "Chen, Weijing" <[email-masked]>
Date: Fri, 18 Jan 2002 10:00:37 -0600

Let's look at this picture again:

                       1                                  2
1
[host]
<------[hop]------>[edge]<------[hop]------>[edge]<------[hop]------->[host]
              access network            core network               access
network

                                                        3
[host]<---------------------------------------------------------------------
------------->[host]

The 3 is comprised of 1 and 2. As we know, there are solutions for 2 (MPLS,
DiffServ, PNNI, over-provisioning, etc). What we need to solve is the 1.
Now what about translation (or mapping) between 1 and 2? Do we need to
standardize it? 

The objective of 1 is KISS and universal. The complexity of 1 and 2 mapping
will be born by the [edge].

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

 -----Original Message-----
From: 	[email-masked] [mailto:[email-masked]] 
Sent:	Friday, January 18, 2002 5:12 AM
To:	Schneider, Marco; [email-masked];
[email-masked]
Cc:	[email-masked]
Subject:	RE: [NSIS] Two kinds of requirements (priority on the
boundary be tween a customer and the network)

I do not agree.

What is the point of completing the work enabling the customer to signal to
the network, if the network cannot signal between domains? The network can
never satisfy the request.

Dick

-----Original Message-----
From: Schneider, Marco [mailto:[email-masked]]
Sent: 18 January 2002 01:44
To: 'Georgios Karagiannis (ELN)'; [email-masked]'
Cc: [email-masked]
Subject: RE: [NSIS] Two kinds of requirements

Hi Georgios,

While I agree NSIS could be used to support Interior to Interior (of one
carrier) or Edge to Core, I think that we need to prioritize on a signaling
protocol across the boundary between a customer and the network. Note that
the customer could be an individual, an ISP or another Carrier.

Marco Schneider

-----Original Message-----
From: Georgios Karagiannis (ELN)
[mailto:[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 

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

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

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

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

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

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

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

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

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

Best Regards,
Georgios

-----Original Message-----
From: [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 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

_______________________________________________
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: "Chen, Weijing" <[email-masked]>
Date: Fri, 18 Jan 2002 10:11:57 -0600

Sorry, previous picture is garbled by mailer. 

[host]<--1--[hop]-->[edge]<---2---[hop]-->[edge]<--1--[hop]-->[host]

[host]<-------------------3------------------------------------------------>
[host]

The 3 is our goal and is comprised of 1 and 2. As we know, there are
solutions for 2 (MPLS, DiffServ, PNNI, over-provisioning, etc). What we need
to solve is the 1.  Now what about translation (or mapping) between 1 and 2?
Do we need to standardize it?  If yes, where? In NSIS group or elsewhere?

Regardless, the objective of 1 is KISS and universal. The complexity of 1
and 2 mapping must be born by the [edge].

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

 -----Original Message-----
From: 	[email-masked] [mailto:[email-masked]] 
Sent:	Friday, January 18, 2002 5:12 AM
To:	Schneider, Marco; [email-masked];
[email-masked]
Cc:	[email-masked]

I do not agree.

Dick

-----Original Message-----
From: Schneider, Marco [mailto:[email-masked]]
Sent: 18 January 2002 01:44
To: 'Georgios Karagiannis (ELN)'; [email-masked]'
Cc: [email-masked]
Subject: RE: [NSIS] Two kinds of requirements

Hi Georgios,

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: "Schneider, Marco" <[email-masked]>
Date: Fri, 18 Jan 2002 13:27:47 -0600

Dick,

Perhaps you have interpreted my wording differently than intended. By
"Interior to Interior" I meant within the same domain. As Weijing comments
below there are already a number of solutions within 2 and these do not
require signaling in direct response to an NSIS setup request when they deal
with aggregated paths. 

Marco 
-----Original Message-----
From: Chen, Weijing 
Sent: Friday, January 18, 2002 10:12 AM
To: [email-masked]'; Schneider, Marco;
[email-masked]
Cc: [email-masked]
Subject: RE: [NSIS] Two kinds of requirements (priority on the boundary
be tween a customer and the network)

--
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:	Friday, January 18, 2002 5:12 AM
To:	Schneider, Marco; [email-masked];
[email-masked]
Cc:	[email-masked]

I do not agree.

Dick

-----Original Message-----
From: Schneider, Marco [mailto:[email-masked]]
Sent: 18 January 2002 01:44
To: 'Georgios Karagiannis (ELN)'; [email-masked]'
Cc: [email-masked]
Subject: RE: [NSIS] Two kinds of requirements

Hi Georgios,

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.