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

From: "Gary Kenward"<[email-masked]>
Date: Thu, 24 Jan 2002 11:17:09 -0500

I don't believe that anyone has proposed "kitchen sink" or
signalling that is not needed. I believe that there are a number
of very important problem areas that need to be addressed. At the
moment, the prevalent thread is whether all or many of these signalling
needs can be resolved with one protocol. There is a great risk in
attacking the problem in a piecemeal fashion: the result may not hold
solve enough of the problem to be useful.

Some specific comments:

  - if there is a need for a protocol to run end-to-end at the application
    layer without interacting with the network, then this can be resolved 
    in two ways: a separate protocol that is designed *only* for this 
    purpose; a protocol that can interact with a network, if the network
    is able and willing (i.e. has the functional and policy support).
 
    the first solution fulfils only one of the needs stated so far on this
    list, and implies a requirement for multiple signalling protocols to 
    set up the end to end *and* network QoS; on the plus side, it is a 
    self contained problem (by definition), independent upon network 
    architecture.

    the second solution is tougher because it requires a definition of
    a generic framework that will allow interaction between the end-to-
    end and entities within the network; on the plus side, it is likely 
    to be more efficient then the first solution.

  - implicit in Ping Pan's proposal is the idea that a useful signalling
    protocol will emerge out of the sequential development of hop-by-hop
    signalling (i.e. host to edge, node to node, edge to edge, etc.); this
    is somewhat like trying to build a jet engine one piece at a time, it
    will not work unless you have an idea where the pieces fit ahead of
time.

  - while I'm not entirely sure what Ping Pan means by an "application"
    (i.e. a usage scenario coupled with network services, a piece of
software)
    basing the design on a subset of applications may be the fastest way
    of generating a solution, but no likely the most useful in the long
term.

Finally, I support the idea of tackling a specific problem are first: my
preference being host to edge, but I strongly recommend that we make an
attempt
to define a strawman framework first. I emphasize "strawman" - the term
implies
that the framework will be evolve significantly.

I do not support the idea of using a subset of applications to design a
protocol.
I like the idea of using use cases, as long as they are acceptable to the
IESG,
and as long as they go beyond "user/end system interaction". 

Gary K.

> -----Original Message-----
> From: David Partain [mailto:[email-masked]]
> Sent: January 24, 2002 04:36
> To: NSIS Mailing List
> Subject: Re: [NSIS] Framework & requirements part of the "Two kinds of
> requirements" thread
> 
> 
> Hi all,
> 
> [Previous discussion clipped]
> 
> Ping Pan gave a very down-to-earth view of what we should be
> doing.  Thank you.
> 

*snip*

> > In conclusion, IMHO, NSIS should
> >
> > 1. focus on edge-to-edge signaling;
> > 2. focus on a small set of applications to deal with;
> > 3. focus on the relevant provider impact;
> > 4. don't do a kitchen-sink blahblah that lasts for years.
> 
> Thank you for helping to keep us focused.  I might perhaps
> put a heavier wireless emphasis on what you're saying, but I
> completely agree with it.
> 
> > 3 cents,
> 
> 2 eurocents.
> 
> Cheers,
> 
> dlp
> 
> _______________________________________________
> nsis mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nsis
>

---

From: David Partain <[email-masked]>
Date: Fri, 25 Jan 2002 16:42:07 +0100

Greetings all,

> On Thursday 24 January 2002 17:17, Gary Kenward wrote:
> signalling that is not needed.

Perhaps that is the case.  I guess my wariness grows out
of seeing folks in many contexts try to solve everything
in this rather complex problem area all at once.  Seen
individually, most of the ideas are likely a Good Thing, but
seen collectively, it's just too much.  I guess Ping is just
raising a red flag and I think that's useful.

> I believe that there are a number of very important problem
> areas that need to be addressed. At the moment, the prevalent
> thread is whether all or many of these signalling needs can be
> resolved with one protocol. There is a great risk in attacking
> the problem in a piecemeal fashion: the result may not hold

I certainly agree and wouldn't advocate piecemeal.  I just
_know_ that we won't solve everything now, even if we try.
As such, we need to solve what is most acute and put something
in place that makes solving later problems easier.

> Some specific comments:
> 
>   - if there is a need for a protocol to run end-to-end at the
>     application layer without interacting with the network,
>     then this can be resolved in two ways: a separate protocol
>     that is designed *only* for this purpose; a protocol
>     that can interact with a network, if the network is able
>     and willing (i.e. has the functional and policy support).
>     the first solution fulfils only one of the needs stated so
>     far on this list, and implies a requirement for multiple
>     signalling protocols to set up the end to end *and* network
>     QoS; on the plus side, it is a self contained problem
>     (by definition), independent upon network architecture.
> 
>     the second solution is tougher because it requires
>     a definition of a generic framework that will allow
>     interaction between the end-to- end and entities within
>     the network; on the plus side, it is likely to be more
>     efficient then the first solution.

I'm not sure that I've got all the implications of what you
write, but based on what I think I get, we need to work on the
latter of the two.

>   - implicit in Ping Pan's proposal is the idea that a useful
>     signalling protocol will emerge out of the sequential
>     development of hop-by-hop signalling (i.e. host to edge,
>     node to node, edge to edge, etc.); this is somewhat like
>     trying to build a jet engine one piece at a time, it will
>     not work unless you have an idea where the pieces fit
>     ahead of time.

No doubt about it.  We need the overall plan as well.

>   - while I'm not entirely sure what Ping Pan means by an
>     "application" (i.e. a usage scenario coupled with network
>     services, a piece of software) basing the design on a
>     subset of applications may be the fastest way of generating
>     a solution, but no likely the most useful in the long term.

As long as we can avoid doing something Fatally Dumb in terms
of extensibilty, it might be both the fastest way and useful
in the long term.

> Finally, I support the idea of tackling a specific problem
> are first: my preference being host to edge, but I strongly
> recommend that we make an attempt to define a strawman
> framework first. I emphasize "strawman" - the term implies

Yep.  This is one of our tasks.

> I do not support the idea of using a subset of applications
> to design a protocol.  I like the idea of using use cases,
> as long as they are acceptable to the IESG, and as long as
> they go beyond "user/end system interaction".

Perhaps I'm just missing something, but I see the applications
as use cases.  If I take the "application" of cellular mobile
telephony (only as one of the possible applications, folks :-)),
that provides a good use case for what we're defining.

Cheers,

dlp