Subject: [NSIS] Scope of the NSIS charter

From: "Geib, Ruediger" <[email-masked]>
Date: Wed, 14 Nov 2001 14:31:17 +0100

Hello all,

after reading version 1.3 of the charter I would like to ask for some clarification in the charter before work on any requirements starts. For the time being it's not clear whether the NSIS WG tries to achieve a simple (QoS) signalling protocol or it is looking for a protocol to support quality differentiating services in a wireless mobile environment. My view is that NSIS should separate these issues. I doubt that it is possible to create a *single* protocol which is simple as well as able to support qualitity differentiating services in a wireless mobile environment. I'd prefer an approach which first creates a simple signaling protocol to support end to end services and to evolve it later to solve problems of particular groups of interest. Please keep in mind that IntServ was designed to maintain also QoS services within an any to any multicast community. 

Regards,

Rüdiger Geib

Anything stated in this message only reflects the personal view of the author. 

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

---

From: "Greis Marc (NRC/Dallas)" <[email-masked]>
Date: Wed, 14 Nov 2001 10:12:03 -0600

Hi Ruediger,

> I doubt that it is possible to create a *single* 
> protocol which is simple as well as able to support qualitity 
> differentiating services in a wireless mobile environment. 

Just out of pure curiosity: Can you elaborate on this opinion, i.e. can
you give any reasons why you think it is impossible?

Thanks!
Marc

---

From: [email-masked]
Date: Thu, 15 Nov 2001 08:44:31 +0200

Rüdiger,

> after reading version 1.3 of the charter I would like to ask 
> for some clarification in the charter before work on any 
> requirements starts. For the time being it's not clear 
> whether the NSIS WG tries to achieve a simple (QoS) 
> signalling protocol or it is looking for a protocol to 
> support quality differentiating services in a wireless mobile 
> environment. My view is that NSIS should separate these 
> issues. I doubt that it is possible to create a *single* 
> I'd prefer an approach which first creates a simple signaling 
> protocol to support end to end services and to evolve it 
> later to solve problems of particular groups of interest. 
> Please keep in mind that IntServ was designed to maintain 
> also QoS services within an any to any multicast community. 

The goal is to acheive a simple QoS Signaling protocol.
We should discuss requirements for such a protocol &
a possible architecure.

Wireless networks may see the first applicability of such
a protocol, but the working group should focus on creating
a solution that is good for the Internet.

John

---

From: "Geib, Ruediger" <[email-masked]>
Date: Thu, 15 Nov 2001 09:08:56 +0100

Hello Marc,

R > I doubt that it is possible to create a *single* 
R > protocol which is simple as well as able to support qualitity 
R > differentiating services in a wireless mobile environment. 
M> Just out of pure curiosity: Can you elaborate on this 
M> opinion, i.e. can
M> you give any reasons why you think it is impossible?

My definition of simple QoS signaling:
- limited set of procedures
- limited state stored in the network
- limited set of messages
- limited set of parameters

In order to get QoS in a wireless mobile environment, the service should not be disturbed by a handover. So we are talking about a seamless handover. (I don't think a customer is willing to pay extra charges for a service with a degraded availability - while you demote QoS packets to Best Effort, service is not available in my opinion).

As far as I know Mobile IP works with tunnels. So you have to set up or change tunnels in the case of handover. The tunnel QoS resources must correspond to the QoS communication you tunnel through it (also be aware that the tunnel entry point needs to identify the traffic to be mapped into a particular tunnel). The tunnel entry point may be easy to identify, however the tunnel end point must be found. There you will have to terminate the QoS signalling related to the tunnel. All of that probably more than doubles procedures, state, messages and parameters one requires as compared to a simple single QoS signaling protocol.

I think that above definition of a simple QoS signaling mechanism could result in a Mobile Node friendly protocol. I'd like however to look at the wireless micro mobility issue as a separate problem.

Regards, Rüdiger

---

From: [email-masked]
Date: Thu, 15 Nov 2001 10:37:19 +0200

Rüdiger,

> - limited set of parameters

I agree with this.
 
> In order to get QoS in a wireless mobile environment, the 
> service should not be disturbed by a handover. So we are 
> talking about a seamless handover. (I don't think a customer 
> is willing to pay extra charges for a service with a degraded 
> availability - while you demote QoS packets to Best Effort, 
> service is not available in my opinion).

This work could be done in a second stage effort.  More specifically,
we build the simplified QoS signaling, then later map this
to existing resource reservation mechanisms, etc.  

> I think that above definition of a simple QoS signaling 
> mechanism could result in a Mobile Node friendly protocol. 
> I'd like however to look at the wireless micro mobility issue 
> as a separate problem.

We are not going to get anywhere near micromobility.  This is
far outside our charter.  

br,
John

---

From: [email-masked] (Gabor Fodor)
Date: Thu, 15 Nov 2001 11:31:51 +0100 (MET)

Rüdiger, John,

regarding the set of parameters that need to be signaled:
we need to consider cellular access networks as well,
that require a fine grained set of OoS paramaters in order
to properly configure their bearer services.

Earlier we submitted two drafts that discuss the QoS
parameter requirements from a cellular perspective :

http://www.ietf.org/internet-drafts/draft-fodor-intserv-wireless-issues-00.txt
http://www.ietf.org/internet-drafts/draft-fodor-intserv-wireless-params-00.txt

These drafts use an Intserv CL based model as an example where
these "wireless hint" type of QoS paramaters could fit, but the
same reasoning would apply to any new QoS signaling protocol that
considers wireless accesses as a possible scenario. We certainly
should have such scenarios in our scope. 

The drafts also discuss how you could make use of such parameters 
specifically in an Intserv over wireless scenario, but again 
the same/similar model could be used for other IP over cellular 
scenarios as well.

/Gabor   

> From [email-masked] Thu Nov 15 09:42:24 2001
> From: [email-masked]
> To: [email-masked], [email-masked]
> Subject: RE: [NSIS] Scope of the NSIS charter
> Date: Thu, 15 Nov 2001 10:37:19 +0200
> MIME-Version: 1.0
> Content-Transfer-Encoding: 8bit
> X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id DAA05764
> X-Mailman-Version: 1.0
> List-Id: Next Steps in Signaling <nsis.ietf.org>
> X-BeenThere: [email-masked]
> 
> Rüdiger,
>