Subject: Re: Generic QoS Socket Interface

From: [email-masked] (Vivek Bansal)
Date: Thu, 18 Aug 94 16:06:28 EDT

> 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. The client
> sees the modified QoS, and if it doesnt like it, tears down the call.

In our work , we've also recognized the need for communication between the
client and the server through signalling before the actual data connection
is actually set.  For example in case of typical (image, video)-on-demand
application it would be the server which would not the characteristics of
the data stream itself, although the connection request would be initiated
by the client. 
 
But Keshav , I believe in your model of connection-setup the resources are
allocated in the first round and in the second round if the server modifies
te QoS then you change the allocation. We do not allocate any resources at
all till the client and server have handshaked the requirements. 

We also provide options to the application to pass some data with the signallingmessages, which the server application can use in deciding the kind of data 
stream that the client needs (which only the server application understands). 
Well it can be said that, well thats a layer above the transport issue, but in
order to set a data connection at the ATM level, we believe all layers (if they can) should contribute in deciding how fat the ATM pipe should be and what QoS 
is needed for it. 
 
All comments welcome...

Vivek...

---

From: [email-masked]
Date: Fri, 19 Aug 94 23:30:40 -0400

I am just wondering off the top of my head if we should keep this all 
in the kernel and transparent to user space.

What about using an out-of-band signal with modifications to define
a change to the QOS?  The change could be a jitter of some sort?

Does the application have to know about the change?  If so why? 

Seems messy to pass this in and out of kernel and user space or
involving an RPC or library, but I understand why it was done today.

Or do we just need a session layer above transport so we don't
have to mess with TCP or UDP?  I am beginning to see other reasons for a
session layer in IP6 besides this topic too, but maybe not????

I really don't think now is the time to mess with the transport layer
and change the network layer too.  This is most likely too much work
for host vendors at one time to absorb.

/jim

---

From: "L. Stuart Vance" <[email-masked]>
Date: Sat, 20 Aug 1994 11:30:14 -0700 (PDT)

>for host vendors at one time to absorb.

A good point, but let me offer something to counter it.  Let's make all the
changes at once, so that the customers only have to deal with it once.  It's
going to be a difficult enough task to deal with one conversion, let alone
two...

Regards,
-----Stuart

---

From: [email-masked]
Date: Sun, 21 Aug 94 01:34:51 -0400

Hi Stuart,

>going to be a difficult enough task to deal with one conversion, let alone

But they may not get IP6 in time because IPv4 addresses will be gone.  I
say this tongue and cheek as it took almost 4 years to figure out IP6.
If it takes the same time for TCPng that could put us near the year 2000 
and the way the Internet is getting used up we could be in real trouble.

Also think about the testing scenarios and the added resources from
those who will participate.  We have our hands full now dealing with
IP6 and transition.  We have to search hard for chairs of WGs and we
just got started on IP6 and I am not clear how long this will take to
ratify to where the specs are stable and real products can be produced.
We have some proposed IETF dates but they are gut feelings and many 
variables could change the dates.

We also are not sure of what the IP6 market is either and if it is even
wanted by real customers, and now we go invest in a new TCP and UDP.  I
am not clear this is a good idea.

For research it should be done and I hope is being done.   Well I know
its being done.

As for the needs presented recently a session layer would work fine with
the proper QOS model in the network layer.  This is very doable and
TCP/UDP do not have to change at all.  This could also be useful for the
anycast model proposed too and RPC could forget about the kernel maybe.

And if we are going to mess with the transport layer based on a lot of
IETF interest the first topic I would be more interested in working on
is the concept of an EID (Steve Deering dont yell at me).  The benefits
here would provide added value for existing customers not percieved new
technologies for which no vendor has yet to make $1billion revenue let
alone a profit to even begin to recover their investment in new
technology.  Sorry if I sound like a capitalist instead of lets do
something elegant that will run fast or solve the world hunger problem.
Its pretty simple to me.  Can any vendor make any money on doing such
work and how?  Lots of folks say I want this technology or that
techonology but unless they buy enough of it suppliers will stop
providing it.  We are in the cusp of our industries paradigm shift to
the information market.  Until this flys we need really good reasons to
change that which ain't broke.

Another problem at hand is UDP I think.  The new frag/reassem model in
IP6 will stress UDP I predict and we discussed this at SIPP implementor
meetings in the past while building that proposals prototype code.  In
stead of dreaming in architecture land, we saw this transport problem
manifest itself in the prototypes as they were being developed by
programmers or engineers which ever you prefer.

What problem would TCPng be trying to solve for the market?  Somone
should have to answer this question.  We had a definitive problem with
IPv4 when undertaking that (actually three).  Or whats the business
problem?  Just doing it because we are there now in IP6 is not a good 
idea IMHO.

/jim