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

From: David Partain <[email-masked]>
Date: Wed, 23 Jan 2002 10:57:38 +0100

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

---

From: Xiaoming Fu <[email-masked]>
Date: Wed, 23 Jan 2002 18:52:19 +0100

Hi David,

A great work to summarize these up-to-date discussions!

> have the technology everywhere for things to work?

IMO end to end is more desired in NSIS. To attain this we may 
allow signaling from host to edge, from edge to edge, from 
hop to hop, etc. As for the "chicken and egg" problem, I believe
some kind of "migration" may also be developed later, e.g., 
"NSIS tunnel" for non-NSIS clouds depending on the needs.

Regards,

Xiaoming

---

From: Ping Pan <[email-masked]>
Date: Wed, 23 Jan 2002 10:48:00 -0800

> "NSIS tunnel" for non-NSIS clouds depending on the needs.

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.

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....

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.

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.

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.

3 cents,

- Ping Pan

---

From: Xiaoming Fu <[email-masked]>
Date: Wed, 23 Jan 2002 20:37:27 +0100

Hi Ping,

My comment inline [XF].

Ping Pan wrote:
> to tell the routers how much to reserve. 

[XF]Are you assuming signaling carries only for quantitive, final-reserved 
resource parameters? Various QoS paradigms in routers could explain the 
contents in the signaling message differently.

> In fact, I doubt the providers

[XF]I think providers, at least access network providers, should listen 
to a QoS user's preference for what kind of traffic he's going to get/receive. 
And I guess one reason why QoS has not well-deployed is that no e2e QoS
mechanism/protocol is well-defined.

> flat-rate users? please), and this is the place where we may see
[XF]There might be incentive for core network providers to calculate/engineering 
how (roughly) the degree of e.g.,over-provisioning for traffic from/to 
access networks, if users/access network providers want e2e QoS.

> will never deploy some extra "stuff" inside the network. So what's worth

[XF]If traffic/user demanding e2e QoS is more and more popular, still no incentive?
Providers always tend to attract more users.

> 1. focus on edge-to-edge signaling;
same as host-edge? Furthermore inter-domain QoS signaling could serve for a 
final e2e protocol, just like the way how routing works for e2e traffic.

> 2. focus on a small set of applications to deal with;
[XF]I think for the sake of scalability, independence of specific applications 
(but may rely on some signaling description protocol e.g., SDPng) should be a 
goal for NSIS.

> 3. focus on the relevant provider impact;
[XF]From the technical point of view this is part of the edge to edge signaling, 
but I guess policy issues should be out of NSIS scope 

Xiaoming

---

From: Ping Pan <[email-masked]>
Date: Wed, 23 Jan 2002 12:38:05 -0800

> contents in the signaling message differently.

Signaling is signaling is signaling. What's been carried is not a 
consideration here.

> to a QoS user's preference for what kind of traffic he's going to get/receive. 

Provider's decision is based on how to make money. They subscribe users, 
and provide services to those users. The only thing that a user can do 
is to monitor its own traffic and complain if his/her service contact is 
not honored. Maybe this will change in the future, but not now.

> mechanism/protocol is well-defined.

Really? :-)

> Providers always tend to attract more users.

Providers tend to attract more users that are willing to pay more for 
the service. One of the lessons we have learnt from the dot-com is: 
providing nice things for free is a good way to be popular and make 
friends, but it is a lousy way to do business.

> final e2e protocol, just like the way how routing works for e2e traffic.

No! How does routing work for e2e? End users don't even see IGP, and 
never mind inter-domain. BTW, tell me, in the current networking 
enviornment, why providers want to do inter-domain QoS if the objective 
to keep the money-making traffic within their own networks as long as 
possible?

> (but may rely on some signaling description protocol e.g., SDPng) should be a 

Keep on dreaming at end hosts as long as the routers don't have to deal 
with it. :-)

- Ping

---

From: Michael Thomas <[email-masked]>
Date: Wed, 23 Jan 2002 12:45:59 -0800 (PST)

> not honored. Maybe this will change in the future, but not now.

   This seems to presuppose that provider/$$$ is what
   will drive qos deployment. Enterprise does not have
   the same economic goals, and signaled qos may very
   well be viable as a means of admission control and
   perhaps accounting. 

		       Mike

---

From: Rute Sofia <[email-masked]>
Date: Wed, 23 Jan 2002 16:11:07 -0500

>
 > Provider's decision is based on how to make money. They subscribe
 > users, and provide services to those users. The only thing that a user
 > can do is to monitor its own traffic and complain if his/her service
 > contact is not honored. Maybe this will change in the future, but not
 > now.
 >
True. But here we have the "chicken & egg" problem: providers subscribe
users and provide (supposedly) adequate services to users; however,
users will only subscribe a payed service if it prooves to really work.
More, users don't want to try something that is payed, they want
*assurance* about the quality of that service *before* they use it...so,
by that way of thinking we end up with BE again and don't need signaling...

 > friends, but it is a lousy way to do business.

Once again, we'll have the same problem; you mention "Dot.coms"; as
counter-example, we have the downloading of mp3...after napster, does
the same percentage of users gets/buys music streams? ...

This comments are just to mean that maybe we're deviating from the
goal...thinking what is the best way to please providers so QoS
mechanisms will be "fastly" deployed is not the solution.

I agree with:

- focusing on edge-to-edge signalling;
- study small set of applications and possibly adaptive behavior.

regards,

Rute

---

From: Ping Pan <[email-masked]>
Date: Wed, 23 Jan 2002 14:00:22 -0800

>    well be viable as a means of admission control and

Mike,

You are right about enterprise. I have overlooked things. Thank you!

- Ping

---

From: David Partain <[email-masked]>
Date: Thu, 24 Jan 2002 10:35:50 +0100

Hi all,

[Previous discussion clipped]

Ping Pan gave a very down-to-earth view of what we should be
doing.  Thank you.

> 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]

> 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.

> flat-rate users? please), and this is the place where we may see

I certainly agree that this where I think the most acute
needs are.

> 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

---

From: Paulo Mendes <[email-masked]>
Date: Thu, 24 Jan 2002 16:56:17 -0500

Hi Ping

Comments below [PM]

Ping Pan wrote:

>> IMO end to end is more desired in NSIS. To attain this we may allow 
>> signaling from host to edge, from edge to edge, from hop to hop, etc. 
>> As for the "chicken and egg" problem, I believe
>> some kind of "migration" may also be developed later, e.g., "NSIS 
>> tunnel" for non-NSIS clouds depending on the needs.
>>
> 
> 

[PM] Probably an approach "one solution fits all problems" isn't the 
best one. And I don't think (if I'm wrong, please correct me) that NSIS 
wants to signal all kind of traffic. That's why this discussion about 
requirements is needed.

> 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.

> signaling will fly in the present network.

[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 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, ...).
However network providers should listen to the market (let's say content 
providers) besides measuring their clients traffic, if they want to grab 
more clients.

> flat-rate users? please), and this is the place where we may see 

[PM] Probably we also need signalling between providers network 
(edge-to-edge?), since congestion probably will also take place there. I 
don't work for a network provider, so this is only a guess.

> will never deploy some extra "stuff" inside the network. So what's worth 

[PM] Okey.. But if network providers don't develop new services how can 
they expect clients to use them, if they don't exist?

> 3. focus on the relevant provider impact;

Network or content providers?

> 4. don't do a kitchen-sink blahblah that lasts for years.

Cheers
Paulo

-- 
| Paulo Mendes
| www.cs.columbia.edu/~mendes

---

From: Ping Pan <[email-masked]>
Date: Thu, 24 Jan 2002 15:09:34 -0800

Paulo,

How are you!

> 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.

>> 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.
> 
> 
> 

(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.

> notify about their capabilities and the clients deal with it (adapt, 

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? ....
> 
> 

> 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.
>>

- Ping

---

From: Xiaoming Fu <[email-masked]>
Date: Fri, 25 Jan 2002 20:17:14 +0100

Ping,

> adaptive schemes to all the traffic, they may crash.

If the number of fancy applications increases fast (so that an expected
revenue is generated - even more than the cost of updating the infrastructure), 
those switches will be motivated to be updated with more advance stuffs, 
although there might be a latency for deployment.

> edge. I am not sure they are regular users.

Kind of such "monitoring" could be a good tool for providers, but I think
for regular users as you pointed out, the best way is still to follow
a host-edge/host-host way to be defined within NSIS or NSIS++ work.

> >> traffic in a SNA network, and how much they have been charged? :-)

Besides, mobility traffic may be also part of the former two you mentioned 
above but belongs to the "new" services which needs extra "stuff".

Cheers,
Xiaoming

---

From: Paulo Mendes <[email-masked]>
Date: Tue, 29 Jan 2002 16:25:21 -0500

Hi Ping

Sorry the delayed answer... Comments are below [PM]

> 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....
>>
>>
>>
>>

I don't see the point of this example.. If a provider wants to setup 
tunnels to transport non-IP traffic between non-IP applications using 
not pure IP access points, that is not a concern of the IP world...

>> 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 
> (I thought I wrote a paper on this in my past life....:-)) 

Yes, I know, that why your pro over-provisioning comments were strange 
to me :-)

> Yes, all 

Here I agree with you.. We need edge-to-edge resource management and 
each provider should manage its domain resources.

> edge. I am not sure they are regular users.

Well.. When I said receiver I meant a final receiver of information, an 
application. Your point is different. A provider is free to monitor and 
re-route traffic inside its domain. However re-route traffic from 
neighbour provider A  to a provider B, isn't so ease. To start the 
contracts with providers A and B could not allow just re-routing..
So probably a provider should be happy to know that their receivers 
(clients, applications) can adapt to quality oscillations freeing the 
provider to the expensive job of re-routing traffic. This was my only 
point... The idea that a network provider can completely ignore their 
clients (provider of information or consumers of information) is wrong, 
IMHO.

>> [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 agree that the *old* services quality should be assured. However we 
already have *new* services that need support from the network, so its 
time to Internet to evolve (and NSIS is trying to help), since consumers 
will not keep buying services with poor quality.. To the list you 
presented I can add broadcast video services, like the timid ones we can 
see based upon the RealNetworks not scalable multi-rate technology and 
the so mentioned 3G services.

Cheers,

Paulo