Subject: [NSIS] Scoping of BBs

From: [email-masked]
Date: Tue, 14 May 2002 15:08:06 +0300

Hi Lasse,

> Could you explain more about your proxy-solution. I am not 
> conviced that your proxy is the same as a bandwidth broker.

You make a good point.  To provide some additional scoping,
here are my thoughts:

1) entities involved in the reservation of resources are 
   out of scope.

2) entities which relay signaling probably are not out of scope.

3) place holders for future work in signaling to & between  
   resource reservation entities is probably in scope, the
   exact nature of the signaling is probably out of scope.

4) signaling to & from entities which 'proxy' qos is probably
   within scope.

5) signaling end-to-end is within scope

6) resource reservation end-to-end is not in scope.

John

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

---

From: "Freytsis, Ilya" <[email-masked]>
Date: Tue, 14 May 2002 09:46:27 -0400

John,

Could you make it clearer what do you mean by "exact nature of the
signaling"?
I my mind the "signaling to & between resource reservation entities" IS one
of the main objectives of this working group. I think you would agree that
in RSVP-like model the routers ARE "resource reservation entities". Are you
saying that we need only placeholders for the future work on signaling
between routers? I hope not.
If you mean that exact nature of the signaling is service specific I would
agree with you.
Ilya

---

From: "Geib, Ruediger" <[email-masked]>
Date: Tue, 14 May 2002 16:48:54 +0200

Hi John,

So IntServ/RSVP is out of scope as every router
processing these messages reserves resources. 
Ilya made that point earlier and I'd interpret 
your statement the same way.

> 1) entities involved in the reservation of resources are 

My expectation of NSIS is that it specifies the interfaces
and signaling mechanisms to set up, maintain and remove 
service reservations of any kind. Done by any units
providing service management.

NSIS does not specify these services nor does 
NSIS specify how these reservations are translated into
router configurations.

Would that approximately describe what NSIS is about? 

Regards, Rüdiger

---

From: [email-masked]
Date: Tue, 14 May 2002 21:33:36 +0300

Hi Georgios,

> I do not think that the entities involved in the reservation of
> resources are out of NSIS scope, but the standardization of the 
> functionality that provides resource reservation, which is 
> included in such entities is out of NSIS scope!!

I think we want to be care not to over-engineer any new
entities in this.  Of course, we will need to discuss
some basic entities, but beyond that is probably out of
scope.

John

---

From: [email-masked]
Date: Tue, 14 May 2002 21:32:15 +0300

Hi Rüdiger,

> your statement the same way.

I think so.  RSVP, with IntServ removed is probably
applicable.  That is why it has been suggested we look at

"Specification of the Null Service Type - RFC 2997"

"A Framework For IntServ Operation Over Diffserv Networks - RFC 2998" 

> Would that approximately describe what NSIS is about? 

My personal (non-chair) opinion, would be that if we could
do the above in a reasonable time period, we would have
some interesting tools to do interesting things.  Additionally,
we would have fairly fertile ground to recharter or 
start an other WG.

John

---

From: [email-masked]
Date: Tue, 14 May 2002 16:58:08 +0300

Hi Georgios,

> One of the issues that we could discuss in Helsinki is:
> Can one NSIS protocol fulfill all the requirements that we 
> have stated?
> 
> In my opinion not!
> Maybe it will be better to discuss the possibility of having 
> more than one protocols?

I will tell you that we are only chartered to work on a (singular)
protocol.  To do more will require rechartering.  Rechartering
will be difficult.  It may be that we need to leave some 
work for later.  For example, we define requirements and a framework
and choose a specific part of the framework to start protocol
work.  After that is completed, we can then seek to recharter
or start a new working group.  

John

---

From: "Georgios Karagiannis (ELN)" <[email-masked]>
Date: Tue, 14 May 2002 17:03:35 +0200

Hi 

I do not think that the entities involved in the reservation of
resources are out of NSIS scope, but the standardization of the 
functionality that provides resource reservation, which is included in such 
entities is out of NSIS scope!!

Best regards,
Georgios

-----Original Message-----
From: Geib, Ruediger [mailto:[email-masked]]
Sent: dinsdag 14 mei 2002 16:49
To: [email-masked]
Cc: [email-masked]
Subject: RE: [NSIS] Scoping of BBs

Hi John,

Regards, Rüdiger

---

From: "Georgios Karagiannis (ELN)" <[email-masked]>
Date: Tue, 14 May 2002 15:36:18 +0200

Hi 

I also agree with Sven.
One of the issues that we could discuss in Helsinki is:
Can one NSIS protocol fulfill all the requirements that we have stated?

In my opinion not!
Maybe it will be better to discuss the possibility of having more than one 
protocols?

Best regards,
Georgios

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]
Sent: dinsdag 14 mei 2002 14:57
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [NSIS] Scoping of BBs

John, all,

The fact that you decouple signaling from resource reservation seems to
suggest the anticipated use of some sort of probing mechanism prior to
connection setup. We were more thinking along the lines of hard-guaranteed
QoS with per-flow admission control (also in the core), mandating the
notion of resource reservation in the signaling protocol (much like in RSVP
by the way). I agree that the actual way the reservation is carried out
locally is out of scope, but I wouldn't like to exclude the notion from the
protocol, nor exclude resource reservation entities to participate in it.

Sven

[email-masked] on 14/05/2002 14:08:06

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

  Subject      [NSIS] Scoping of BBs                          
  :                                                           

Hi Lasse,

John

---

From: [email-masked]
Date: Tue, 14 May 2002 16:55:08 +0300

Hi Ilya,

> If you mean that exact nature of the signaling is service specific I would

NSIS cannot do everything ... when we consider that there may
be specific needs for specific types of resource reservation,
we may need some sort of 'mapping.'  This is currently not
in our charter, but we could put place holders so that we 
could recharter or start another working group on subject.

For example, signaling needed between resource reservation entities
for simple over-provisioned network domains is different than what is
needed for IntServ domains.

John

---

From: "Gary Kenward"<[email-masked]>
Date: Tue, 14 May 2002 10:31:12 -0400

John: 

I am somewhat confused by this problem description. NSIS is 
concerned with QoS signalling, correct? QoS in the internet almost
always includes bandwidth, correct? So how does one signal QoS without
being involved with bandwidth allocation? What does "involved" mean?

Does NSIS provide the mechanisms to signal a router to allocate Q Mbps
of bandwidth for flow xzy? Well, ok, perhaps not, but if NSIS is not
telling the entity that performs this function to initiate the provisioning
of Q Mbps, then what exactly is it doing? Ferrying DSCP's about? If NSIS
ends up using RSVP, do we drop bandwidth from the TSpec and RSpec, or the
other parameters, for they are used for provisioning?

I am very concerned that the NSIS charter has defined a problem space
wedged between session establishment and bearer path provisioning. A
solution for this problem space is definitely required, but it must be
questioned
that yet another protocol solution is warranted. One has to wonder just how
many 
protocols/entities are really necessary to establish end-to-end QoS, and
just 
what the quality of this distributed, loosely coupled, multi-phasic solution
will be? 
More important, will this solution really provide a viable alternative to
the L2 
centric solutions being worked on in other (notably wireless, but also
PacketCable) 
SDOs (yes, I understand that these solutions do not address the end-to-end
problem
completely, but they are efficient solutions for the particular access
network).

Sorry if this seems like charter bashing: consider it a request for
clarification.
I would ask it at the interim, but I cannot be there.

Cheers,
Gary

> From: [email-masked] [mailto:[email-masked]]
> Sent: May 14, 2002 08:08
> Subject: [NSIS] Scoping of BBs
> 
> 
> Hi Lasse,
>

---

From: [email-masked]
Date: Wed, 15 May 2002 11:58:52 +0300

Hi Sven,

> connection setup. 

Why do you say that?  Cannot the probe be the actual request? 

> We were more thinking along the lines of hard-guaranteed

I wonder if we need hard-guaranteed-QoS with per-flow admission control
in all cases.  I definately think that this is a service, but I am not
sure if it is the default.

John

---

From: [email-masked]
Date: Wed, 15 May 2002 11:27:09 +0300

Hi Georgios,

> As entities I am referring to (Layer 3) Routers.

Then we are probably in agreement that this is something
that NSIS will discuss.

John

---

From: "Georgios Karagiannis (ELN)" <[email-masked]>
Date: Wed, 15 May 2002 10:24:21 +0200

Hi John

Best Regards,
Georgios

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: dinsdag 14 mei 2002 20:34
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [NSIS] Scoping of BBs

Hi Georgios,

John

---

From: [email-masked]
Date: Wed, 15 May 2002 11:26:06 +0300

Hi Cary,

> being involved with bandwidth allocation? What does "involved" mean? 

If you signaling that you want x amount of bandwidth, and get a reply
of 'OK' - then that is signaling bandwidth.  

For example, if you and I want to have some sort of media call, with a
bandwidth of 50 k, my network uses no resource reservation mechanisms,
just simple access control and overprovisioning, while yours uses a proprietary
implementation of IntServ, how do we handle bandwidth allocation?  Might
it be enought that I signal to my network my needs (BW = 50k), which are passed on
to you, you signal to your network your needs (BW = 50K).  Assuming everything
was OK, then we have a session of 50k between us.  This kind of signaling
is nice because when you roam into my network, you don't need to worry
at all what kind of provisioning is done in my network, you just simply
request.

> other parameters, for they are used for provisioning? 

See above example.

> solution for this problem space is definitely required, but it must be questioned 
> that yet another protocol solution is warranted. One has to wonder just how many 
> protocols/entities are really necessary to establish end-to-end QoS, and just 
> what the quality of this distributed, loosely coupled, multi-phasic solution will be? 

Question to you, what is it that you are looking for in this space?

> More important, will this solution really provide a viable alternative to the L2 
> centric solutions being worked on in other (notably wireless, but also PacketCable) 
> SDOs (yes, I understand that these solutions do not address the end-to-end problem 
> completely, but they are efficient solutions for the particular access network). 
> Sorry if this seems like charter bashing: consider it a request for clarification. 

The above is l2 specific or network specific.  You have trouble using
any of them on the open Interent. Since there is not a solution currently,
you do see multiple solutions at l2 or network dependent.  However, these
solutions are not universal enough to be used on other l2s or in different
networks.

John

---

From: [email-masked]
Date: Fri, 17 May 2002 11:46:08 +0200

Hi john,

See some comments inline

Sven

[email-masked] on 15/05/2002 10:58:52

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

  Subject      RE: [NSIS] Scoping of BBs                      
  :                                                           

Hi Sven,

Sven>> Maybe it can but it will never guarantee you QoS. There is
absolutely no reason why the current state of the network would still allow
the QoS when the actual data arrive or even that it remains that way for
the duration of the connection one wishes to establish. That's why we think
there is a case for hard-guaranteed QoS.

Sven>> I assume the default service will still be BE and that we are trying
with nsis to provide something in addition to that.

Sven.

John

---

From: [email-masked]
Date: Fri, 17 May 2002 12:02:22 +0200

Hi Marcus,

As I said in the reply to John I agree with respect to the actual
reservation act (as stated in some other mails in this thread this can
happen e.g. with a BB) but it is essential to have to notion in the
signaling to say that at least you can get confirmation that something is
actually there for you when you send data.

2 more cents,
Sven.

Marcus Brunner <[email-masked]> on 15/05/2002 17:56:21

Please respond to [email-masked]

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

                                                              
  Subject      Re: [NSIS] Scoping of BBs                      
  :                                                           

Sven,

I am not sure what you refer to with probing mechanisms. But agree that we
really want to decouple signalling from resource reservation.

Marcus

--On Tuesday, May 14, 2002 2:57 PM +0200 [email-masked]
wrote:

> notion of resource reservation in the signaling protocol (much like in
> RSVP by the way). I agree that the actual way the reservation is carried
> out locally is out of scope, but I wouldn't like to exclude the notion
> from the protocol, nor exclude resource reservation entities to
> participate in it.
>
> Sven
>
>
>
>
>

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

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

---

From: [email-masked]
Date: Fri, 17 May 2002 15:47:43 +0300

Hi Sven,

> the duration of the connection one wishes to establish. 
> That's why we think there is a case for hard-guaranteed QoS.

So, Hard-quaranteed QoS could be one service offered.  That is
reasonable.  Do you think this implies additional requirements?

John