Subject: [NSIS] section 5.2.2 in requirement draft

From: [email-masked]
Date: Thu, 7 Mar 2002 16:05:56 +0100

All, 

to the second major concern I have about the requirement document. 

That is whether or not to constrain the signaling and controllers onto the datapath. 

I have seen discussions in various camps that it is a good thing to relax the condition about having "signaling" (let it be QoS-signalinig or routing...) and data on the same plane. 

For me this boils down to a discussion around fate sharing. Ie whether or not the dataplane forwarding (or the quality of forwarding) should be dependent on a single (or cluster of) device(s). 

Generally, business agreements and policy management is the two functionality that I see should be centrally controlled, this because of their nature. Anything else should be forced onto the dataplane.

That was architecturally, but what about reality? 

I see a divider between two different form of services: a connection service and a 'call'. A vague definition would be: 

- connection service: where an ISP sell capacity between two (or more) points, promised at all times. 
- 'call'-service: where an ISP sell a promise that a call can be delivered at any time. 

Under connection services you find things like trunk capacity between PSTN-gateways, trunk capacity between VPN-nodes etc. Under 'call' service you find services like PSTN-calls-over IP, SIP-initiated communication (mobile as well as fixed) etc.

These two have, IMO, far different requirements when it comes to business agreements and technical solution. One may very well suit a centralised solution (connection services in SDH is usually managed this way). On the other hand, the 'call' service does not usually match a centralised solution, I think a distributed solution is probably the most sensible choice for those.

I have still not understood the nsis scope regarding which form of services to consider. 

My understanding is that nsis focus on the second of these services, is that a correct? 

If my understanding was correct: does a 'call'-service really necessitate a seperation between signaling plane and data plane? And in that case, why? 

Anders

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

---

From: [email-masked]
Date: Thu, 7 Mar 2002 16:18:12 +0100

Hi Anders,

I think we have to make a distinction between in-band/out-of-band and
centralised/distributed. An out of band solution is not necessarily
centralised. It may, however, be convenient to think about it as
centralised although its implementation can be distributed. Anyway, in my
opinion, out-of-band signaling has several adventages:
- deployment: it requires less updates in software/hardware
- transparency for other/future technologies: it allows to implement the
signaling over other/future technologies that are not necessarily nsis
aware because the nsis messages would only be interpreted in the
(ou-of-band) QCs.

If out-of-band signaling is with a centralised entity, then of course it
needs to be scalable in order to be feasible on a per-call basis. This is
achieved with the two-level admission control within long-lived pipes with
defined QoS. This would relax the requirements on the nsis protocol when
used end-to-end because most of the complexity would be in the defintion
and provisioing of the long-lived pipes which is a local matter.

What do you think?,
Sven.

[email-masked] on 07/03/2002 16:05:56

  To:          [email-masked]                                  
                                                              
  cc:          (bcc: Sven VAN DEN BOSCH/BE/ALCATEL)           

  Subject      [NSIS] section 5.2.2 in requirement draft      
  :                                                           

All,

That is whether or not to constrain the signaling and controllers onto the
datapath.

I have seen discussions in various camps that it is a good thing to relax
the condition about having "signaling" (let it be QoS-signalinig or
routing...) and data on the same plane.

For me this boils down to a discussion around fate sharing. Ie whether or
not the dataplane forwarding (or the quality of forwarding) should be
dependent on a single (or cluster of) device(s).

Generally, business agreements and policy management is the two
functionality that I see should be centrally controlled, this because of
their nature. Anything else should be forced onto the dataplane.

I see a divider between two different form of services: a connection
service and a 'call'. A vague definition would be:

- connection service: where an ISP sell capacity between two (or more)
points, promised at all times.
- 'call'-service: where an ISP sell a promise that a call can be delivered
at any time.

Under connection services you find things like trunk capacity between
PSTN-gateways, trunk capacity between VPN-nodes etc. Under 'call' service
you find services like PSTN-calls-over IP, SIP-initiated communication
(mobile as well as fixed) etc.

These two have, IMO, far different requirements when it comes to business
agreements and technical solution. One may very well suit a centralised
solution (connection services in SDH is usually managed this way). On the
other hand, the 'call' service does not usually match a centralised
solution, I think a distributed solution is probably the most sensible
choice for those.

I have still not understood the nsis scope regarding which form of services
to consider.

My understanding is that nsis focus on the second of these services, is
that a correct?

If my understanding was correct: does a 'call'-service really necessitate a
seperation between signaling plane and data plane? And in that case, why?

Anders

---

From: [email-masked]
Date: Thu, 7 Mar 2002 17:04:05 +0100

Sven, 

> centralised although its implementation can be distributed. 
Agreed, that was what I tried to indicate with a cluster-of QCs. 

> This is achieved with the two-level admission control within 
> long-lived pipes with
This was my main question: 

is the "long-lived pipes"-service something that is within focus of nsis or not? 

This "long-lived pipes" sounds like provisioning of resources to me. We have been playing with this architecture for awhile as well (a paper coming out in Networks 2002) that describes and analyse an architecture for supporting this. The architecture is doable, but is it really the first thing we should tackle? And should it be tackled in nsis?

If the consensus is yes, then I suggest for clarity that the requirements for the two different parts be clearly separated. My hunch is that the two different tracks ("layers") will lead to two different architectures and mixing them will create a fuzzy requirements document. 

From my point of view, I would be as happy to leave this work for future studies and focus on the first tier (the e2e signaling). And then bring up the discussion on the second-tier seperately.

Anders

---

From: [email-masked]
Date: Thu, 7 Mar 2002 17:52:58 +0100

Anders,

I have the feeling that the proposal contained in Sven mail fits well with
the definition you gave in a previous mail:
- connection service: implemented by long-lived pipes, which can be defined
today by provisioning and maybe extending in the future with more
semi-dynamic procedures (but still 'maybe'). This entity is not aware of,
let's say, the usage of the content of each pipe (micro-flows, etc.)
- 'call'-service: the provider of this service is using a "connection
service" from a transport provider, so it is the customer of this
"connection service", and is considering each pipe much as a link. This
entity is fully aware of the content of the pipe, but it does not need to
consider how the pipe is actually implemented (diffserv, VPN, etc.)
As this, you can break the scalability issue by splitting the global
picture in two different roles.

Now, concerning the nsis scope, IMHO the general model should consider both
roles. However, this does not mean in anyway that e.g. the definitions of
SLAs are in the scope of nsis.
NSIS should provide the general architecture and the related mechanisms
allowing the involved actors to define their needs and negotiate common
agreements.
It is definitely not in the scope of NSIS to define the services
themselves.

Best regards

Juan Carlos

[email-masked]@ietf.org on 07/03/2002 17:04:05

Sent by:  [email-masked]

To:   Sven VAN DEN BOSCH/BE/ALCATEL@ALCATEL
cc:   <[email-masked]>, <[email-masked]>
Subject:  RE: [NSIS] section 5.2.2 in requirement draft

Sven,

is the "long-lived pipes"-service something that is within focus of nsis or
not?

This "long-lived pipes" sounds like provisioning of resources to me. We
have been playing with this architecture for awhile as well (a paper coming
out in Networks 2002) that describes and analyse an architecture for
supporting this. The architecture is doable, but is it really the first
thing we should tackle? And should it be tackled in nsis?

If the consensus is yes, then I suggest for clarity that the requirements
for the two different parts be clearly separated. My hunch is that the two
different tracks ("layers") will lead to two different architectures and
mixing them will create a fuzzy requirements document.

From my point of view, I would be as happy to leave this work for future
studies and focus on the first tier (the e2e signaling). And then bring up
the discussion on the second-tier seperately.

Anders

---

From: [email-masked]
Date: Fri, 8 Mar 2002 10:42:06 +0200

Hi Sven,

To summarize the requirements with regards to on-path vs. off-path signaling, 
we may have to say this:

	NSIS SHOULD support on-path signaling.
	NSIS MAY support signaling to known entities.

Perhaps my word-usage could be tweaked, but what I mean is the default
signaling is on-path, but if an endpoint knows where it wants to signaling
to (pre-configured or something) is should be allowed as well.

John

---

From: [email-masked]
Date: Fri, 8 Mar 2002 10:58:25 +0200

Hi Anders,

> be delivered at any time. 

I would suggest that NSIS will be working on a connection basis,
however, the specifics of the connection may be a detail that
NSIS tackles, but also may be left up to deployment.

I do think we will have a hard discussion ahead (not for the
requiements draft) of how we classify the quality in QoS.
Is it reliability, is it bandwidth, is it delay; is it
absolute; is it relative ... However, I don't think we
can go into that level of detail here.

thanks,
John

---

From: [email-masked]
Date: Fri, 8 Mar 2002 10:59:45 +0200

> can go into that level of detail here.

PS - (talking to myself, I guess) we should make sure that
the requirements do not unduely restrict the possibilities
here.

John

---

From: [email-masked]
Date: Fri, 8 Mar 2002 09:59:52 +0100

Anders,

Thanks for you reply.
You mentioned that you would like to focus on e2e signaling first. There
can be two definitions of this:
1) between the first and the last nsis speaker
2) between end-hosts
I think everyone agrees that the (nsis) signaling from end-host to end-host
will have different requirements than from edge to edge. If you assume for
a minute that not all end-hosts will be nsis speakers right away then this
means that the edge-to-edge case is certainly in the scope of nsis. In that
case it makes sense to think of the 'edge-to-edge application' of nsis as
the first step. This would then need to be complemented with a 'local QoS
signaling' for the end-host to first nsis speaker connection and possibly
also for mapping of the edge-to-edge signaling to local mechanisms. I
believe it has been stated as a requirement that NSIS can be used as a
local mechanism (in its own right) as well. This would then map very nicely
to this second 'local application' of NSIS. I think this would be a useful
distinction to aggregate the requirements for. In my opinion, the
requirements for the local mechanism would be a superset of the
edge-to-edge requirements.

Sven.

[email-masked] on 07/03/2002 17:04:05

                                                              
  cc:          [email-masked], [email-masked]          

  Subject      RE: [NSIS] section 5.2.2 in requirement draft  
  :                                                           

Sven,

Anders

---

From: [email-masked]
Date: Fri, 8 Mar 2002 10:12:28 +0100

Hi John,

I agree with your explanation but I don't think your wording really
reflects what you say there. Would you agree to something like:
NSIS SHOULD support on-path signaling and signaling to and/or from known
entities. The default behaviour SHOULD be on-path signaling.

Sven.

[email-masked] on 08/03/2002 09:42:06

  To:          Sven VAN DEN BOSCH/BE/ALCATEL@ALCATEL,         
               [email-masked]                     
                                                              
  cc:          [email-masked]                                  

Hi Sven,

To summarize the requirements with regards to on-path vs. off-path
signaling,
we may have to say this:

John

---

From: [email-masked]
Date: Fri, 8 Mar 2002 11:20:38 +0200

Hi Sven,

> NSIS SHOULD support on-path signaling and signaling to and/or 
> from known entities. The default behaviour SHOULD be on-path signaling.

I prefer to have single statement requirements, so I'd suggest we have
3 requirements:

	NSIS SHOULD support on-path signaling.
	NSIS SHOULD support signaling to and/or from known entities. 
	The default behaviour SHOULD be on-path signaling.

Fufilling requirements with multiple clauses is difficult.
(also we can discuss the level - MUST/SHOULD/MAY ...)

John

---

From: [email-masked]
Date: Fri, 8 Mar 2002 10:25:09 +0100

All, 

could we agree on the following?

	NSIS SHOULD support on-path signaling.
	NSIS MAY support signaling to and/or from known entities. 
(btw: maybe the first req. should be a MUST)

Anders

---

From: [email-masked]
Date: Fri, 8 Mar 2002 11:26:06 +0200

Hi Anders,

> (btw: maybe the first req. should be a MUST)

I agree.

John

---

From: [email-masked]
Date: Fri, 8 Mar 2002 11:06:17 +0100

Hi John, Anders, all

I fully agree of course that in-band signaling SHOULD be supported (this
could be even a MUST).
Since we do not want to constrain ourselves to a particular solution I
would like propose that both
in-band and out-of-band signaling should be supported. Adding a default
behavior as
proposed before today on the mailinglist is then a good idea. Hence, I am
in favor of three requirements:
     1. NSIS SHOULD (MUST?) support on-path signaling.
     2. NSIS SHOULD support signaling to and/or from known entities.
     3. The default behaviour SHOULD be on-path signaling.

Maarten.

[email-masked] on 08/03/2002 10:26:06

 To:      [email-masked], Sven VAN DEN            
          BOSCH/BE/ALCATEL@ALCATEL                            
                                                              
 cc:      [email-masked](bcc: Maarten BUCHLI/BE/ALCATEL)       

Hi Anders,

I agree.

John

---

From: [email-masked]
Date: Fri, 8 Mar 2002 13:08:26 +0100

Hi John,

A good suggestion. I agree.

Thanks,
Sven.

[email-masked] on 08/03/2002 10:20:38

                                                              
  cc:          [email-masked], [email-masked]      

Hi Sven,

John

---

From: "Hancock, Robert" <[email-masked]>
Date: Fri, 8 Mar 2002 19:47:29 -0000

hi all,

I'm slightly confused by the process being followed in the refinement of this requirement.

we have scenarios in the draft, and a mapping of the requirements to the scenarios (in section 6) with an interpreted may/must/should/whatever. the currently phrased requirement tries to capture the fact that in several of the scenarios the QoS entities are not (should not be forced to be) in the data path.

it appears that the mapping for 5.2.2 is currently assigned as 'MUST' for all scenarios. so, when people are suggesting MAY/SHOULD for signalling to known entities, is this a reflection of the view that
*) the relationship between the requirement and the scenario is wrong, or
*) the scenario is not important, or
*) something else.

likewise, if there is a MUST to support on-path signalling, i'd be interested to know what scenarios it relates to. (they probably aren't hard to find, of course.)
[Note: i'm not saying that on-path signalling is a bad thing. Indeed, in many situations, it may be the best thing. But in that case, it will come in as part of the solution anyway, we don't need to write a requirement that says it is the best thing. In particular, writing a requirement that it should be the default strikes me as very close to being 'solution oriented' which we are supposedly trying to avoid...]

robert h.

PS this is entirely in addition to the question of whether on/off path and directed signalling are even related concepts  in the first place, and what it actually means to say 'NSIS must/may whatever'. but i'll pose those questions separately.

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]
> Sent: 08 March 2002 12:08
> To: [email-masked]
> Cc: [email-masked]; [email-masked]

---

From: "Hancock, Robert" <[email-masked]>
Date: Fri, 8 Mar 2002 19:47:26 -0000

Hi all,

in this discussion it appears that we have two pairs of alternatives being considered as parts of requirements:
A1) signalling is addressed to the flow endpoint (and intercepted) OR 
A2) signalling is addressed explicitly to the next QC/QR (if you like this 'QR' term, which I am coming round to)
AND
B1) signalling goes to entities on the flow data path OR 
B2) signalling goes to entities away from the flow path.

In theory, people worried about the need for QC/QR discovery procedures etc. should be worried about the choice between A1 and A2. People worried about the cost of distributing QoS information from centralised entities to the routers, or about fate sharing/resilience issues should be worried about the choice between B1 and B2. (Georgios and Anders have made these points, and there is also a discussion in 10.1 of our framework document draft-hancock-... which comes to a slightly different conclusion...).  

I want to stress that A1 != B1, and A2 != B2. QoS routing (or indeed load sharing or indeed any other sort of traffic engineering) *anywhere* between the flow endpoints can allow implicitly addressed signalling to drift away from the data path. So, if the fundamental requirement is B1, we have to allow A2.

So, what are the requirements? Currently we have B1=SHOULD and A2=SHOULD. Do people care about A1 and B2 or not? Are all four SHOULD?

Robert H.

PS I apologise if this seems pedantic [colleagues of mine will not be shocked], but I think the distinction is real and significant. I also think that the A1/A2 requirements are framework rather than requirements issues.

---

From: "Schneider, Marco" <[email-masked]>
Date: Fri, 8 Mar 2002 15:46:29 -0600

Anders,

I think our first priority is a protocol that allows an application (QOS
Initiator?) to request(from a QOS Controller?) a qos connection service
between its host and another host. Next we need to consider what other
signaling will be necessary to produce an end-to-end result. 

In one approach a QOS controller might setup several QOS
connections/channels independently and splice them together. By
connection/channel I mean an entrance and exit through a network with a qos
service guarantee. 

In another approach a  QOS controller may arrange for a qos
connection/channel in its domain and pass on a request to the next domain to
arrange for a qos connection/channel towards an eventual destination. This
is analagous to hop by hop signaling only it is domain by domain under the
assumption that there are many existing techniques (such as long lived
pipes) to arrange for the qos within a particular domain.

Best Regards,
Marco  

> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, March 07, 2002 10:04 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> This "long-lived pipes" sounds like provisioning of resources 
> to me. We have been playing with this architecture for awhile 
> as well (a paper coming out in Networks 2002) that describes 
> and analyse an architecture for supporting this. The 
> architecture is doable, but is it really the first thing we 
> should tackle? And should it be tackled in nsis?
> 
> If the consensus is yes, then I suggest for clarity that the 
> requirements for the two different parts be clearly 
> separated. My hunch is that the two different tracks 
> ("layers") will lead to two different architectures and 
> From my point of view, I would be as happy to leave this work 
> for future studies and focus on the first tier (the e2e 
> signaling). And then bring up the discussion on the 
> second-tier seperately.
> 
> Anders
>