Subject: Re: (IPng) Re: Generic QoS Socket Interface

From: Masataka Ohta <[email-masked]>
Date: Thu, 18 Aug 94 14:57:46 JST

> I believe that we should view the QoS in the following way. The client
> sends a specification via signalling to the server. The server has
> a chance to accept the connection, and _modify_ this QoS, depending on
> its current load. The modified string is then used to relax the 
> network's reservation state, and passed back to the client.

There are a lot of people who thinks differently in a lot less
connection oriented way.

That is, a client periodically sends reservation packets to the
destination. Intermediate relaying entities such as routers or bridges
may or may not grant the reservation and may notify the denied grant
to the client.

> Having worked with two signaling implementations, 
> it is very clear, at least to me, that putting
> signaling in the kernel is a bad idea. There are far too many things
> that can go wrong, and it is a big win to be able to restart signaling
> in user space, instead of rebooting the kernel each time.

Then, what is wrong is the signaling specification, not rest of
the world.

Anyway, the current ATM QoS with Q.2931 packet is no effective
beyond IP routers and can not be a basis of QoS specification for
the Internet.

							Masataka Ohta