Subject: RE: [NSIS] Framework & requirements part of the "Two kinds of req uirements" thread

From: "Chen, Weijing" <[email-masked]>
Date: Thu, 24 Jan 2002 02:43:16 -0600

I have fundamental disagreement with David's point.

1. David's proposal of working requirement within so called "framework" is
putting the cart before the horse. Because we think one framework is cool,
we confine our requirements and use cases within that framework. It is
totally unacceptable.

2. 

|-----|                                                  |-----|
|ehost|<------------------------------------------------>|ehost|
|-----|                                                  |-----|
|     |                                                  |     |
|-----|            |-----|            |-----|            |-----|
|eedge|<---------->|eedge|<---------->|eedge|<---------->|eedge|
|-----|            |-----|            |-----|            |-----|
|     |            |     |            |     |            |     |
|-----|   |----|   |-----|   |----|   |-----|   |----|   |-----|
|ehop |<->|ehop|<->|ehop |<->|ehop|<->|ehop |<->|ehop|<->|ehop |
|-----|   |----|   |-----|   |----|   |-----|   |----|   |-----|
 host    interior   edge    interior   edge     interior  host
         w/in domain       w/in domain        w/in domain

In above picture, [host] has to assemble and process the [ehop], [eedge] in
addition to [ehost] part. How will the [host] correctly assemble and process
the [ehop] and [eedge] pieces? It implies that [host] has global view of
[ehop] and [eedge] in every domains. For this to happen, there must be
another protocol to exchange network information and pass whole network view
to [host]. So on, and so on, and sooner we know that we revive an ultimate
engineer dream: a protocol for all and do all. Be there, done that, and
failed. Otherwise we wouldn't be here to debate about what NSIS should be.

The right picture should be (if you insist talking about the framework
before requirement):

                   |-----|   |----|   |-----|  
                   |ehop |<->|ehop|<->|ehop |   
                   |-----|   |----|   |-----| 
                   |     |            |     |
                   |-----|            |-----|
                   |glue |            |glue |
                   |-----|            |-----|
                   |     |            |     |
|-----|            |-----|            |-----|            |-----|
|ehost|<---------->|ehost|<---------->|ehost|<---------->|ehost|
|-----|            |-----|            |-----|            |-----|
 host                edge     hop      edge                host
           domain            domains             domain
                             (inter and
                              intra)
           NSIS                                   NSIS

Now what about "glue"? Shall NSIS do it? Part of me says yes, another says
no. I am 50/50.

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

-----Original Message-----
From: David Partain [mailto:[email-masked]] 
Sent: Wednesday, January 23, 2002 3:58 AM
To: NSIS Mailing List
Subject: [NSIS] Framework & requirements part of the "Two kinds of
requirements" thread

Greetings all,

I'd like to offer my take on part of the thread "Two kinds
of requirements" to see if we can collectively reach any sort
of conclusion based on what's been written.  I doubt I'll say
anything new, but perhaps it'll help summarize a bit.

To cut to the chase, the conclusion of this mail is that
I think:

 - we should use the "framework" below as the starting point of
   framework discussions
 - the requirements should grow from use cases of particular
   applications that will use the network

The original mail postulated that people are wanting to work
on two kinds of requirements here:

 - end-host to end-host, or application to application
   signalling

 - transport level signalling

From that point, there has been a hearty debate about whether
this indeed is true, as well as a host of other issues.

I think the following points have been made, amongst others:

 - It should support the use of throughput adaptive applications
   and the ability for a traffic flow to express its QoS
   preferences with regard to the throughput values which it
   may be allocated.

 - One part of the thread was about whether RSVP and related
   work (e.g., RFC 2998), or perhaps SDPng, are suitable
   solutions.  While it's obvious that we need to learn from
   and perhaps start from one of these efforts in working on
   NSIS, it also seems clear that we shouldn't start working
   on that until the requirements are done.

 - There's no chance we'll create a single one-size-fits-all
   application-related signalling protocol that will be used
   by everyone.  That seems very clear.

 - There's a need for something transport independent that can
   help signal QoS needs across multiple domains in order
   to help the application-related signalling protocols do
   their thing.

The big issue there is what part of this we should solve here.
Should we concentrate specifically on the application/host
to network signalling?  I think not and others have agreed.
Should we try to design something that goes end to end?  If we
do that, do we have a "chicken and egg" problem of needing to
have the technology everywhere for things to work?

A case has been made that the goal should be to create a
signalling protocol that has different kinds of components
appropriate to different parts of the problem.  Georgios K.
proposed the following figure, which I like quite a lot and
which others have said is good, as a way of looking at it:

|-----|                                                  |-----|
|ehost|<------------------------------------------------>|ehost|
|-----|                                                  |-----|
|     |                                                  |     |
|-----|            |-----|            |-----|            |-----|
|eedge|<---------->|eedge|<---------->|eedge|<---------->|eedge|
|-----|            |-----|            |-----|            |-----|
|     |            |     |            |     |            |     |
|-----|   |----|   |-----|   |----|   |-----|   |----|   |-----|
|ehop |<->|ehop|<->|ehop |<->|ehop|<->|ehop |<->|ehop|<->|ehop |
|-----|   |----|   |-----|   |----|   |-----|   |----|   |-----|
 host    interior   edge    interior   edge     interior  host
         w/in domain       w/in domain        w/in domain

   ehost = everyhost
   eedge = everyedge
   ehop  = everyhop

NSIS protocol decomposition:

 * A "host" could be an end host or a proxy.  It can process
   and use the "everyhost", "everyedge", and "everyhop"
   protocol components.

 * An "edge" can be a Diffserv edge, MPLS edge, etc.  It can
   process and use the "everyedge", and "everyhop" protocol
   components. The "everyhost" protocol component is not
   processed (used or checked) but is carried onward.

 * An "interior within domain" can be any router within
   a domain.  It can process and use only the "everyhop"
   protocol component.  The "everyhost" and "everyedge"
   protocol components are not processed (used or checked)
   but are carried onward.

The everyhop bit within a domain provides signalling facilities
for that particular domain and is very likely to differ from
the everyhop bit used in the next boarding domain.

The point of all of this is to get a concatenation of results.
Each domain is responsible for taking its own decisions in its
own domain-specific ways.  The concatenation of the everyhop
decisions within a domain provides the domain's answer.
The concatenation of the domains' results gives and end to
end answer that can be used by the everyhost bit.

I think that having this overall framework -- for lack of a
better term -- in mind is very helpful.

If we can agree that this is a reasonable framework to use as
the basis of discussion, I think that what we need to do is
to produce a set of requirements for different "applications"
that will use these networks/this framework.  Indeed, I believe
this matches Keith Allen's request that requirements be based on
use cases.  If we know we're going to use the NSIS protocol on
a cellular wireless network (just to pull an example out of the
air :-)), then that "use case" implies a set of requirements.
A different scenario (e.g., the core of the network) implies
another set of requirements.

I personally think this is the right way forward and would
like to see this group move in this direction.

Georgios added some more thoughts on this topic
which addressed the applicability and prioritization
of work.  That can be found in the archive at
http://www1.ietf.org/mail-archive/working-groups/nsis/current/msg00418.html

I realize that I haven't covered everyone's particular topic
in this thread, but perhaps it'll help focus on one part of
the discussion.  If someone wants to summarize some other
sub-thread, that would be great...

Cheers,

dlp

ps. I think it would be very useful if Subject lines could more
accurately reflect the topic covered in the mail.  Long threads
with the same subject and covering a multitude of topics is
difficult to follow...

_______________________________________________
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: "Georgios Karagiannis (ELN)" <[email-masked]>
Date: Thu, 24 Jan 2002 10:32:42 +0100

Hi Weijing

Please see my comments in line.

[WC]>> 1. David's proposal of working requirement within so 
[WC]>> called "framework" is putting the cart before the horse. 
[WC]>> Because we think one framework is cool,
[WC]>> we confine our requirements and use cases within 
[WC]>> that framework. It is totally unacceptable.

In principle I agree with you. The framework should not be used
to  define the NSIS requirements. The NSIS requirements should be
produced based on different QoS needs of certain application types.
However, the mentioned framework can be used to decompose a 
complex QoS problem into certain simpler QoS problems.

[WC]>> 2. Figure
[WC]>>  In above picture, [host] has to assemble and process 
[WC]>>  the [ehop], [eedge] in addition to [ehost] part. How will 
[WC]>>  the [host] correctly assemble and process
[WC]>> the [ehop] and [eedge] pieces? It implies that [host] has 
[WC]>> global view of [ehop] and [eedge] in every domains. 
[WC]>> to happen, there must be another protocol to exchange network 
[WC]>> information and pass whole network view
[WC]>> to [host]. 

No it is not required that the "host" has a global view 
of the domains. The way of how this NSIS protocol finds the edges
and the hops is similar with the way the RSVPv1 protocol does it.

[WC] >> Now what about "glue"? Shall NSIS do it? Part of me 
[WC] >> says yes, another says
[WC] >> no. I am 50/50.

Please note that the NSIS charter mentions that a "framework" 
draft should be specified by March 2002.

Best regards,
Georgios

-----Original Message-----
From: Chen, Weijing [mailto:[email-masked]]
Sent: donderdag 24 januari 2002 9:43
To: [email-masked]
Cc: NSIS Mailing List
Subject: RE: [NSIS] Framework & requirements part of the "Two kinds of
req uirements" thread

2. 

|-----|                                                  |-----|

                   |-----|   |----|   |-----|  

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

-----Original Message-----
From: David Partain [mailto:[email-masked]] 
Sent: Wednesday, January 23, 2002 3:58 AM
To: NSIS Mailing List
Subject: [NSIS] Framework & requirements part of the "Two kinds of
requirements" thread

Greetings all,

|-----|                                                  |-----|

   ehost = everyhost
   eedge = everyedge
   ehop  = everyhop

Cheers,

dlp

---

From: "Freytsis, Ilya" <[email-masked]>
Date: Thu, 24 Jan 2002 11:45:00 -0500

Weijing,

I like your diagram much better than original one and agree with you that
detailed Use Cases should lead to the diagram of this sort not the other way
around.
I want to comment on your "glue" - it looks to me very much as an adaptation
layer to the domain specific QoS technology in use. From this perspective I
would say NO, NSIS should not deal with it.  Though it should not prohibit a
QoS technology re-use NSIS if it finds it useful.

Ilya Freytsis

From: "Chen, Weijing" <[email-masked]>
To: [email-masked]
Cc: NSIS Mailing List <[email-masked]>
Subject: RE: [NSIS] Framework & requirements part of the "Two kinds of
requirements" thread
Date: Thu, 24 Jan 2002 02:43:16 -0600

2. 

|-----|                                                  |-----|

                   |-----|   |----|   |-----|  

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

---

From: "Schneider, Marco" <[email-masked]>
Date: Thu, 24 Jan 2002 16:45:54 -0600

Hi Georgios,

Please see my comments inline.

> From: Georgios Karagiannis (ELN)
> [mailto:[email-masked]]
> Sent: Thursday, January 24, 2002 3:33 AM
> To: Chen, Weijing
> Cc: NSIS Mailing List

[MS] So we are in agreement in principle. 

> and the hops is similar with the way the RSVPv1 protocol does it.

[MS] So going back to my comments in a previous email, the "framework" does
have an implementation/solution in mind along the lines of RSVP and imposes
this on the host. Not only is this getting the cart before the horse, but I
am not even sure I like what's in the cart. Or is there something that has
still not been clarified? 

> draft should be specified by March 2002.

[MS] To the extent that the "framework" draft will include possible
approaches to solving the problem we can include yours for comparison. I
think that is where it may fit in.

Cheers,

dlp

---

From: "Chen, Weijing" <[email-masked]>
Date: Thu, 24 Jan 2002 21:58:41 -0600

Georgios,

>>produced based on different QoS needs of certain application types.

Thank you.

>>and the hops is similar with the way the RSVPv1 protocol does it.

So we still expose the network interior to host. Then what is the benefit of
this for host? Compare the following stacks that the host has to handle:

|-----|
|ehost|
|-----|
|     |
|-----|
|eedge|
|-----|
|     |
|-----|
|ehop |
|-----|
 host    

vs.

|-----|
|ehost|
|-----|
 host                

Cleary the latter one is much simpler.

Now let's take a look what is the typical sequence of end-to-end QoS service
delivery chain:

[src ehost]->hello, edge, I want so and so [original QoS] to so and so
place.
[incoming eedge]->ok, host, just a millisecond.
       [background] glueing the [original QoS] to [ehop QoS] in first
[ehop], 
                    [ehop] passes [ehop QoS] and [original QoS] to next
                    [ehop], on and on to outgoing [eedge].
[outgoing eedge]->hello, ehost, here is [original QoS] request from
                  [src ehost], will you take it?
[dest ehost]->ok, accept.
[outgoing eedge]-->[ehop]-->[incoming eedge]...
[incoming eedge]->host, you are ready to go.
[src ehost]->ok...

In the above sequence, [ehost] only deals with [eedge] directly, not [ehop].
So why do we want to force [ehop] information (i.e. network internal
information) to [ehost]? If we are doing so, [ehost] would say "Ooo, I am
stuffed, choked, ok, I am giving up. I don't want QoS." Which is exactly
where we are today.

So please don't stuff the poor [ehost] with anything else except he
absoultly need for [ehost] to [eedge] request and response. Thank you very
much.

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

-----Original Message-----
From: Georgios Karagiannis (ELN)
[mailto:[email-masked]] 
Sent: Thursday, January 24, 2002 3:33 AM
To: Chen, Weijing
Cc: NSIS Mailing List
Subject: RE: [NSIS] Framework & requirements part of the "Two kinds of req
uirements" thread

Hi Weijing

[WC]>> 2. Figure

Best regards,
Georgios

-----Original Message-----
From: Chen, Weijing [mailto:[email-masked]]
Sent: donderdag 24 januari 2002 9:43
To: [email-masked]
Cc: NSIS Mailing List
Subject: RE: [NSIS] Framework & requirements part of the "Two kinds of
req uirements" thread

2. 

|-----|                                                  |-----|

                   |-----|   |----|   |-----|  

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

-----Original Message-----
From: David Partain [mailto:[email-masked]] 
Sent: Wednesday, January 23, 2002 3:58 AM
To: NSIS Mailing List
Subject: [NSIS] Framework & requirements part of the "Two kinds of
requirements" thread

Greetings all,

|-----|                                                  |-----|

   ehost = everyhost
   eedge = everyedge
   ehop  = everyhop

Cheers,

dlp

---

From: "Georgios Karagiannis (ELN)" <[email-masked]>
Date: Fri, 25 Jan 2002 14:10:37 +0100

Hi Weijing and Marco

I will just repeat some text from the proposed framework:

   protocol components

Example _1: Suppose that a network provider is managing an overprovisioned 
network and is willing to provide to its end users applications that 
require end to end QoS support (e.g., telephony).
This provider may choose to use the (NSIS) protocol 
on an "end host to end host" basis. In this case 
the "host" will not use (activate) the "everyedge" 
and "everyhop" components, since they are not required.
Therefore, all edges and hops in the network will not process this 
type of NSIS protocol. Thus the NSIS message will only be processed 
by the end hosts. This is identical to the ("simple") example used
by Weijing.

Example_2: Now suppose that the network consists of overprovisioned 
access networks (managed by one provider) and by many concatenated 
QoS domains that are overprovisioned
but they are managed by different network providers.

Assume that the end user will like to use the "end host 
to end host" type of NSIS protocol for this purpose.
In this case the "host" will only activate the [everyedge] 
component, which will include 
QoS information that is needed by an edge of a domain. 
The [everyhop] component will not be activated, and therefore,
it will not be processed by any router located within the 
overprovisioned access network. Thus, the interior nodes 
located within the overprovisioned access network will not use 
the NSIS message.

The first edge node of a domain that will receive the NSIS message
will only use the [everyedge] information. Please note
that the edge node may change (replace) the [everyedge]
information.  If within this domain 
none existing QoS mechanism, e.g., Intserv/MPLS/overprovisioning,
are used, then the edge (of course this depends on the 
policy of the provider of the domain) will activate and include 
information into the [everyhop] component. Every hop within this 
domain will only use the [everyhop] component included in 
the NSIS message.

The same principles could be applied to all other domains 
wherein the NSIS message will pass through in its way to the 
receiving end host.

This example shows that by using the proposed framework
the NSIS protocol will be used (and checked) only (and only) by the 
nodes that need to use it. In this way the protocol can be 
processed fast and at the same time provide a reasonable level 
of QoS signaling functionality.

Best Regards,
Georgios

-----Original Message-----
From: Chen, Weijing [mailto:[email-masked]]
Sent: vrijdag 25 januari 2002 4:59
To: 'Georgios Karagiannis (ELN)'
Cc: NSIS Mailing List
Subject: RE: [NSIS] Framework & requirements part of the "Two kinds of
req uirements" thread

Georgios,

Thank you.

|-----|
|ehost|
|-----|
|     |
|-----|
|eedge|
|-----|
|     |
|-----|
|ehop |
|-----|
 host    

vs.

|-----|
|ehost|
|-----|
 host                

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

-----Original Message-----

Hi Weijing

[WC]>> 2. Figure

Best regards,
Georgios

-----Original Message-----
From: Chen, Weijing [mailto:[email-masked]]
Sent: donderdag 24 januari 2002 9:43
To: [email-masked]
Cc: NSIS Mailing List
Subject: RE: [NSIS] Framework & requirements part of the "Two kinds of
req uirements" thread

2. 

|-----|                                                  |-----|

                   |-----|   |----|   |-----|  

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

-----Original Message-----
From: David Partain [mailto:[email-masked]] 
Sent: Wednesday, January 23, 2002 3:58 AM
To: NSIS Mailing List
Subject: [NSIS] Framework & requirements part of the "Two kinds of
requirements" thread

Greetings all,

|-----|                                                  |-----|

   ehost = everyhost
   eedge = everyedge
   ehop  = everyhop

Cheers,

dlp

---

From: "Chen, Weijing" <[email-masked]>
Date: Fri, 25 Jan 2002 10:47:50 -0600

>>   protocol components are not processed (used or checked)

Weijing, etc:
* A "host" could be an end host or a proxy. It only assembles and
disassembles the "every host" component.
* A "edge" could be a Diffserv edge, MPLS edge, IP edge, ATM edge, etc. It
must process "every host" compnonent, preserve its original form, and carry
it onward. It must also assemble and disassemble "every hop" components
based on information from "every host" component (which could be called
"glueing" "every host" component to "every hop" component).
* A "hop" is always "interior within domain", It could be a router, a
switch, etc. It must disassemble, process, and re-assemble "every hop"
component. However, "every host" component are not processed but are carried
onward.

Do you agree to the above disagreement? If so, let's move forward and table
it as an onging issue.

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

-----Original Message-----
From: Georgios Karagiannis (ELN)
[mailto:[email-masked]] 
Sent: Friday, January 25, 2002 7:11 AM
To: Chen, Weijing; Schneider, Marco
Cc: NSIS Mailing List
Subject: RE: [NSIS] Framework & requirements part of the "Two kinds of req
uirements" thread

Hi Weijing and Marco

Best Regards,
Georgios

-----Original Message-----
From: Chen, Weijing [mailto:[email-masked]]
Sent: vrijdag 25 januari 2002 4:59
To: 'Georgios Karagiannis (ELN)'
Cc: NSIS Mailing List
Subject: RE: [NSIS] Framework & requirements part of the "Two kinds of
req uirements" thread

Georgios,

Thank you.

|-----|
|ehost|
|-----|
|     |
|-----|
|eedge|
|-----|
|     |
|-----|
|ehop |
|-----|
 host    

vs.

|-----|
|ehost|
|-----|
 host                

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

-----Original Message-----

Hi Weijing

[WC]>> 2. Figure

Best regards,
Georgios

-----Original Message-----
From: Chen, Weijing [mailto:[email-masked]]
Sent: donderdag 24 januari 2002 9:43
To: [email-masked]
Cc: NSIS Mailing List
Subject: RE: [NSIS] Framework & requirements part of the "Two kinds of
req uirements" thread

2. 

|-----|                                                  |-----|

                   |-----|   |----|   |-----|  

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

-----Original Message-----
From: David Partain [mailto:[email-masked]] 
Sent: Wednesday, January 23, 2002 3:58 AM
To: NSIS Mailing List
Subject: [NSIS] Framework & requirements part of the "Two kinds of
requirements" thread

Greetings all,

|-----|                                                  |-----|

   ehost = everyhost
   eedge = everyedge
   ehop  = everyhop

Cheers,

dlp

---

From: "Schneider, Marco" <[email-masked]>
Date: Mon, 28 Jan 2002 11:46:28 -0600

Georgios,

Thank you for clarifying the picture you presented. I still interpret that
you are imposing structure on the solution (albeit generalized which is a
good thing). 

1) It assumes the same functionality in the host as the edge for UNI
signaling: (The picture shows everyedge function in both host and edge, and
your discussion below seems to imply that this is what a host will use to
signal to the network for a QOS connection.)

2) It assumes a linear model of signaling and thus rules out alternative
hierarchical approaches. By linear I mean that whether hop by hop or edge to
edge it shows this occuring in order across a path. One hop/edge signals to
the next hop/edge. By hierarchical I mean that either the host (which I
don't advocate) or a network element signals the creation of multiple
segments which spliced together provide the end-to-end QOS. 

Marco

Cheers,

dlp