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:01:38 -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.
> 
> > Before we define end-to-end, edge-to-edge and 
> domain-to-domain, ask the
> > following:
> >
> > - why do we signal in the first place?
> > - where do we need to signal?
> > - will signaling work in provider's networks?
> >
> > We signal because there is no QoS when we are using some 
> inter-active
> > real-time applications. Since most of the Internet traffic 
> is not within
> > the scope of this "inter-active" and "real-time", let's not 
> consider a
> > kitchen-sink signaling protocol.
> 
> If we try to throw every possible problem area into the NSIS
> work, this working group will still be talking when we're rolling
> out 8th generation mobile telephony :-)  We have to work very
> hard at limiting the scope of what we are trying to do.  Yes,
> everyone has their particular area of interest, and everyone's
> not going to be happy (I may be one of them).  But we _must_
> start by solving the most acute problems.  If we demonstrate
> competence at doing that, maybe we can move onto other problems
> later.
> 
> [clipped bit on adaptive applications]
> 
> > Currently, most of the backbone networks are over-provisioned, so no
> > serious signaling is required yet. End-to-end signaling is very
> > attractive to the end users, but the providers will not 
> allow the users
> > to tell the routers how much to reserve. In fact, I doubt 
> the providers
> > will listen to anything that end-user are throwing at them. So other
> > than some end-to-end measurement-based approach, I don't see e2e
> > signaling will fly in the present network.
> 
> "End-to-end signalling" doesn't necessarily imply that everyone
> in the path has to care.  That's what I think is so important
> about the framework picture that I sent out yesterday:  each
> domain decides how it's going to provide (or not) the quality
> of service being requested.  There are going to be those with
> Big Fat Pipes who may _never_ introduce any kind QoS mechanisms
> into their boxes.  Their domain-specific solution is
> overprovisioning, which is cool.  If their customers/partners
> agree to this (the business side of things), then we can still
> provide "end-to-end" QoS.
> 
> You want to provide QoS differentiation with DiffServ?  Fine.
> You want to do it with IntServ?  Fine.  You want to use traffic
> engineering with MPLS?  Fine.  You want to use it with YAFQoSP
> (yet another future QoS protocol)?  Fine.  Just give the "layer"
> above the answer so that we can build an end-to-end answer.
> 
> There is no alternative, in my view, to having end-to-end QoS
> as a product of the concatenation of domain-specific responses
> to QoS requests.  We will never have homogeneity.  If we don't
> create with this assumption in NSIS, I think we'll lose.
> 
> > The place where we need signaling is inside the access 
> networks. This is
> > the place where the providers have no incentive to 
> over-provision (to
> > flat-rate users? please), and this is the place where we may see
> > resource shortage.
> 
> I certainly agree that this where I think the most acute
> needs are.
> 
> > Finally, the providers are motivated by money to provide 
> any additional
> > service. Unless the traffic that they are carrying worth 
> something, they
> > will never deploy some extra "stuff" inside the network. So 
> what's worth
> > money? ....
> >
> > - voice traffic! I am not only talking about VoIP; I am 
> talking all the
> > voice traffic that use the Internet infrastructure.
> >
> > - wireless traffic: users packets are not landed inside the 
> backbone, so
> > the access network needs to do more to those flows.
> >
> > - VPN (an over-used term :-)): but some users want to have QoS
> > reservation even though they are sending any traffic. Not for any
> > technical reason, it's a business reason. Have you seen the 
> amount of
> > traffic in a SNA network, and how much they have been charged? :-)
> >
> > 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: Xiaoming Fu <[email-masked]>
Date: Thu, 24 Jan 2002 17:42:03 +0100

Gary, 

I agree with your explanation.

Cheers,
Xiaoming
> Gary Kenward wrote:
>     will not work unless you have an idea where the pieces fit ahead of time.
> 
>     (i.e. a usage scenario coupled with network services, a piece of software)
>     of generating a solution, but no likely the most useful in the long term.
> 
> 
> 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
> 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,