Subject: RE: [Diffserv] QoSSIG BOF

From: Lixia Zhang <[email-masked]>
Date: Sat, 22 Jan 2000 21:15:40 -0800

At 12:12 PM 1/22/00 , Yoram Bernet wrote:
> ......
>But - perhaps we don't need quite the leel of fucntionality offered by RSVP
>(e.g. full receiver heterogeneity, other things). I actually believe that
>there is some excess functionality built into RSVP that doesn't justify its
>compelxity. So - we can claim that RSVP tried to do too much, scrap it all
>and start over with another protocol that will be in development for five
>years. Alternatively, we can look at RSVP, ask where it can be simplified
>and how we might use a subset of it that is simpler and that achieves most
>of the functionality that we need. That's really what's been happenning over
>the last few years. We have been working to adopt from RSVP, those pieces
>which provide the functionality we need. 
>
>I hope that you folks that are proposing work on a new protocol are not
>doing so because you think that the fucntionality of RSVP can be achieed
>with a significantly lighterweight protocol. If you do - I think that you
>are casting in doubt the competence of those who created it. 

I personally would not think that way.

I agree that the current RSVP is complex.
I would also like to point out that RSVP did not start as complex, but
ended up there.

Over all these years participating in IETF ever since the very first
meeting, I've seen many best people put in their best effort in dealing
with Internet problems and developing solutions. However I must admit that
I have not found this process the right place to produce *simple* protocols.

For those who want a simple protocol: I am all for it, just that experience
has shown that setting up a BOF/WG is NOT the way to reach you goal.  My
personal suggestion would be to lock the door with a few friends till the
design is finished, then it'd be a better time to run a BOF to convince
others to go with you.

Lixia

---

From: Lloyd Wood <[email-masked]>
Date: Sun, 23 Jan 2000 13:09:14 +0000 (GMT)

> I have not found this process the right place to produce *simple* protocols.

Indeed. That's the same argument that Bruce Schneier raises
when reviewing IPsec and calling for half of it to be junked:

http://www.counterpane.com/ipsec.html

L.

> design is finished, then it'd be a better time to run a BOF to convince

<[email-masked]>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>

---

From: Ping Pan <[email-masked]>
Date: Sun, 23 Jan 2000 11:07:05 -0500

Sigh! The reality is that going through the entire IETF process is
taking longer and longer. Maybe we are getting too many people from the
old standard communities, people somehow are more interested in the
process rather than the technical "meat". ;-) Big companies start to
talk about "more IETF presence" while sending too many non-engineers (or
slideware engineers) to the Internet ENGINEERING Task Force meetings.

It's becoming more common that vendors are shipping products based on
the drafts: MPLS products are based on the drafts; the entire ISP
routing operation is based on a draft (draft-ietf-idr-bgp4-xx.txt). ;-)

I think we need a BOF if we all promise to get job done fast. Otherwise,
agree with Lixia, why not lock the door and start hacking?

2 more cents,

- Ping

--
Ping Pan         http://www.cs.columbia.edu/~pingpan

---

From: Tim Dorcey <[email-masked]>
Date: Sun, 23 Jan 2000 11:22:54 -0800

> design is finished, then it'd be a better time to run a BOF to convince

Absolutely!  I have noticed that the size of a problem space tends to grow
exponentially (factorially?) with the number of participants in a work group,
while the ability to devise a solution grows linearly at best.  Starting off with
the goal of filling some n-space is generally a recipe for failure.  But, a point
in n-space is still just a point:  simple solutions are possible by restricting
scope.  Then, 2 such points define a line, and so on, so that a more general
solution space can grow from specific instances that are end-to-end complete,
perhaps never filling n-space, but oriented to cover the most important points in
practice.

Tim

---

From: Zoltan Richard Turanyi <[email-masked]>
Date: Mon, 24 Jan 2000 11:06:22 +0100

> design is finished, then it'd be a better time to run a BOF to convince

This is a very good point. The logic is simple: 
 - IETF protocols must be extensible.
 - Anyone can propose extensions.
 - It is hard to reject extensions which provide useful functionality.
=> Protocols end up being complex. (See also Mobile IP besides RSVP as
good example.)

One way out might be the hierarchical thinking. This may have a few
benefits.

1. The problem might be different on local and global scales, so
providing a few local and one global protocol that interoperate may be
better that putting everything into one protocol.

2. Locally anyone can use whatever local protocol he thinks best suits
his domain.

3. Extensions or adjustments that are needed by only some of the local
domains, may not effect other domains.

4. Scaling might be easier.

On the negative side, interoperability and end2end is harder to achieve.
Still it may be considered here and in other areas as well. In case of
routing it worked.

/Zoltan

-- 
Zoltan Richard Turanyi  
Research Fellow, Ericsson Hungary
Traffic Analysis and Network Performance Lab

---

From: "Istvan Cselenyi" <[email-masked]>
Date: Mon, 24 Jan 2000 14:44:10 +0100

On Sun, 23 Jan 2000, Ping Pan wrote:
> ... 

One way to achieve fast work and avoide slide-ware show could be to 
apply Dave Clark's famous slogan:

"we don't believe in kings or queens, we believe in rough consensus and 
running code".

therefore we could set up a rule that the concepts presented at the 
QoSSIG BOF shall be previously verified by implementation. 

Istvan

---

From: "Istvan Cselenyi" <[email-masked]>
Date: Mon, 24 Jan 2000 14:43:09 +0100

Lixia,

thanks for your honest response, I think this is the right attitude what 
we need for making QoS signaling happen.

> I would also like to point out that RSVP did not start as complex, but

I believe that and think the same would happen if all the "QoSsig" funs 
started to melt their stuff for getting The ultimate QoS protocol.
 
> I have not found this process the right place to produce *simple* protocols.

But does it mean that IETF is not the right place for standardizing QoS 
signaling for IP? 

> design is finished, then it'd be a better time to run a BOF to convince

Many groups from my previous list started with a silent design period 
and made a prototype for verification. I think it is time for synchronizing 
theese works and check where are the limits of QoS signaling and what 
is the cost of different functionality.

I may be super naive but still believe in that IETF can provide a forum for 
discussing a common framework for QoS signaling in future internet and 
reviewing the vigorous alternatives.

BR
Istvan

--------------------------------------------------
                Istvan Cselenyi                      
 Telia Research AB           Phone: +46-8-7138173
 Vitsandsgatan 9 B431          Fax: +46-8-7138199          
 S-12386 Farsta            Mobile: +46-70-3228801  
 Sweden        E-mail: [email-masked]
--------------------------------------------------

---

From: "Andrew T. Campbell" <[email-masked]>
Date: Mon, 24 Jan 2000 12:00:22 -0800

> better that putting everything into one protocol.

Signaling systems are complex by nature - we all know that there is
no free lunch - they essentially define the
network-wide service creation environment and  services offered. 

The telcos have a lot of experience in engineering,
dimensioning and understanding these complex systems (to perfection,
whether 
we like the end result or not - the result is impressive). In contrast, 
IETF folks don't have that background or 
skill base here; that may be good or bad depending were you are
standing.

What strikes me as odd about the recent discussion on 'hierarchical'
signaling 
(to use Zoltan's term) is that this "separation"
of local and global state management for services 
parallels to some extent out dated ideas from telecoms al la 
the UNI and PNNI division (the motivation almost identical in both
cases?). 

Is such a division arbitrary and a moving target?

Tangentially, I always felt that the lingering "signaling" 
issues that were sidelined (or punted
because their complexity) would come back to bite diffserv. 
I have yet to read a good diffserv signaling/management paper that
argues
the case of slow versus not so slow (dynamic) provisioning and the
impact on service creation and signaling/management support. 
This is almost as a odd as not seeing a decent 
paper on the so called RSVP scalability problem. In fact I have yet to
read that 
'va-paper' that heralded RSVP's demise. Most discussion was hearsay on
RSVP's problems.
Yes signaling systems are costly - why is that suprising? BTW, can
someone point me
to a good analytical or simulation paper on the RSVP problem?
Note I don't want to be told about the size of the memory requirement
for maintaining per-flow state in the router or simplified complexity
metrics. Lets be serious folks? 

Coming back to my earlier question: Is such a division 
arbitrary and a moving target? Some may argue in the future that 
there will be even more infinite bandwidth at the edge local switches 
(so no explicit signaling needed there) and the core should
provide explicit signaling and state management 
for user services (e.g., in support dynamic virtual networking with its
associated isolation, security constraints, state and QOS provisioning). 
So the signaling (none at the edges and dynamic and 
explicit in the core) would be quite different 
from that discussed (or not discussed as the case may be) in 
today's diffserv.

So what's the panacea? open signaling?

This begs the question that as services evolve the service creation
engine of the network must accommodate change dynamically and with
ease.  There is an argument for defining a set of open signaling
interfaces 
in support of building dynamic network based services. Such a signaling 
engine with its open APIs has been discussed by 
the OPENSIG Group over the course of the past few years
initially in the context of ATM but for the last couple of
years for IP and mobile networks. The proceedings can be
found at:

 http://comet.columbia.edu/opensig/activities/activities.html

I don't think we need the IETF equivalent of UNI and PNNI.
Rather than enduring long drawn out discussions on the right
signaling protocol, I think we need a network-based 
middleware platform at the end-systems, edges and in the core that 
provide a set of well defined building blocks for a wide variety of
services and arbitrary divisions. This would herald competition (i.e.,
service
differentiation between ISPs) and evolution in the marketplace. 

QOS and signaling are very difficult problems. So rhetorically I
ask: is that why we are running around in circles.

After diffserv, ......

---

From: Jon Crowcroft <[email-masked]>
Date: Mon, 24 Jan 2000 17:30:15 +0000

>>network-wide service creation environment and  services offered. 
 
signaling systems are anything apart from the users data. they range
from ip destination address in every IP datagram, through to
per flow, per VPN or per ISP-ISP state setup.....in between these, for
example, the DSbyte is a quite simple signaling system - 

what you mean is that accurate provisioning is difficult.

 >>skill base here; that may be good or bad depending were you are

telcos have 1 service traditionally - its quite easy after 100 years
to provision for it (but even Erlangs dont cut it when ytou take into
account phone-in traffic) - but telcos dont have any magic experience
to offer on provisioning for multiple services on the same wire esp.
when the service model is not defined, and the traffic source model
and matrix are ill understood.

note: there's lots more ISPs and lots more levels of hierartchy for
this than there are telcos as well, just to make life harder, and the
system is growing and evolving faster than the phone net did ...so
that makes life harder.

 >>the UNI and PNNI division (the motivation almost identical in both

hierarchy is one of those strange attractor ideas - unfortunately ,it doesnt
always help. just because we have address, route and name hierarchies
doesnt mean that signaling or provisioning hierarchically is an
improvement - there's plenty of papers on the problems of fan-out and
fan-in of both signaling flows and traffic flows...

 >>Is such a division arbitrary and a moving target?
 
yep...

 >>because their complexity) would come back to bite diffserv. 

yep, agree

 >>impact on service creation and signaling/management support. 

i agree...

 >>'va-paper' that heralded RSVP's demise. Most discussion was hearsay on

yes, good point - rsvp, per se, is a very nice piece of work
for what it is designed for...

 >>metrics. Lets be serious folks? 

right - people would love a panacea - they want
assured qos, with assured predicatable provisioning targets AND lite
signaling - its a nogo - the model should be
you want diff-serve with low assurance (i.e. a lot of SLA
violations, a lot of subscription rejections), then you might get away
with something liter - maybe thats the target - say we say we 
don't mind double allocating 15% of capacity, and saying no wrongly
20% of the time - what type of signaling and dimensionign tools could
we use for that (after all we do this with best effort now and that
creates plenty of megabucks) 

maybe the new new thing in signaling is to look at scaling a system by
admitting a modest level of inconsistency to persist (somethign 
we have succesfully done in multiparty multimedia applications
sometimes) - so 

rough resource request and reserve consensus forming protocol (R4CFP)

maybe...

 cheers

   jon

---

From: Grenville Armitage <[email-masked]>
Date: Mon, 24 Jan 2000 10:40:27 -0800

Jon Crowcroft wrote:
	[..]
> rough resource request and reserve consensus forming protocol (R4CFP)

an application mails its request to a QoS Chair, who issues a Last
Call for resources, and after two units of time decides if there's
sufficient consensus for the request to be installed as an RFC
(request for CoS)

note i've now simplified the existing process by removing the
IESG review phase - voila, a lightweight protocol!

;)

cheers,
gja

---

From: Ping Pan <[email-masked]>
Date: Mon, 24 Jan 2000 14:13:26 -0500

> and matrix are ill understood.

Agree. 

> system is growing and evolving faster than the phone net did ...so

Yes. Worse, all the ISP's have their own route policies and filters at
border. They play all sort of tricks to use neighboring ISP's resource.
The concept of "peering cooperation" is probably too much to ask for in
today's network. I don't know what it was like in the early days of the
phone network. Today's Internet is probably much more hostile than the
phone network.

Thus, I agree with Juha's earlier assessment, for inter-domain
reservation, we need to work out the administrative problem as well.

> fan-in of both signaling flows and traffic flows...

At the same time, the concept of hierarchy is not something new. I'm
still reading through J. Noel Chiappa's work
(http://users.exis.net/~jnc/tech/book2.html) with amazement. People
obviously had thought about the issues that we are discussing today ...
different solution to the same set of problems.

BR,

- Ping

---

From: Randy Bush <[email-masked]>
Date: Mon, 24 Jan 2000 12:02:28 -0800

> border. They play all sort of tricks to use neighboring ISP's resource.

excuse!  please justify or withdraw this seeming libel.

randy

---

From: Ping Pan <[email-masked]>
Date: Mon, 24 Jan 2000 15:10:29 -0500

> excuse!  please justify or withdraw this seeming libel.

Given I probably should not reveal who had told me the ISP condition in
public mailing lists, I withdraw my previous comment. Sorry! 

- Ping

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 25 Jan 0 14:33:22 JST

Andrew;

> from that discussed (or not discussed as the case may be) in 

That's the matured standardiation committee.

> So what's the panacea? open signaling?

Massive parallelism.

See may paper titled "Hash Parallel and Label Parallel Routing for
High Performance Multicast Router with Fine Grain QoS Control"
in proceedings of IWS'99 just published by IEEE press.

> What strikes me as odd about the recent discussion on 'hierarchical'

UNI and PNNI division solves nothing.

							Masataka Ohta

---

From: Jon Crowcroft <[email-masked]>
Date: Tue, 25 Jan 2000 08:11:12 +0000

>>IESG review phase - voila, a lightweight protocol!

ha - very amusing - :-)
but acutally i was serious - the point about diffserve (now we can
discuss this as we've dropped them off the cc: list:-)

is that it makres relative assurances - since they arent absolute, its
reasonable to make them also not deterministic - some of the phases in
most trad signaling protocols are complex because they are tryting to
be transactional (ACID in proper terms) - these phases can be removed
if you relax the requirement for consistency - this makes them
inherently simpler in number of messages AND state in routers....

we can also probably hack multi-path and dynamic re-routing more
easily if we were to make this relaxation - the point is then, it
makes the dimensioning/probisioning hard, but its hard anyway, so why
not just punt on that, and build an optimistic fuzzy
reservation./signaling protocol, which will scale, but be
approxcimate, and then find out how approximate....ratehr than try to
nail everything down the way we have been, when we dont even know what
we are nailing down on to what!!

 >>cheers,

yep

 cheers

   jon

---

From: Zoltan Richard Turanyi <[email-masked]>
Date: Tue, 25 Jan 2000 11:20:45 +0100

Andrew,

Beforehand I must state that in no way am I an ATM fan. But I still
believe that in some cases separating the interface between the host and
the network from the interface between network nodes is a good idea.
This separates two businesses: OS/Apps and networking and makes much
easier to change or modify networking protocols. It also allows local
domains to use whatever protocol they wish without affecting hosts. This
thing is also called modularity.

Besides, the idea is already used. Routers talk to each other via
routing protocols, while hosts get only occasional ICMP Redirects. Or
with multicasting: hosts speak IGMP, while the routers can use whatever
mcast routing protocol you prefer. Furthermore, a Qos signalling
protocol might have different requirement between two routers of the
same domain and between two ISPs. This is also clearly reflected in the
present routing system. Just think how easier is it now to
change/introduce an intra-domain routing protocol compared to the case
of all routers running the same protocol.

Defining different protocols for different interfaces is indeed a good
idea in many cases. (And the fact that ATM does the same, does not
weaken this argument (-: .) Signalled Qos (if we need it at all) is a
case when considering might be worthwile. This way services could be
created much easier locally in a domain by employing the protocol of
local choice and without disturbing OSs or ISP-ISP interfaces.

/Zoltan

---

From: "Scott W Brim" <[email-masked]>
Date: Tue, 25 Jan 2000 12:19:02 -0500

At 08:11 AM 1/25/00 +0000, Jon Crowcroft wrote:
>reasonable to make them also not deterministic -

First, diffserv-based *services* can be deterministic at the edges.  So 
be careful what you declare unnecessary.  The one thing we can't do (that 
I can think of) with diffserv in the core is isochronous delivery.

>some of the phases in
>most trad
       ^^^^
Please use English, not English :-)

>signaling protocols are complex because they are tryting to

I think you're on a track similar to Ping's.

...Scott

---

From: Jon Crowcroft <[email-masked]>
Date: Wed, 26 Jan 2000 07:53:06 +0000

>>excuse!  please justify or withdraw this seeming libel.

randy,

while you're undoubtedly right....say you weren't?:

um, i suppose you speak for all ISPs and have in place a
multi-provider SLA  monitoring system that can produce audited
evidence in support of the libel case? :-) :-)

of course, if you did, then all this diffserv/intserv/signaling stuff
would be moot, since you'd offer this wonderful service thru some
tariff structure, to the end user...

 cheers

   jon