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

From: "Gary Kenward"<[email-masked]>
Date: Sun, 27 Jan 2002 12:47:59 -0500

David:

  I agree with your definition of an application for this
work, namely use cases. Keep in mind there has been a thread
on "adaptive applications", which is an entirely different kind
of application.

  I find use cases a very useful tool, when properly used ;^}.

Gary

> -----Original Message-----
> From: David Partain [mailto:[email-masked]]
> Sent: January 25, 2002 10:42
> To: 'NSIS Mailing List'
> Subject: Re: [NSIS] Framework & requirements part of the "Two kinds of
> requirements" thread
> 
> 
> Greetings all,
> 
> > On Thursday 24 January 2002 17:17, Gary Kenward wrote:
> > I don't believe that anyone has proposed "kitchen sink" or
> > 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
> > solve enough of the problem to be useful.
> 
> 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
> > that the framework will be evolve significantly.
> 
> 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
> 
> _______________________________________________
> nsis mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nsis
>

---

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

Ping,

Please see my comments below.

Marco

> From: Ping Pan [mailto:[email-masked]]
> Sent: Thursday, January 24, 2002 5:10 PM
> To: Paulo Mendes
> Cc: [email-masked]; [email-masked]; NSIS
> Paulo,
> How are you!
> Paulo Mendes wrote:
> >> Also, let's be careful with adaptive applications. They 
> look very nice 
> >> on paper, but when you see what type of switches are used 
> interfacing 
> >> between voice networks and the Internet, you gotta be 
> kidding me to 
> >> insist on adaptiveness for your traffic....
> > 
> > 
> > 
> > [PM] I don't know about others, but when I speak about adaptive 
> > applications I'm thinking of 100% IP networks.
> > 
> 
> 
> The problem is that much of the voice traffic flowing over 
> the Internet 
> has nothing to do with the native Internet applications. Many 
> providers 
> setup tunnels through their backbones and transport non-IP 
> packets. The 
> access points are not pure IP boxes. They may be some ancient and 
> expensive Luent switches. If you ask the switches to run some fancy 
> adaptive schemes to all the traffic, they may crash.
> 
> > 
> >> 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.

[MS] If we think we can charge extra for it then we will do it. As you well
know the user is not going to care whether the reservations in the network
are hop by hop or there is overprovisioning or whatever, as long as the QOS
is met.  We will let users tell us "how much to reserve".

> > 
> > 
> > 
> > [PM] Allow me to disagree... Are you mentioning US over-provided 
> > networks, or networks in other geographic locations? And 
> even if you're 
> > only thinking in an US Internet, can you tell me how can this 
> > over-provision take place?
> 
> 
> (I thought I wrote a paper on this in my past life....:-)) Yes, all 
> backbones have "hot" spots, and have congestion. But the backbone 
> problems can be (or have been) addressed via RSVP-TE. Yes, we have 
> short-time outage in the backbone due to frequent upgrade and router 
> crash. That's why we have worked very hard on backbone traffic 
> redundency (fast reroute, graceful restart.....) issues. So 
> far, I have 
> a pretty good feeling on resource management within the backbone. The 
> focus is now on the edge and the access. I am hoping NSIS is 
> the place 
> to do it.
> 
> 
> > I agree that network providers can't engineer their network 
> to satisfy 
> > every single client reclamation. That's why clients 
> (receivers) with 
> > adaptive applications are useful to network providers. The network 
> > notify about their capabilities and the clients deal with 
> it (adapt, 
> > leave session, ...).
> 
> 
> The "receivers" can be some monitoring boxes arranged by the 
> providers 
> to monitor the traffic in/out of the network. If things are not OK, 
> these boxes may play some rotuing tricks to redirect traffic from the 
> edge. I am not sure they are regular users.
> 
> 
> > 
> >> 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? ....
> > 
> > 
> 
> > 
> > [PM] Okey.. But if network providers don't develop new 
> services how can 
> > they expect clients to use them, if they don't exist?
> > 
> 
> 
> I have just listed some of the services below. IMHO, the 
> current state 
> of the Internet is not about "new" services, or "new" economy to that 
> matter. The Internet is a new media to transport traffic, 
> like we have 
> been doing via post office, SNA, phone networks, Frame/ATM 
> networks.... 
> The trick is to send the same old information efficiently.... 
> Plus the 
> Internet needs to evolve itself to carry traffic some future 
> applications when they come..
> 
> 
> > 
> >> - 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? :-)
> >>
> 
> - Ping
> 
>