Subject: [NSIS] RE: Update NSIS Charter (v 1.3)

From: [email-masked]
Date: Tue, 6 Nov 2001 20:48:21 +0200

Hi Jim,

> Great job! Looks just exactly right.

Thanks for the support!
 
> I hope that the WG will discuss initially the reasons why QoS hasn't
> been deployed. These have been floating around but I think it will be
> important in formulating requirements
> to have a clear and well-articulated understanding about why 
> deployment of QoS has so far been lagging (other than the obvious 
> one that multimedia traffic on the Internet has yet to become a large 
> part of the traffic).

Agreed.  There have been some documents produced already on this
subject, hopefully they can be submitted as input for NSIS.

John

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

---

From: [email-masked]
Date: Tue, 6 Nov 2001 20:55:15 +0200

Hi,

> Forgive me for jumping into this in midstream; some of my comments
> may already have been addressed.
> 
> 1) Is this "Next Steps in Signaling" or "Next Steps in Signaling QoS"?

Essentially Next Steps in Signaling QoS.

> 2) If the latter, is DiffServ even under consideration?

We are staying out of specific QoS mechanisms (diffserv, intserv,
etc-serv).  

> 3) "It is a non-goal of the working group to develop new resource
>     allocation protocols."  -- is this a done deed?  (I'm happy with
>     it; I just want to know if this has consensus.)

It is a done deal.  Maybe once NSIS has fufilled its charter, we can
get into resource allocation, but first we want to simply be able
to signal QoS.
> 
> > It is noted that resource reservation and traffic engineering can be
> > considered as part of network administration, and therefore 
> > beyond the scope of the IETF to mandate a particular mechanism.
> 
> I'm not sure why this is in here:
> a) RSVP is an IETF protocol. 

We are considering RSVP as a signaling protocl, not intserv.

> b) The TE WG is an active IETF WG.

Yes, but the IETF cannot mandate a one-size fits all.  If operator
A deploys intserv, operator b deploys diffserv and operator c uses
over provisioning, how can a roaming user be assured QoS without
explicitly understanding the underlying mechanism used?  This is
the problem space we are playing in. What I propose is we remove
the burder from the user.  The user can say 'give me x QoS' and
the network can interpret this.

> c) "mandate a particular mechanism" -- does the IETF's IDR WG 
> "mandate"
>    BGP as an interdomain protocol?  If so, is that bad?  This 
> statement
>    seems to question NSIS's raison d'etre.  If we want to go 
> that route,
>    NSIS should be a BOF, and we should settle this issue first.
> 
>    Personally, I don't agree with the statement, so my choice would be
>    to remove it.

I believe that QoS has not been deployed because of competing mechanisms
and difficulties with mobility, roaming and end-to-end QoS.  

John

---

From: "Georgios Karagiannis (ELN)" <[email-masked]>
Date: Thu, 8 Nov 2001 13:25:01 +0100

Hi John

I think that the charter looks better now!

However, I hope that the main objective of the 
first NSIS WG meeting will be to discuss the 
QoS requirements + analysis that are/will be submitted.
Based on this discussion we may decide which existing 
QoS protocols (solutions) could satisfy the most of these 
requirements.
Moreover, based on the above, we may probably discuss 
where the NSIS solution will be applicable and where not!

Best regards,
Georgios

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: dinsdag 6 november 2001 15:10
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: [NSIS] Update NSIS Charter (v 1.3)

Hi all,

Please find the updated charter.  We recieved some comments from the IESG,
mostly quite positive.  Please let me know what you all think.

Best regards,
John

=========

nsis-charter version 1.3

NSIS
Next Steps in Signaling
Chair:  John Loughney, [email-masked]
Area:   Transport

Mailing List: 
General Discussion: [email-masked] 
To Subscribe: [email-masked] 
In Body: subscribe 
Archive: www.ietf.org/mail-archive/working-groups/nsis/current/maillist.html

Quite a bit of work has been done on Quality of Service and resource
reservation for the Internet.  For a number of reasons, however, there has
not been a significant amount of end-to-end QoS deployed on the Internet
other than best effort service.  

It is noted that resource reservation and traffic engineering can be
considered as part of network administration, and therefore beyond the scope
of the IETF to mandate a particular mechanism.  When considering end-to-end
communication, it is likely that several administrative domains are
traversed.  Interworking between domains in which different QoS solutions
solutions are deployed is problematic. Mobility and roaming additionally add
complexity to the overall picture.  This creates a need for a simplified
solution of signaling QoS, one that reuses parts of existing methods.  This
will allow users to obtain QoS-aware services, irrespective of underlying
mechanisms used.

This working group will develop the requirements, architecture and protocols
for the next IETF steps on signaling QoS. The working group will use
existing IETF signaling as the basis for this work.  Additionally, the
working group will consider how to signal QoS (what sort of QoS parameters
to use), and where to signal (end-to-end, end-to-edge, end-to-proxy,
edge-to-edge, etc.). As input to the working group, the Mobile IP QoS
Requirements document  (draft-mobileip-qos-requirements) will be considered
as one starting point for developing the overall set of requirements.  The
working group will not limit itself to mobile IP-only QoS signaling needs,
however, but will consider general cases of signaling QoS in the Internet
(both wired and wireless). Consideration will be given to the idea of a
building block structure, so the group could develop elements for QoS
signaling that could be modular and be combined with a different payload or
different proxy (e.g.) for use by a non-QoS signaling function. The added
function will be out of scope, but the openness of the design (which may be
a new version of RSVP) will be in scope.

This working group will focus on providing (QoS) signaling function to a
local access network and end-to-end signaling.  It is not the intention of
this working group to invent new signaling protocols. Additionally, mobility
protocols and AAA work are out of scope of the working group.  The work
produced in this Working Group should work with existing IETF mobility and
AAA protocols, including (but not limited to) Mobile IP, SeaMoby Context
Transfer and Diameter.

As with nearly all work being done in the IETF, security is a very important
concern for NSIS.  The working group will study the security requirements
for QoS Signaling, as well as create a threat analysis of QoS signaling.
Compatibility with authentication and authorization mechanisms is also a
concern.  These topics will be addressed in the Signaling Requirements
document.

This working group will provide the framework for interworking with existing
resource allocation methods.  It is a non-goal of the working group to
develop new resource allocation protocols.    

The working group will coordinate with a number of other IETF working
groups, including Diffserv, Seamoby, Mobileip, AAA, Midcom and RAP.  It will
also welcome participation and expression of requirements from non-IETF
standards organization members, for instance 3GPP and 3GPP2 and ITU-T.

Goals and Milestones:
=====================

Jan 01	Initial ID on Signaling Requirements.

Feb  01	Initial ID on Analysis of existing signaling protocols.

Mar 02	Initial ID on 'Framework Signaling Architecture.'

Jun 02 	Submit 'Signaling Requirements' to IESG for publication as an
Informational RFC.

Jun 02 	Initial ID on 'Next Step QoS Signaling'.

Jul 02 	Submit 'Analysis of existing signaling protocols' to IESG for
publication as an Informational RFC.

Sep 02 	Submit 'Framework signaling architecture' to IESG for publication as
an Informational RFC.

Sep 02  	If the initial analysis and framework do not meet two
criteria, submit a rechartering request to the IESG.
The criteria are:  the use of a minimized version of RSVP has been fully
evaluated; the potential of the NSIS work to be a tool box or building piece
for revised or new signaling in non-QoS areas has been covered by the
framework.

Oct 02	If criteria were met, submit 'Next Step QoS Signaling' as a
standards track RFC.

---

From: [email-masked]
Date: Fri, 9 Nov 2001 06:00:26 +0200

Hi Xiaoming,

> Since the selection of QoS parameters depends on the 
> IS,DS,...x-serv mechanisms in different domains, I would 
> suggest to add one item into the charter:
> develop the mapping rules/interface rules between such x-serv 
> mechanisms and the desired QoS signaling protocol/component. 

I agree that this is important, but I do not think this
should be covered in the initial version of the charter.
This work could be added in a re-chartering of NSIS after
the initial goals are met.

> How about policy protocols like COPS? Now that it's stated 
> that the resource allocation mechanisms are admistrative-related 
> and out of the scope of (current) NSIS, the policy control may 
> be of concern (otherwise whom will this QoS signaling
> protocol be going to collaberate with?:)).

Again, you raise an important point, but I think this topic
should be left for later work.  I think that if we attempt
a too broad scope, we run the risk on not being able to
accomplish our goals.

best regards,
John

---

From: [email-masked]
Date: Fri, 9 Nov 2001 10:34:06 +0200

Hi Georgios,

> where the NSIS solution will be applicable and where not!

Depending on what input we have into the meeting (internet
drafts), we shall see what sort of discussion we will
have.  I believe it will be premature to start
discussing solutions until after we have at least the
version 00 of the requirements document published.

John

---

From: [email-masked]
Date: Fri, 9 Nov 2001 10:38:29 +0200

Hi Brian,

> > This working group will develop the requirements, 
> > architecture and protocols for the next IETF steps 
> > on signaling QoS. The working group will use
> > existing IETF signaling as the basis for this work.  

> Although the wordings above are not incorrect, it is quite 
> possible they could be misconstrued.
> - You are developing requirements, archiecture and protocols - okay. 
> - You will use existing IETF signalling as the basis - surely this
> depends on that signalling being suitable for the requirements (and
> architecture) you develop. I think it needs some comment 
> about the basis
> "where it is feasible and applicable", and that decision would seem to
> be within the scope of the WG based on the first sentence.

No comment is needed. Discussions between myself, the Area
Directors and the IESG have concluded that NSIS will start
with the basic understanding that existing IETF signaling
protocols will be considered as the starting point for
any protocol work that takes place in NSIS.  We will be 
free to suggest modifications & enhancements, but it is 
not permissable to start the protocol work on a blank 
sheet of paper, unless we can show that is the only way
we can meet our requirements.

> Also, the statement that to me could be interpreted as "it is the
> intention of the WG _not_ to invent new protocols". Again, I 
> agree with
> this direction _as_long_as_ the existing protocols do meet the
> requirements (and architecture) that is developed.

That is understood and noted in the charter.

best regards,
John

---

From: [email-masked]
Date: Fri, 9 Nov 2001 11:11:28 +0200

Hopefully the discussion will start on this list already before the meeting
so that the meeting time will get used on issues not possible to solve
here...

	Jarno

> From: ext Georgios Karagiannis (ELN)
> [mailto:[email-masked]]
> Sent: 8. marraskuuta 2001 14:25
> To: [email-masked]'
> Subject: RE: [NSIS] Update NSIS Charter (v 1.3)
> 
> 
> 
> Hi John
> 
> Archive: 
> www.ietf.org/mail-archive/working-groups/nsis/current/maillist.html
> 
> 
> beyond the scope
> architecture and protocols

---

From: "Georgios Karagiannis (ELN)" <[email-masked]>
Date: Fri, 9 Nov 2001 11:04:19 +0100

Hi Jarno

If the discussion is focused on requirements, yes!

best Regards,
Georgios

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: vrijdag 9 november 2001 10:11
To: [email-masked]
Subject: RE: [NSIS] Update NSIS Charter (v 1.3)

	Jarno

---

From: Bob Braden <[email-masked]>
Date: Wed, 14 Nov 2001 20:52:42 GMT

*> 
  *> Quite a bit of work has been done on Quality of Service and resource
  *> reservation for the Internet.  For a number of reasons, however, there has
  *> not been a significant amount of end-to-end QoS deployed on the Internet
  *> other than best effort service.  
  *> 
  *> It is noted that resource reservation and traffic engineering can be
  *> considered as part of network administration, and therefore beyond the scope
  *> of the IETF to mandate a particular mechanism.  When considering end-to-end
  *> communication, it is likely that several administrative domains are
  *> traversed.  Interworking between domains in which different QoS solutions
  *> solutions are deployed is problematic. Mobility and roaming additionally add
  *> complexity to the overall picture.

John,

So far, I followed you. But the next sentence does not seem to follow
from what preceded it.

  *>                                     This creates a need for a simplified
  *> solution of signaling QoS, one that reuses parts of existing methods.  This

It would be much better if you said what "existing methods" you mean; that
will help define the scope.  As one of the principal designers of one
"existing method", I wonder whether you mean the Signaling Protocol Whose
Name Cannot be Spoken in PC Internet Circles...  Or ???

I wish I thought this was a technical judgment, not just an empty
political statement.

  *> will allow users to obtain QoS-aware services, irrespective of underlying
  *> mechanisms used.

I believe you are skirting the edge of wishful thinking here.  In the QoS
field, there has been an awful lot of wishful thinking and throwiing
around of fine-sounding phrases that in fact mean nothing technically.
It is simply nonsense to talk about "QOS-aware services" if different
parts of the path use incompatible service models.

  *> 
  *> This working group will develop the requirements, architecture and protocols
  *> for the next IETF steps on signaling QoS. The working group will use

Wow!  That is quite a task.  I assume you are alloting about 5 years to
this WG.

Again, what existing signaling?

  *> existing IETF signaling as the basis for this work.  Additionally, the
  *> working group will consider how to signal QoS (what sort of QoS parameters
  *> to use), and where to signal (end-to-end, end-to-edge, end-to-proxy,

"What sort of QoS parameters to use" means the service model?

I have a great ideal for a simple QoS parameter set: one parameter
called "niceness".  It has the advantage that every provider can do
it.  You could have a scale of niceness = 0 to 63, for example.  Or,
no, let's make it even simpler... lets have a binary niceness
parameter, with values zero and one.  Ooops, I just reinvented the
Controlled Load service model of int-serv.

  *> edge-to-edge, etc.). As input to the working group, the Mobile IP QoS
  *> Requirements document  (draft-mobileip-qos-requirements) will be considered
  *> as one starting point for developing the overall set of requirements.  The
  *> working group will not limit itself to mobile IP-only QoS signaling needs,
  *> however, but will consider general cases of signaling QoS in the Internet
  *> (both wired and wireless). Consideration will be given to the idea of a
  *> building block structure, so the group could develop elements for QoS
  *> signaling that could be modular and be combined with a different payload or
  *> different proxy (e.g.) for use by a non-QoS signaling function. The added
  *> function will be out of scope, but the openness of the design (which may be
  *> a new version of RSVP) will be in scope.

Oh! OH! You spoke the dreaded word.

But I am totally mystified by the sentence that contains it.  What does
it mean?

  *> 
  *> This working group will focus on providing (QoS) signaling function to a
  *> local access network and end-to-end signaling.  It is not the intention of
  *> this working group to invent new signaling protocols. Additionally, mobility
  *> protocols and AAA work are out of scope of the working group.  The work
  *> produced in this Working Group should work with existing IETF mobility and
  *> AAA protocols, including (but not limited to) Mobile IP, SeaMoby Context
  *> Transfer and Diameter.
  *> 
  *> As with nearly all work being done in the IETF, security is a very important
  *> concern for NSIS.  The working group will study the security requirements
  *> for QoS Signaling, as well as create a threat analysis of QoS signaling.
  *> Compatibility with authentication and authorization mechanisms is also a
  *> concern.  These topics will be addressed in the Signaling Requirements
  *> document.
  *> 

I suggest that the security issue alone will take you 3 years, if you do
nothing else!

  *> This working group will provide the framework for interworking with existing
  *> resource allocation methods.  It is a non-goal of the working group to
  *> develop new resource allocation protocols.    
  *> 
  *> The working group will coordinate with a number of other IETF working
  *> groups, including Diffserv, Seamoby, Mobileip, AAA, Midcom and RAP.  It will
  *> also welcome participation and expression of requirements from non-IETF
  *> standards organization members, for instance 3GPP and 3GPP2 and ITU-T.
  *> 
  *> Goals and Milestones:
  *> =====================
  *> 

It's par for the course, but the schedule seems totally unrealistic.

  *> Jan 01	Initial ID on Signaling Requirements.
  *> 
  *> Feb  01	Initial ID on Analysis of existing signaling protocols.
  *> 
  *> Mar 02	Initial ID on 'Framework Signaling Architecture.'
  *> 
  *> Jun 02 	Submit 'Signaling Requirements' to IESG for publication as an
  *> Informational RFC.
  *> 
  *> Jun 02 	Initial ID on 'Next Step QoS Signaling'.
  *> 
  *> Jul 02 	Submit 'Analysis of existing signaling protocols' to IESG for
  *> publication as an Informational RFC.
  *> 
  *> Sep 02 	Submit 'Framework signaling architecture' to IESG for publication as
  *> an Informational RFC.
  *> 
  *> Sep 02  	If the initial analysis and framework do not meet two
  *> criteria, submit a rechartering request to the IESG.
  *> The criteria are:  the use of a minimized version of RSVP has been fully
  *> evaluated; the potential of the NSIS work to be a tool box or building piece
  *> for revised or new signaling in non-QoS areas has been covered by the
  *> framework.
  *> 
  *> Oct 02	If criteria were met, submit 'Next Step QoS Signaling' as a
  *> standards track RFC.
  *> 
One year to develop requirements, architecture, and protocol?
You can't be serious.

QoS is a hard problem.  That's why is has taken so long.  Many people
are not willing to face up to that fact, which is why there is so
much garbage written about it.

Bob Braden

---

From: [email-masked]
Date: Mon, 19 Nov 2001 10:45:34 +0200

Hi Kathy,

> Although it's important to define what a user is going to get from
> QoS, it's at least as important to figure out how a network can
> deliver it. Too much user-emphasis can lead to coming up with
> signalling semantics that let the user "ask for" something which
> the network cannot deliver. To me, this goes along with the paragraph
> above, from Bob Braden: that is, what the user has to signal for
> something that a network provider can actually deliver and the
> properties of that "quality of service" must be quantifiable since
> the internal mechanisms of how the quality level is accomplished
> are unlikely to be exposed. I'd like to see some emphasis on just
> *what* is being signalled for, and some existence proof that it
> is realizable.

I agree with you - one could ask for much without hope of
receiving it (kind of like my son at Christmas time).  I'd hope
that we would strike a balance between what is reasonable to
ask for and what is reasonable to provide.

br,
John